A Cloud Native book becomes valuable when it ties containers, functions, and data services into one operating picture instead of a pile of separate technologies.
In real design work, the chapter shows how to assemble application architecture for a concrete workload, choose a sensible level of abstraction, and evaluate the design through delivery speed, failure radius, and post-launch operating simplicity.
In interviews and engineering discussions, it helps frame cloud architecture through platform boundaries, SLA commitments, and cost of ownership rather than through a list of fashionable tools.
Practical value of this chapter
Design in practice
Connect containers, functions, and data services into one application architecture for real workloads.
Decision quality
Evaluate architecture through delivery speed, failure radius, and post-launch operating simplicity.
Interview articulation
Structure answers as platform decomposition: compute, data, messaging, observability, and security.
Trade-off framing
Explain how to choose abstraction level without losing SLA and cost control.
Related book
Building Microservices
Sam Newman on service boundaries, communication, and the cost of distribution.
Cloud Native
Authors: Boris Scholl, Trent Swanson, Peter Jausovec
Publisher: O'Reilly Media, 2019
Length: 229 pages
O'Reilly's practical guide to Cloud Native: containers, functions, data, resilience, GitOps, and observability.
Related chapter
Kubernetes Fundamentals
A practical overview of Kubernetes architecture, objects, and baseline practices.
What cloud-native architecture means
Cloud Native does not mean “we rented a VM and moved the same service onto it.” It means the application is designed up front for automation, elasticity, managed services, and partial failure — so it survives a node restart or a move between environments without manual intervention.
Key characteristics
- The application is packaged as a container image and does not depend on manual setup on a specific machine.
- Infrastructure is described declaratively, from APIs to deployment policy.
- State moves into backing services, while application processes stay stateless.
- The platform handles scaling, restart, routing, and observability signals.
Practical value
- Ship changes faster without manual server operations.
- Scale services around actual workload shape rather than pre-purchased hardware.
- Isolate failures and reduce blast radius through platform boundaries.
- Collect operational signals early: logs, metrics, traces, and readiness checks.
Documentaries
Book structure
Cloud-native context
The book defines the language: cloud-native architecture, distributed-system challenges, The Twelve-Factor App, and the boundary teams often blur — an app designed for the cloud behaves differently from one merely lifted into it.
Application and platform patterns
Containers, orchestration, service communication, resilience, and patterns for surviving network failures and partial outages.
Data in cloud architecture
Data ownership, events, stream processing, CQRS, and Event Sourcing: data becomes part of a distributed contract, not just tables behind a service.
Delivery, security, and operations
The final chapters connect CI/CD, GitOps, observability, and security into one operating model.
Containers and Kubernetes
Deep dive
Kubernetes Patterns
A pattern catalog for Kubernetes: sidecars, health probes, configuration, and advanced patterns.
Containers
- Application isolation through namespaces and cgroups.
- Immutable images make execution reproducible.
- A layered filesystem makes builds and image distribution more efficient.
- Container registries store versions that the platform can deploy.
Core Kubernetes objects
- Pod is the smallest execution unit.
- Service gives a stable network address for a group of Pods.
- Deployment handles declarative updates and rollbacks.
- ConfigMap / Secret carry configuration and sensitive values.
# Kubernetes Deployment example
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
spec:
containers:
- name: my-app
image: my-app:v1.2.0
resources:
limits:
memory: "256Mi"
cpu: "500m"Serverless functions
The serverless model takes server management off the team: the platform spins instances up and down under load and charges only for actual invocations. The price for that convenience is someone else’s rules — hard limits on time, memory, and networking, plus a lock-in to how the platform delivers events.
AWS Lambda
Function as a Service, event triggers, AWS integrations, and bounded execution time.
Azure Functions
Functions and Durable Functions for long-running workflows that must hold state between steps and bind to platform events.
Google Cloud Functions
HTTP triggers, event triggers, and Cloud Run when a container-based option is a better fit.
When it fits
- Event-driven processing for small independent tasks.
- API handlers with variable load.
- Scheduled jobs for background operations.
- Data transformation pipelines without a dedicated processing server.
Constraints
- Cold-start latency on rare or heavy invocations.
- Limits on execution time and resource size.
- Stateless processes by default.
- Vendor lock-in to a provider’s event model.
Data management
Deep dive
Designing Data-Intensive Applications, 2nd Edition
DDIA on replication, sharding, and consistency guarantees in distributed systems.
Database per service
A service owns its data instead of sharing one schema with every neighbor. Coupling drops, but the cost is immediate: distributed transactions no longer rest on a single database, and the consistency model becomes something you choose explicitly rather than inherit from the DBMS.
Event-driven architecture
Services publish events and react to them asynchronously — processing scales because the sender does not wait for the receiver. The same asynchrony also delivers events twice and out of order, so without idempotency, replay, and durable event schemas it quietly drifts into inconsistency.
Event Sourcing
Store the history of events, not only current state
CQRS
Separate write commands from read queries
Resilience patterns
Classic
Release It!
Michael Nygard introduced the Circuit Breaker and other stability patterns.
Retries with backoff
Retries help with transient failures, while exponential backoff and jitter reduce the risk of a thundering herd.
Circuit breaker
A circuit breaker stops sending requests to a degraded service and protects the system from cascading failure.
Health checks
A liveness probe answers whether the process is alive; a readiness probe answers whether traffic can be sent to it.
Bulkhead
Bulkheads contain failure propagation: one pool, queue, or dependency should not take down the whole system.
DevOps and observability
Related book
Site Reliability Engineering
SRE practices for SLOs, incidents, and reliable operation of cloud platforms.
Delivery practices
GitOps
Git acts as the source of truth for infrastructure and platform changes.
Canary release
A canary release exposes the new version to a small slice of traffic and compares it against metrics.
Blue-Green
Blue-green deployment keeps two environments and switches traffic between them.
Three pillars of observability
Logs
Structured logging, ELK or Loki, and correlation IDs for finding the full request chain.
Metrics
Prometheus, Grafana, and RED/USE methods for load, errors, and resource saturation.
Traces
Distributed tracing through Jaeger, Zipkin, or OpenTelemetry shows the path of a request across services.
Using this on system design interviews
Useful concepts
- Container orchestration with Kubernetes.
- Serverless for event-driven processing.
- Database per service and explicit data ownership.
- Circuit breakers, retries, and health checks.
- Graceful shutdown and stateless execution.
- Observability: logs, metrics, and traces.
Where it helps
- “How would you deploy and scale the service?”
- “How would you survive partial failures and dependency degradation?”
- “How would you observe a distributed system in production?”
- “How would you choose storage and data boundaries for a microservice?”
- “How would you implement event processing without retry chaos?”
Key takeaways
Related chapters
- Why know Cloud Native and 12 factors - A framing chapter on why cloud-native thinking matters for system design and platform architecture.
- The Twelve-Factor App - Foundational principles for portable applications: configuration, processes, build/release/run, and dev/prod parity.
- Containerization - Container runtime fundamentals: images, isolation, and portability as the base for cloud operations.
- Kubernetes Fundamentals (v1.36): architecture, objects and baseline practices - How orchestration manages scaling, resilience, and the lifecycle of application workloads.
- Infrastructure as Code - Declarative infrastructure management and repeatable delivery for production environments.
- GitOps - An operating model where Git becomes the source of truth for deployments and platform changes.
- Serverless Architecture Patterns - Where Function as a Service takes operations off the team, and where it charges that back as platform constraints and lock-in to its event model.