Cloud Physics & Reliability Engineering
Mastering the cloud execution model, elasticity, software-defined networking, and quantifying failure with SLOs.
The Cloud Execution Model
In traditional infrastructure, servers are capital expenditures (CapEx)—expensive, static physical assets. The Cloud Execution Model shifts compute to an operational expenditure (OpEx), offering the illusion of infinite, on-demand resources.
However, “the cloud” is ultimately just someone else’s computer. It is built on massive fleets of cheap, commodity hardware that is statistically guaranteed to fail. The architectural shift is moving from Scale-Up (buying a massive $100,000 server that never goes down) to Scale-Out (renting 1,000 cheap servers and architecting the software to survive when 50 of them catch fire).
- Scalability: The ability of a system to handle increased load by adding resources.
- Elasticity: The ability of a system to automatically provision and de-provision resources in real-time to match fluctuating demand, minimizing cost.
Cloud Storage Systems: Block vs. Object
Storing data at cloud scale requires choosing the correct abstraction based on latency and mutability requirements.
- Block Storage (e.g., AWS EBS): The cloud equivalent of a physical hard drive plugged into a server. Data is stored in fixed-size blocks. It offers ultra-low latency and allows for partial file updates (e.g., modifying a single row in a database). However, it is tightly coupled to a single computing instance (or AZ) and is highly expensive.
- Object Storage (e.g., AWS S3): Data is stored as a complete, immutable object (the file + metadata) in a flat, globally distributed namespace. It is infinitely scalable and incredibly cheap, but it operates over HTTP.
Software-Defined Networking (SDN)
In a physical datacenter, changing a network route requires an engineer to physically plug a fiber optic cable into a Cisco router. In the cloud, the network is entirely virtualized through Software-Defined Networking (SDN).
SDN separates the Control Plane (the software making routing decisions) from the Data Plane (the physical switches moving the packets). This allows engineers to declare complex network topologies—Virtual Private Clouds (VPCs), subnets, NAT gateways, and firewalls (Security Groups)—purely through code (Infrastructure as Code, like Terraform), dynamically isolating blast radii at the network level.
Cloud Reliability Engineering (SRE)
Because cloud hardware constantly fails, Site Reliability Engineering (SRE) dictates that 100% uptime is not only impossible, it is the wrong engineering target. Pushing for 100% uptime halts all feature velocity.
Instead, engineers use a data-driven framework to balance reliability with innovation:
- SLI (Service Level Indicator): A direct, quantitative measurement of system health (e.g., “The percentage of HTTP 200 responses in the last 5 minutes”).
- SLO (Service Level Objective): The internal engineering target (e.g., “99.9% of all API requests will return successfully in under 200ms over a 30-day window”).
- SLA (Service Level Agreement): The legal and financial contract with the customer. If the SLA is breached, the company owes the customer money. (e.g., “99.9% uptime”). The SLO must always be stricter than the SLA.
If a system is meeting its SLO, the engineering team has an Error Budget. They can freely deploy new, risky features. If the SLO is breached, the error budget is exhausted, and all feature work must halt until reliability is restored.