Learn cloud computing: from servers to serverless
This curriculum takes a beginner from zero cloud knowledge to confident cloud architect, moving through four tightly sequenced stages. Each stage builds on the last: first establishing mental models and vocabulary, then hands-on deployment skills, then scalable distributed design, and finally the deep architectural thinking behind modern cloud-native systems.
Foundations: What the Cloud Actually Is
BeginnerUnderstand what cloud computing is, why it exists, and how its core service models (IaaS, PaaS, SaaS) and major providers fit together — building the vocabulary needed for everything that follows.
▸ Study plan for this stage
Pace: 2–3 weeks, ~20–25 pages/day — The Big Switch is ~230 pages; read Part 1 (the historical electricity analogy) in Week 1, Part 2 (the IT utility shift) in Week 2, and spend Week 3 reviewing, reflecting, and completing exercises.
- The utility analogy: how electricity generation shifted from private dynamos to a shared grid, and why Carr argues IT is following the same path
- World Wide Computer: the idea that the internet becomes a single, shared computing utility available on demand
- The economics of centralization: why it is cheaper and more efficient to rent computing power from massive shared infrastructure than to own and operate it yourself
- IaaS, PaaS, and SaaS as layers of abstraction: infrastructure, platform, and software each represent a different level of control traded for convenience
- Major cloud providers (AWS, Google, Microsoft Azure) as the 'power stations' of the new computing grid
- Commoditization of IT: as computing becomes a utility, differentiation shifts from owning hardware to how you use the service
- Disruption of the traditional IT department: what changes for businesses, workers, and society when computing is no longer on-premise
- The double-edged nature of the cloud: efficiency and democratization gains alongside risks around privacy, control, and dependency
- In Carr's electricity analogy, what role did Samuel Insull play, and which modern cloud providers occupy the equivalent position today?
- What specific economic and technical forces does Carr identify as driving the shift from private data centers to shared cloud infrastructure?
- How do IaaS, PaaS, and SaaS differ in terms of what the customer manages versus what the provider manages — and which layer does Carr's 'World Wide Computer' most directly describe?
- What does Carr mean by the 'commoditization of IT,' and what are the strategic implications for a company that previously viewed its data center as a competitive advantage?
- What social and workforce risks does Carr raise about the cloud utility model, and do you find his concerns more or less relevant given developments since the book was published?
- How does the concept of 'on-demand, pay-as-you-go' pricing change the capital expenditure model of traditional IT?
- Timeline exercise: Draw a two-column timeline — one column for the history of electrical utilities (1880s–1930s) and one for cloud computing (1990s–present). Map Carr's key milestones side by side to make the analogy concrete and memorable.
- Vocabulary flashcards: Create a card for each term — IaaS, PaaS, SaaS, on-demand computing, utility computing, commoditization, elasticity, multi-tenancy. Write the definition in your own words on the back, grounded in Carr's framing.
- Provider mapping: Research AWS, Microsoft Azure, and Google Cloud. For each, find one real product that fits IaaS, one that fits PaaS, and one that fits SaaS. Build a simple 3×3 table to see how the layers manifest in practice.
- Cost comparison thought experiment: Pick a hypothetical small business that needs a web server. Estimate the rough cost of buying and maintaining physical hardware for 3 years versus renting equivalent compute from a cloud provider. Reflect on which variables Carr's argument depends on.
- Annotated re-read: Go back through Part 2 of The Big Switch and highlight every claim Carr makes that is either (a) clearly validated or (b) clearly contradicted by what you know about cloud computing today. Write a one-paragraph verdict on how well his predictions held up.
- Elevator pitch: Write a 90-second spoken explanation of 'what cloud computing is and why it exists' as if explaining it to a non-technical friend — using only concepts and analogies drawn from The Big Switch. Record yourself and listen back.
Next up: Having absorbed the historical 'why' and the high-level vocabulary of cloud computing through Carr's utility lens, the reader is now ready to move from conceptual framing to hands-on technical architecture — understanding how cloud infrastructure is actually designed, deployed, and managed in practice.
A compelling, accessible narrative on why computing became a utility — like electricity — giving the reader the essential 'why cloud' mental model before touching any technology.
Hands-On: Deploying and Running Apps in the Cloud
BeginnerGet practical experience provisioning infrastructure, deploying applications, and using core AWS services — translating conceptual knowledge into real, working cloud deployments.
▸ Study plan for this stage
Pace: 10–12 weeks total. Week 1–4: "Amazon Web Services in Action" (~40–45 pages/day, 5 days/week) — read alongside the AWS Free Tier console. Week 5–7: "Docker: Up and Running" (~35–40 pages/day, 5 days/week) — run every example locally as you read. Week 8–12: "Kubernetes: Up and Running" (~30–35 pages/d
- AWS core services: EC2 (virtual machines), S3 (object storage), RDS (managed databases), IAM (identity & access management), VPC (virtual networking), and the AWS Management Console/CLI — as introduced in Amazon Web Services in Action
- Infrastructure provisioning on AWS: launching and configuring instances, attaching storage, setting security groups, and understanding the shared-responsibility model — grounded in Amazon Web Services in Action
- Containerization fundamentals: images vs. containers, Dockerfiles, the Docker build/run/push lifecycle, volumes, networking, and Docker Compose for multi-container apps — as covered in Docker: Up and Running
- Container registries and image distribution: tagging, pushing to Docker Hub or Amazon ECR, and pulling images in production environments — from Docker: Up and Running
- Kubernetes architecture: the control plane (API server, scheduler, etcd) vs. worker nodes, and the role of kubectl as the primary interface — as laid out in Kubernetes: Up and Running
- Core Kubernetes objects: Pods, ReplicaSets, Deployments, Services, ConfigMaps, and Secrets — and how Hightower's book walks through composing them to run real applications
- Scaling and self-healing in Kubernetes: rolling updates, rollbacks, horizontal pod autoscaling, and liveness/readiness probes — from Kubernetes: Up and Running
- The progression from raw VMs → containers → orchestrated workloads: understanding why each layer exists and what problem it solves, a thread that runs across all three books
- After reading Amazon Web Services in Action, can you explain what a VPC is, why subnets and security groups matter, and walk through the steps to launch a publicly accessible EC2 instance with an attached EBS volume?
- How does IAM enforce the principle of least privilege in AWS, and what is the difference between an IAM user, a role, and a policy — as described in Amazon Web Services in Action?
- From Docker: Up and Running, what is the difference between a Docker image and a running container, and what instructions in a Dockerfile are most critical for keeping images small and secure?
- How does Docker Compose (covered in Docker: Up and Running) simplify running a multi-container application locally, and what are its limitations compared to a production orchestrator?
- Based on Kubernetes: Up and Running, what happens step-by-step when you run kubectl apply -f deployment.yaml — which control-plane components are involved and how does the desired state get reconciled?
- How do Kubernetes Services (ClusterIP, NodePort, LoadBalancer) expose Pods to traffic, and when would you choose each type, as explained in Kubernetes: Up and Running?
- AWS in Action — Build a 3-tier architecture: use the AWS Console and then the AWS CLI to provision a VPC with public/private subnets, launch an EC2 web server in the public subnet, an RDS MySQL instance in the private subnet, and an S3 bucket for static assets. Verify each tier can communicate correctly and lock it down with security groups.
- AWS in Action — IAM least-privilege drill: create a new IAM user with zero permissions, then iteratively attach only the policies needed to let that user list S3 buckets, start/stop a specific EC2 instance, and nothing else. Document every policy decision.
- Docker: Up and Running — Containerize a simple web app: write a Dockerfile for a Node.js or Python Flask app, build the image, run it locally, push it to Docker Hub (or Amazon ECR), then pull and run it on your EC2 instance from the AWS exercise above — closing the loop between both books.
- Docker: Up and Running — Multi-container app with Compose: write a docker-compose.yml that wires together your web app container, a Redis cache container, and an Nginx reverse-proxy container. Practice stopping, rebuilding, and scaling individual services.
- Kubernetes: Up and Running — Local cluster to cloud: deploy your Dockerized app from the Docker exercises onto a local cluster (kind or minikube) using a Deployment and a Service manifest. Then repeat the deployment on a real cloud cluster (Amazon EKS free tier or a small kubeadm cluster on EC2) and expose it via a LoadBalancer Service.
- Kubernetes: Up and Running — Rolling update and rollback drill: update your Deployment to a new image tag, watch the rollout with kubectl rollout status, deliberately push a broken image to trigger a failed rollout, then use kubectl rollout undo to recover — mirroring the resilience patterns Hightower emphasizes throughout the book.
Next up: By the end of this stage the reader can independently provision AWS infrastructure, package apps as containers, and orchestrate them with Kubernetes — creating the practical foundation needed to tackle more advanced topics such as cloud-native architecture patterns, CI/CD pipelines, infrastructure-as-code (e.g., Terraform or AWS CloudFormation), and production-grade observability in the next stage
The most widely recommended hands-on AWS book for beginners; walks through EC2, S3, RDS, VPC, and IAM with concrete examples, making abstract services tangible.
Containers are the universal packaging unit of modern cloud apps; this book teaches Docker from scratch so the reader can package and deploy applications the way the industry actually does it.
Builds directly on Docker knowledge to teach orchestration — how to run, scale, and manage containerized apps in production, a skill required for every subsequent architectural topic.
Scaling and Reliability: Distributed Systems Thinking
IntermediateUnderstand why distributed systems are hard, how to design for scale and fault tolerance, and what trade-offs underpin every major cloud architecture decision.
▸ Study plan for this stage
Pace: 10–12 weeks total. Weeks 1–7: "Designing Data-Intensive Applications" (~40–45 pages/day, 4–5 days/week, prioritizing chapters on replication, partitioning, transactions, and consistency). Weeks 8–12: "The Art of Scalability" (~30–35 pages/day, 4–5 days/week, focusing on the Scale Cube, organizationa
- Replication strategies and their trade-offs: single-leader, multi-leader, and leaderless replication (DDIA Ch. 5) — understanding lag, failover, and conflict resolution
- Partitioning (sharding) schemes — range vs. hash partitioning, secondary indexes, and rebalancing strategies (DDIA Ch. 6)
- The CAP theorem and consistency models: linearizability, eventual consistency, and causal consistency, and when each is appropriate (DDIA Ch. 9)
- Distributed transactions and consensus: two-phase commit, the problems it introduces, and how consensus algorithms like Raft/Zab solve them (DDIA Ch. 9)
- Batch vs. stream processing paradigms: MapReduce, dataflow engines (Spark, Flink), and the Lambda/Kappa architecture patterns (DDIA Ch. 10–11)
- The Scale Cube (X/Y/Z axes): horizontal duplication, functional decomposition, and data partitioning as a unified framework for scaling decisions (The Art of Scalability)
- Organizational and process scalability: how team structure, roles, and engineering processes must evolve alongside technical architecture (The Art of Scalability)
- Fault tolerance design principles: designing for failure, graceful degradation, bulkheads, and the difference between availability and reliability as engineering targets (both books)
- After reading DDIA, can you explain the difference between synchronous and asynchronous replication, and articulate a concrete scenario where each is the right choice — including what you give up with each?
- What does the CAP theorem actually constrain, and why is the CP vs. AP framing often an oversimplification? What does DDIA suggest is a more nuanced way to think about consistency trade-offs?
- How does the Scale Cube from 'The Art of Scalability' map onto real cloud services you use (e.g., a database cluster, a microservices API, a CDN)? Which axis does each primarily exploit?
- What is the difference between a distributed transaction using 2PC and achieving the same outcome through idempotent operations and sagas? When would you choose one over the other?
- How do 'The Art of Scalability's' organizational scaling principles (team topology, swim lanes, fault isolation) complement the technical fault-tolerance patterns described in DDIA?
- Given a system experiencing both read and write bottlenecks, how would you use concepts from both books to diagnose the root cause and propose a phased scaling strategy?
- **Replication Lab:** Spin up a 3-node PostgreSQL or MySQL cluster (use Docker Compose) and simulate leader failover. Observe replication lag under write load and document what data loss or inconsistency you observe — then map your findings to the failure modes described in DDIA Ch. 5.
- **CAP Trade-off Matrix:** Build a one-page reference table mapping 6–8 real cloud services (e.g., DynamoDB, Spanner, Kafka, Cassandra, Redis Cluster) to their consistency model, partition-tolerance behavior, and the DDIA chapter that best explains their design. Justify each entry in writing.
- **Scale Cube Audit:** Pick a real or hypothetical application (e.g., a social media feed, an e-commerce checkout). Apply the Scale Cube from 'The Art of Scalability' and produce a written scaling roadmap: what you'd do at each axis, in what order, and what organizational changes each step requires.
- **Chaos Engineering Drill:** Using a local microservices demo (e.g., the Istio Bookinfo app or a simple Flask/Node multi-service setup), deliberately kill one service and observe cascading failures. Then implement one bulkhead or circuit-breaker pattern and re-run the experiment. Write a post-mortem using the vocabulary from both books.
- **Stream vs. Batch Design Doc:** Design (on paper or in a diagramming tool) a data pipeline for a high-volume event stream (e.g., clickstream analytics). Produce two versions — one batch (MapReduce-style) and one streaming (event-driven) — and write a trade-off analysis grounded in DDIA Ch. 10–11.
- **Org-to-Architecture Mapping:** Using 'The Art of Scalability's' organizational frameworks, draw the team structure that would own each component of your Scale Cube design from Exercise 3. Identify at least two Conway's Law risks and propose mitigations.
Next up: Mastering why distributed systems are hard and how to scale them deliberately sets the foundation for the next stage, where these abstract trade-offs become concrete implementation decisions in specific cloud provider services, managed databases, and serverless architectures.
The single most important book on how data flows through distributed systems; covers replication, partitioning, consistency, and streaming — the intellectual core of cloud-scale design.
Introduces the Scale Cube and systematic frameworks for scaling people, processes, and technology — bridging the gap between distributed systems theory and real organizational practice.
Advanced Architecture: Cloud-Native and Modern Patterns
ExpertDesign production-grade, cloud-native systems using microservices, serverless, and infrastructure-as-code — and reason about security, cost, and operational excellence like a senior cloud architect.
▸ Study plan for this stage
Pace: 10–13 weeks total: "Building Microservices" (~4 weeks, ~35 pages/day), "Cloud Native Patterns" (~3 weeks, ~30 pages/day), "Terraform: Up & Running" (~3 weeks, ~25 pages/day), plus 1–2 weeks for integration exercises and review across all three books.
- Microservice decomposition strategies: domain-driven design, bounded contexts, and the 'how small is small enough' principle from Newman's service modeling chapters
- Inter-service communication patterns: synchronous REST/RPC vs. asynchronous event-driven messaging, and the trade-offs Newman details around choreography vs. orchestration
- Resilience and stability patterns: circuit breakers, bulkheads, timeouts, and retry logic as Newman prescribes them for production microservices
- Cloud-native application contract (the 12-factor app and beyond) as Cornelia Davis frames it — statelessness, config externalization, and disposability
- Dynamic routing, service discovery, and the role of the platform (Kubernetes, Cloud Foundry) in Davis's cloud-native model
- Serverless and Function-as-a-Service trade-offs: cold starts, event-driven invocation, and when Davis argues serverless is and isn't appropriate
- Infrastructure-as-Code fundamentals with Terraform: HCL syntax, state management, providers, and the plan/apply lifecycle from Brikman
- Terraform modularity and team workflows: reusable modules, remote state backends, workspaces, and Terragrunt patterns Brikman advocates for production teams
- According to Newman, what are the primary decomposition strategies for identifying microservice boundaries, and how does domain-driven design's concept of bounded contexts guide those decisions?
- How does Cornelia Davis distinguish a 'cloud-native' application from one that is merely 'cloud-hosted,' and what architectural properties must an app possess to qualify as truly cloud-native?
- Newman details several patterns for handling data in a microservices architecture — what are the key arguments against a shared database, and what patterns does he recommend instead?
- Davis describes dynamic service discovery and routing as a platform responsibility rather than an application responsibility — what does this mean in practice, and how does it change how you write service clients?
- In Brikman's Terraform model, what is the role of Terraform state, what problems arise when state is managed locally on a single machine, and how does remote state with locking solve them?
- How would you combine all three books' lessons to design a production system: using Newman's service boundaries, Davis's cloud-native runtime contract, and Brikman's IaC approach to provision and manage the infrastructure?
- Service decomposition workshop: Take a monolithic e-commerce application (orders, inventory, payments, notifications) and draw explicit bounded-context diagrams following Newman's guidance. Justify each service boundary in writing, identifying shared data risks and proposed event contracts.
- Build a resilient microservice pair: Implement two small services (e.g., an Order Service calling an Inventory Service) with a circuit breaker (using Resilience4j or Polly), retry logic, and a dead-letter queue for failed async messages — directly applying Newman's stability patterns.
- 12-factor compliance audit: Deploy a sample app to a cloud platform (AWS, GCP, or Azure) and audit it against Davis's cloud-native checklist: externalized config via environment variables, stateless processes, health-check endpoints, and graceful shutdown. Document every violation and fix it.
- Serverless event pipeline: Following Davis's event-driven patterns, build a serverless pipeline (e.g., AWS Lambda or Google Cloud Functions) triggered by object storage events that transforms and forwards data — measure cold-start latency and design a mitigation strategy.
- Terraform module library: Using Brikman's module patterns, write a reusable Terraform module for a standard 'web service' unit (VPC, load balancer, auto-scaling group or managed container service, IAM roles). Parameterize it for dev/staging/prod environments using workspaces or separate state files.
- Full-stack IaC + cloud-native deployment: Provision the infrastructure for your microservice pair from Exercise 2 entirely with Terraform (from Exercise 5's modules), deploy the services as containers with externalized config (Exercise 3's lessons), and wire up a CI/CD pipeline — treating the entire system as a reproducible, version-controlled artifact.
Next up: Mastering cloud-native architecture patterns, microservice design, and infrastructure-as-code gives you the production system design vocabulary needed to tackle the next frontier: advanced reliability engineering, observability at scale, and platform engineering — where the focus shifts from building systems to operating and continuously improving them under real-world load.
The definitive guide to decomposing applications into independently deployable services; directly applies Kubernetes and distributed systems knowledge to real architectural decisions.
Focuses specifically on the patterns — dynamic configuration, service discovery, circuit breakers — that make applications truly cloud-native rather than just cloud-hosted.
Closes the curriculum by teaching infrastructure-as-code with Terraform, the industry-standard tool for provisioning and managing cloud resources repeatably and at scale.
Discussion
Keep reading
Paths that share books, cover the same subject, or open a related topic.
