Cloud-Architecture

Overview Vertical scaling grows capacity by adding more CPU/RAM to a single machine, while horizontal scaling grows capacity by adding more nodes behind a load balancer. The choice shapes your application’s architecture, failure model, and cost curve as it grows. Comparison Diagram VerticalHorizontalServerServer+CPU +RAMServer++CPU ++RAMLoad BalancerNodeNodeNode+NodeSingle node, growingMany nodes, distributed Comparison Table Aspect Vertical Scaling Horizontal Scaling Scaling mechanism Add CPU, RAM, or faster disks to one machine Add more machines/nodes to a shared pool Architecture requirement Works with any app, no code changes needed Requires stateless design, load balancing, and shared state (session store, distributed cache) Upper limit Capped by the largest hardware SKU available Effectively unbounded, limited only by orchestration and cost Downtime during scale-up Often requires reboot or migration to bigger instance New nodes join the pool live, no downtime Fault tolerance Single point of failure — one box, one crash Node failures are absorbed by the remaining pool Cost curve Price rises non-linearly at the high end (diminishing returns) Roughly linear cost per added unit of capacity Operational complexity Low — one server to patch, monitor, and secure Higher — needs service discovery, distributed monitoring, data consistency handling Typical use case Monolithic apps, relational databases, legacy systems Stateless web services, microservices, cloud-native workloads Key Differences Vertical scaling upgrades a single machine; horizontal scaling adds more machines to a pool Horizontal scaling demands stateless services, while vertical scaling needs no architectural change Vertical scaling has a hard hardware ceiling; horizontal scaling scales near-linearly A single oversized server is a single point of failure, unlike a distributed node pool Horizontal scaling trades simplicity for operational complexity in orchestration and consistency When to Use Each Vertical Scaling ...

Overview Both let you deploy application code without owning physical servers, but they draw the abstraction line in different places. Serverless functions run only in response to events and scale to zero between invocations, while containers package your app with its dependencies into a persistent, always-addressable process you (or an orchestrator) keep running. Comparison Diagram ServerlessContainersInstance per eventrequestsIdle gaps = zero cost, zero running processCluster / hostContainer AContainer BContainer CAlways running, billed continuously Comparison Table Aspect Serverless Containers Deployment unit Single function handler plus its dependencies Full image with OS layers, runtime, and app code Startup trigger Invoked per event (HTTP call, queue message, timer) Started explicitly and left running by an orchestrator Runtime lifetime Ephemeral, seconds to minutes, then torn down Long-lived, runs continuously until stopped or redeployed State handling Stateless between invocations; external store required Can hold in-memory state across requests within its life Scaling behavior Platform scales instance count automatically, including to zero You or an orchestrator (e.g. Kubernetes) define replica counts and rules Resource control No control over OS, runtime patching, or underlying host Full control over base image, OS packages, and runtime version Cost model Pay per invocation and execution time, nothing when idle Pay for allocated capacity whether or not it’s handling traffic Operational overhead No servers, patching, or orchestration to manage You own cluster upkeep, scaling policy, and image maintenance Key Differences Serverless bills per invocation, containers bill for allocated capacity regardless of traffic Containers give you a fixed runtime environment you control; serverless abstracts the OS away entirely Cold starts and short execution limits shape serverless function design; containers have no such ceiling Serverless functions are inherently stateless, while containers can maintain in-process state across requests When to Use Each Serverless ...

Overview Multi-cloud and hybrid cloud both combine more than one infrastructure environment, but for different reasons. Multi-cloud spreads workloads across multiple public providers that typically run independently, while hybrid cloud tightly links private and public environments so they operate as one integrated system. The distinction matters because it drives very different networking, security, and management requirements. Comparison Diagram Multi-CloudHybrid CloudAWSAzureGCPIndependent providers,no shared network layerPrivate /On-PremPublic CloudVPN / DirectConnect linkConnected environments,workloads span both Comparison Table Aspect Multi-Cloud Hybrid Cloud Infrastructure composition Two or more public cloud providers (e.g. AWS + GCP + Azure) A mix of private/on-prem infrastructure plus at least one public cloud Primary driver Avoid vendor lock-in, use best-of-breed services, meet regional data rules Extend existing on-prem investments while adding cloud elasticity or offloading specific workloads Integration between environments Environments usually operate independently with little cross-linking Environments are deliberately networked together (VPN, Direct Connect, ExpressRoute) to act as one system Workload placement Each workload runs entirely within whichever single provider suits it A single application or pipeline can span on-prem and public cloud simultaneously Networking and identity Separate networking, IAM, and billing per provider Requires a shared identity layer and consistent network routing across both sides Management complexity Multiple consoles, APIs, and skill sets to operate in parallel Requires orchestration tooling that bridges private and public layers into one operational view Resilience and failure mode An outage in one provider is isolated and doesn’t affect the others A break in the private-to-public link can disrupt the integrated workload on both sides Key Differences Multi-cloud spans multiple public providers that don’t need to talk to each other; hybrid cloud deliberately connects on-prem and cloud into one system. Multi-cloud is chosen mainly to avoid vendor lock-in; hybrid cloud is chosen mainly for compliance or latency constraints on data. In multi-cloud each workload lives entirely in one provider; in hybrid cloud a workload can literally span environments. Hybrid cloud depends on a dedicated network link between environments; multi-cloud typically has none. The two aren’t mutually exclusive — an organization can run a hybrid multi-cloud setup combining both patterns. When to Use Each Multi-Cloud ...