Cloud-Native and Infrastructure Architecture

Welcome to Chapter 10, Cloud-Native and Infrastructure Architecture. For most of the history of software, infrastructure came after the architecture: an operations team received a finished application and found servers to run it on. That separation has gone. Today the choice between virtual machines, containers, platforms and functions decides much of the cost. The number of availability zones and regions decides the availability. And the deployment pipeline decides how quickly and safely a team can change anything.

This chapter is for developers and architects who want to choose, justify and run the platforms their systems depend on, without being sold a stack. It builds on Chapter 0, which introduced servers, virtual machines, containers, cloud service models, regions and availability zones, and on Chapter 9, which explained how to make systems scale, degrade gracefully and stay observable. Here those ideas meet the platforms most systems now run on. Decisions about where and how software runs are expensive to reverse, they cut across every team, and they fix the quality attributes that Chapter 2 asked you to specify. And Chapter 11 follows, with how to judge an architecture, including its infrastructure, and how to change it safely over time.

The running example is the food delivery platform used throughout the course: customer and restaurant apps, an order service, menus, payments, courier dispatch, and a sharp evening rush. The first four sections are about the foundations. Section ten point one sets out who manages what, from infrastructure as a service, or IaaS, through PaaS and functions, to SaaS. Under the shared responsibility model, your data, identities and configuration are always your job. Section ten point two explains container images, the Kubernetes control plane and nodes, and the reconciliation loop at its heart. It is also honest about when Kubernetes is overkill. Section ten point three walks through all twelve factors of the twelve-factor app, with modern caveats, and shows how to audit an existing service against them. Section ten point four covers infrastructure as code: declarative tools, state and drift, modules, immutable infrastructure, GitOps, policy as code and testing.

The single most important idea in this chapter is declared desired state, continuously reconciled by automation. This diagram from Section ten point two shows how Kubernetes does it. You declare the desired state. Here, three replicas of version two point four of the orders service. A controller observes the actual state of the cluster, and finds only two pods running. It compares what it sees with what was declared, and finds one pod missing. So it acts, and asks for one new pod. The loop repeats on every change event, and periodically. Because it acts on the current difference, not on a remembered sequence of events, missed events and restarts do no lasting harm. The same idea runs through infrastructure code, GitOps, deployment pipelines and immutable infrastructure. A person changes a description, which is reviewed, versioned and auditable, and machines do the rest.

The second four sections are about change, scale, people and money. Section ten point five follows a change from commit to production through a CI/CD pipeline, compares rolling, blue-green, canary and shadow deployments, and separates deployment from release with feature flags. Section ten point six compares disaster recovery strategies, explains what replicating data across regions does to consistency, and covers cell-based architecture and edge functions. Section ten point seven treats the internal developer platform as a product, with golden paths and guardrails, and shows how to measure whether it helps. And Section ten point eight turns cost into an architectural quality, measured per order, and treats vendor lock-in as a trade-off to be priced rather than a sin to be avoided.

The second idea is that every option in this chapter is a trade-off. This diagram from Section ten point six shows four disaster recovery strategies side by side. Each is judged by two numbers that come from the business: the recovery time objective, or RTO, how long you may be down, and the recovery point objective, or RPO, how much data you may lose. With backup and restore, backups are copied to a recovery region where nothing runs. Recovery takes hours, and you lose everything since the last backup. With a pilot light, data is replicated but the application servers are off. With a warm standby, a small working copy already runs and scales up. Recovery time falls to tens of minutes, then to minutes. With active-active, a full second region is already serving traffic, and both numbers are near zero. Each step to the right buys faster recovery and less data loss, at a higher continuous cost and complexity. The right choice depends on the workload and the organisation.

By the end of the chapter, you will be able to compare the cloud service and deployment models, and assign the duties for a workload under the shared responsibility model. You will understand how Kubernetes maintains a declared desired state, and be able to judge when it is overkill. You will be able to choose between rolling, blue-green, canary and shadow deployments, and use feature flags to separate deployment from release. And you will be able to calculate unit costs, such as cost per order, and evaluate lock-in as a priced trade-off.

Each section can be read on its own, but the order is deliberate. You cannot reason about deployment strategies without knowing what Kubernetes does during a rollout. If you are new to operations, read the beginner boxes, and Chapter 0's section on servers and the cloud, first. Don't worry about memorising tool names. Products change every few years, while the mechanisms last. Vendors are named as examples, not recommendations. At the end of each section there are self-check questions. Answer them in your head before you look at the answers. Allow about three hours to read the whole chapter. When you are ready, there is an optional chapter test of about forty five minutes, with twenty multiple choice questions and two written answers. The pass mark is eighty per cent.

That is the shape of the chapter. Start with Section ten point one, on cloud service and deployment models, and who is responsible for what. See you there.