20.2 Cloud Computing Architectures

Cloud Computing Fundamentals

Cloud computing provides on-demand access to a shared pool of configurable resources like servers, storage, and networks. Rather than buying and maintaining physical hardware, organizations provision what they need over the internet and release it when they're done. This model shifts computing from a capital expense to an operational one, which is why it's become central to modern distributed systems.

This section covers the defining characteristics of cloud computing, the three main service models, deployment strategies, and the architectures (virtualization, containers, microservices) that make it all work.

Characteristics of Cloud Computing

The NIST definition of cloud computing identifies five essential characteristics. These aren't just buzzwords; they're what distinguishes cloud computing from traditional hosting.

• On-demand self-service: Users provision computing capabilities (spin up a VM, allocate storage) as needed, without calling or emailing a service provider. You interact with a portal or API, and resources appear in minutes.
• Broad network access: Resources are available over the network and accessed through standard mechanisms (web browsers, mobile apps, CLI tools). "Ubiquitous access" means you can reach your cloud resources from anywhere with a connection.
• Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model. Physical and virtual resources are dynamically assigned and reassigned based on demand. You don't know (or need to know) exactly which physical server your workload runs on.
• Rapid elasticity: Capabilities can scale outward and inward quickly to match demand. From the consumer's perspective, available resources often appear unlimited. If your web app suddenly gets 10x traffic, auto-scaling can spin up additional instances automatically.
• Measured service: Cloud systems automatically control and optimize resource use through metering. You pay for what you consume (compute hours, storage GB, network bandwidth), and both provider and consumer can monitor usage transparently.

Cloud Service Models and Deployment

Service Models

The three service models represent different levels of abstraction. As you move from IaaS to SaaS, the cloud provider manages more of the stack, and you manage less.

• Infrastructure as a Service (IaaS): Provides the fundamental building blocks: virtual machines, storage volumes, and networks. You control the operating system, middleware, and applications. The provider handles the physical hardware, power, and networking underneath.
  • Examples: AWS EC2, Microsoft Azure VMs, Google Compute Engine
  • Use case: You need full control over the OS and runtime environment, like running a custom database server.
• Platform as a Service (PaaS): Provides a managed platform for developing and deploying applications. You write and deploy your code; the provider handles the OS, runtime, scaling, and patching. This is a higher level of abstraction than IaaS.
  • Examples: Heroku, Google App Engine, AWS Elastic Beanstalk
  • Use case: A development team wants to deploy a web application without managing servers or OS updates.
• Software as a Service (SaaS): Provides complete applications accessible through a web browser or thin client. The provider manages everything: infrastructure, platform, and the application itself. Users just consume the software.
  • Examples: Google Workspace, Salesforce, Dropbox
  • Use case: An organization needs email and document collaboration tools without running its own mail servers.

Cloud Deployment Models

Deployment models describe who owns and accesses the cloud infrastructure.

• Public cloud: Infrastructure is provisioned for open use and owned/operated by a third-party provider (AWS, Azure, GCP). Multiple organizations share the same underlying physical resources, though their data and workloads are logically isolated.
  • Advantages: Low upfront cost, high scalability, minimal management overhead
  • Limitations: Less control over data locality and security policies, potential regulatory compliance challenges
• Private cloud: Infrastructure is provisioned for exclusive use by a single organization. It can be hosted on-premises or by a third party, but the key point is that only one organization uses it.
  • Advantages: Greater control over data, security, and compliance; customizable to specific requirements
  • Limitations: Higher cost, limited elasticity compared to public cloud, more management burden
• Hybrid cloud: A composition of two or more distinct cloud infrastructures (typically private and public) bound together by technology that enables data and application portability. A common pattern is cloud bursting, where normal workloads run on a private cloud but overflow to a public cloud during demand spikes.
  • Advantages: Combines the control of private cloud with the scalability of public cloud
  • Limitations: More complex to manage and integrate; security risks can arise at the boundary between private and public environments

Virtualization and Cloud-Native Architectures

Virtualization

Virtualization is the foundational technology that makes cloud computing possible. A hypervisor (like VMware ESXi or KVM) sits between the physical hardware and the virtual machines, dividing one physical server's CPU, memory, and storage among multiple isolated VMs.

Why this matters for cloud computing:

• Multi-tenancy: Multiple customers' VMs can safely share the same physical host because the hypervisor enforces isolation between them.
• Rapid provisioning: Spinning up a new VM takes minutes, not the weeks it takes to procure and rack a physical server.
• Live migration: VMs can be moved between physical hosts without downtime, enabling maintenance and load balancing.

Containers

Containers are a lighter-weight alternative to full VMs. A container packages an application along with its dependencies (libraries, config files, runtime) into a single executable unit. Unlike a VM, a container shares the host OS kernel rather than running its own full operating system.

• Docker is the most widely used container runtime. Kubernetes is the standard orchestration platform for managing containers at scale (scheduling, scaling, health checks).
• Containers start in seconds (vs. minutes for VMs), use less memory, and are highly portable across environments.
• The tradeoff: containers provide process-level isolation rather than the hardware-level isolation of VMs, so they offer a smaller security boundary.

Microservices

A microservices architecture decomposes a single application into many small, loosely coupled services. Each service handles one specific business capability (e.g., user authentication, payment processing, inventory management) and communicates with others through well-defined APIs, typically REST or gRPC.

This architecture pairs naturally with containers and cloud computing because:

1. Each microservice can be deployed, updated, and scaled independently. If your payment service needs more capacity, you scale just that service, not the entire application.
2. Different teams can own different services, choosing the best language or framework for each one.
3. A failure in one service doesn't necessarily bring down the whole application, improving overall resilience.

The main challenge is operational complexity. Instead of deploying one application, you're now managing dozens or hundreds of services, each with its own deployment pipeline, logging, and monitoring. Orchestration tools like Kubernetes and service meshes (e.g., Istio) help manage this complexity, but the overhead is real.