Before understanding what the cloud solves, you need to understand how networked computing used to work (and still does). Almost everything you use daily—a website, a mobile app, email—relies on a very simple idea called the client-server model.

The idea in one sentence

There is a program that requests things (the client) and another program that responds to those requests (the server).

The client and the server are two roles, not necessarily two different machines. But in practice, they are usually on different computers connected by a network.

A real-world analogy: the restaurant

Imagine a restaurant:

  • You (the client) sit down and order a dish from the waiter.
  • The kitchen (the server) receives the order, prepares the dish, and delivers it to you.
  • You don’t need to know how the kitchen is organized, what stoves they use, or where they buy the ingredients. You just order and receive.

In computing, it works exactly the same way:

  • Your browser (client) requests a page: “give me https://store.com/products”.
  • The web server receives the request, looks up the data, generates the HTML, and sends it back to you.
  • You don’t know (nor need to know) if there’s one or a hundred computers behind it.

What it looks like technically

When you open a website, this happens, simplified:

[Your browser]  --- HTTP request --->  [Web server]
   (client)                              (server)
[Your browser]  <--- HTML response ---  [Web server]
  1. You type a URL.
  2. Your browser makes a request using the HTTP protocol.
  3. The server processes that request (sometimes queries a database).
  4. The server returns a response with the content.
  5. Your browser renders it on the screen.

Everyday example you already use

When you open WhatsApp Web:

Role Who What they do
Client The browser on your laptop Requests new messages
Server WhatsApp’s computers Store and deliver the messages
Network Internet Transports the requests and responses

Your laptop does not store the entire conversation history of all users in the world: it only requests the part you’re interested in. The heavy lifting is done by the server.

The traditional “physical” server

For decades, setting up a service on the internet meant buying or renting a physical computer (a server) and putting it in a room with:

  • Air conditioning so it doesn’t overheat.
  • Redundant internet connection.
  • Power systems with batteries in case the power goes out.
  • Someone to watch over it and fix it when it breaks.

This room is called a datacenter. A company that wanted its website “always on” had to take care of all this itself. This is called having on-premise infrastructure (on your own premises), and we’ll look at it in detail in subchapter 1.3.

Why this matters for the cloud

The client-server model does not disappear with the cloud: it’s the foundation of everything. What changes with the cloud is who provides and maintains the server.

  • Before: you bought, set up, and maintained the physical server.
  • With the cloud: you rent the server (or just the capacity you need) from a provider like AWS, and they take care of the hardware, the room, the air conditioning, and the electricity.

In other words: the “server” role still exists, but it’s no longer your physical problem. That’s exactly what we’re going to explore in the rest of the book.

What you should remember

  • The client requests and the server responds: it’s the foundation of the internet.
  • Client and server are roles, usually on different machines connected by a network.
  • A traditional physical server requires space, energy, cooling, and maintenance.
  • The cloud does not eliminate the client-server model: it just changes who takes care of the server.

In the next subchapter, we’ll look at the specific problems this traditional approach had and that gave rise to the cloud.

Cloud, AWS & Terraform — From Zero to Expert

Chapter 1 · What is cloud computing

Chapter 2 · The cloud market and major providers

Chapter 3 · Regions, availability zones and edge

Chapter 4 · Compute: EC2

Chapter 5 · Storage: S3

Chapter 6 · Networking: VPC

Chapter 7 · Identity and access: IAM

Chapter 8 · Managed databases

Chapter 9 · Why Infrastructure as Code

Chapter 10 · HCL: the Terraform language

Chapter 11 · Providers and state

Chapter 12 · Your first real infrastructure in Terraform

Chapter 13 · Load balancing and auto scaling

Chapter 14 · Serverless with Lambda

Chapter 15 · Messaging and events

Chapter 16 · Content delivery and DNS

Chapter 17 · Containers on AWS

Chapter 18 · Modules: reuse and composition

Chapter 19 · Workspaces and environment management

Chapter 20 · Remote backends and locking

Chapter 21 · Infrastructure testing

Chapter 22 · Terraform in CI/CD

Chapter 23 · Defense in depth

Chapter 24 · Observability: logs, metrics and traces

Chapter 25 · Cost optimization

Chapter 26 · High availability and disaster recovery

Chapter 27 · AWS Well-Architected Framework

Chapter 28 · Serverless architectures at scale

Chapter 29 · Data platforms on AWS

Chapter 30 · Multi-account and landing zones

Chapter 31 · Platform Engineering and Internal Developer Platform

Chapter 32 · Relevant AWS certifications

Chapter 33 · Projects to consolidate what you've learned

Chapter 34 · Resources and community

© Copyright 2024. All rights reserved