Deployment patterns and Kubernetes
The deployment patterns from packages to containers, running on Kubernetes, and releasing safely.
key idea / coordinatorservice / good pathin progress / watch outproblem / failureneutral
How deployment changed
With hundreds of services, only automated, lightweight deployment is workable.
Principles of deployment
Whatever platform you pick, five principles hold. From Building Microservices, ch. 8.
| Principle | Why it matters |
|---|---|
| Automation | More services mean more moving parts. Gilt went from about 10 services after a year to over 450 in 2014, driven by tooling that let developers self-serve. |
| Infrastructure as code | Machine-readable config in source control gives an audit trail and lets you recreate an environment as of a date. One client spent months rebuilding an old system for a court case. |
| Zero-downtime deployment | Consumers should not notice a release, so teams can ship in working hours. Async middleware makes it easy; otherwise use rolling upgrades or blue-green. Kubernetes only for this is overkill. |
Four deployment patterns
Each step up hides more of the machine from you.
| Pattern | Benefits | Drawbacks |
|---|---|---|
| Language package (JAR/WAR) | Fast deploy, shares resources | No isolation, no resource limits, ops must know the runtime |
| Virtual machine (AMI) | Stack encapsulated, isolated, mature cloud | Heavy, minutes to build and boot, patch the OS |
| Container (Docker) | Encapsulated, isolated, limited, starts fast | You patch images and run the platform |
| Serverless (Lambda) | No servers, elastic, pay per request | Cold starts, limited to short functions |
Kubernetes
A Docker orchestration framework that turns many machines into one pool.
From Docker to Kubernetes in practice
Bootstrapping Microservices walks the whole road with one example app. Package it, publish it, then run it on a cluster. From Bootstrapping Microservices, ch. 3, 4 and 6.
| Tool | Used for |
|---|---|
| Docker Compose | Run the whole app on your computer while developing and testing. It simulates the cluster without the weight. |
| Local Kubernetes (Docker Desktop) | Learn and rehearse a deployment: switch it on, apply, test, delete. |
| Managed Kubernetes (for example Azure) | Production. A few clicks, or Terraform code, give you a cluster with a container registry attached. |
A bare pod is not enough for production. A deployment keeps the chosen number of pods running, and a service gives them one stable address. Each pod here hosts one container, though a pod can host several (the sidecar pattern).
Infrastructure as code with Terraform
Clicking through a cloud portal does not repeat. Terraform is a language and tool for describing cloud infrastructure, and it is executable documentation that cannot go out of date. From Bootstrapping Microservices, ch. 7.
Grow the code in small steps: a resource group first, then the container registry, then the Kubernetes cluster, sharing settings through variables. Outputs expose values such as the registry address, but avoid outputting passwords, since they land in plain text in the state file.
Kubernetes: limits and when to use it
An orchestrator decides where containers run and keeps the desired state true, so you do not script it by hand. Kubernetes won this space, but it has limits. From Building Microservices, ch. 8.
| Tool | Role |
|---|---|
| Helm | A package manager: install third-party software such as Kafka |
| Operator | Manages the ongoing life cycle, such as upgrades. Can be used with Helm. |
| CRD | Custom resource definition: extend the Kubernetes API with your own object types |
Safe releases
Roll out without downtime, then release gradually.
Progressive delivery
Progressive delivery is continuous delivery with fine-grained control over the blast radius. It rests on one idea: deployment (installing a version) is not release (users get it). From Building Microservices, ch. 8.
| Technique | Idea | Note |
|---|---|---|
| Blue-green | Run the new version beside the old, check it, then switch traffic | Simple zero-downtime option |
| Feature toggle | Hide deployed code behind a switch | Supports trunk-based work. Start with a config file. |
| Canary release | A small subset sees the new version, then widen | Tools such as Spinnaker can ramp up on error rates |
| Parallel run | Send each request to both versions and compare | Only one result is used |
Recap
- Four patterns: language package, VM, container, serverless.
- Containers give isolation and resource limits while starting in seconds.
- Kubernetes keeps the desired number of healthy pods and rolls out new versions.
- A service mesh separates deployment from release with traffic routing.
- Deploy with isolation, automation, infrastructure as code, zero downtime and desired state management. GitOps applies this to Kubernetes.
- Compose for local development, Kubernetes for production, Terraform to create the infrastructure, GitHub Actions to deploy. Consider managed clusters or FaaS before running your own Kubernetes.
- Separate deployment from release: blue-green, feature toggles, canary and parallel runs. Prefer a repo per service at scale.
Quick check
Show answer
Readiness only shows the pod started. A bug that appears under real traffic would still spread. Istio lets you test v2 with test users, then shift traffic slowly and revert at once.