Cloud-native applications
Concept · Chapter 8
The idea in brief
Section titled “The idea in brief”- Deploying to the cloud does not make an app cloud-native. It’s about how the software is designed and implemented, not just where it runs.
- Cloud-native applications are designed and built from the ground up for the cloud, so they can fully exploit their deployment environment.
- Requires closer collaboration: developers must care how their app runs in production; operations must partner with dev to improve deployment over time (see DevOps practices).
Why enterprises move to the cloud
Section titled “Why enterprises move to the cloud”- Reducing costs — cuts capital expenditure (no hardware/software to buy) and operational expenditure (less IT staff, power, cooling).
- Flexibility & scalability — scale up/down fast on demand; global scale from providers, delivering the right compute in the right place; grow without major hardware changes.
- Automatic updates — provider handles software, security, and hardware updates (servers, memory, CPU, disk) with latest-generation data centers.
- Disaster recovery — backup, DR, and business continuity made easy and cheap, even for small businesses (see Migrating to the cloud).
CNCF definition — three pillars
Section titled “CNCF definition — three pillars”The Cloud Native Computing Foundation (CNCF) defines cloud-native as an open-source software stack producing applications that are:
- Containerized — each part packaged with all its libraries/dependencies in a lightweight, immutable, standalone package. Like standardized shipping containers, this gives predictability (“runs the same anywhere that supports containers”), eliminating “works on my machine”. Each part of the system gets its own container for reproducibility and resource isolation.
- Dynamically orchestrated — containers alone aren’t enough; you must run multiple containers across multiple machines and orchestrate them: start the right container at the right time, scale by adding/removing, and relaunch on other machines on failure. Tools: Kubernetes (K8S) (most popular; open-source, from Google), Docker Swarm, Apache Mesos. Managed services: Amazon ECS, Amazon EKS, AWS Fargate, Azure AKS, Google Kubernetes Engine.
- Microservices-oriented — partition the app into small, autonomous, independently versioned, self-contained services for agility and maintainability (see Microservice architecture).
Additional expectations of modern apps
Section titled “Additional expectations of modern apps”- No downtime — always-available; design for failure with fault tolerance. Failover redirects traffic; loosely coupled, redundant components take over. A single failure should be isolated, not down the whole system.
- Continuous delivery — shorter release cycles (days/weeks, not months) → tighter feedback loops and faster response to users, market, and competitors — a competitive advantage.
- Support for a variety of devices — mobile, desktop, tablets, IoT; unified experience across devices; backends must serve many frontends and large data volumes via highly distributed design.
Twelve-factor app methodology
Section titled “Twelve-factor app methodology”A set of principles (originally from Heroku’s creators; Adam Wiggins, The Twelve-Factor App) for building cloud-deployable apps. Conforming to the contract makes apps predictable, portable, scalable, and continuously deployable.
| Factor | Principle |
|---|---|
| Codebase | One codebase in version control, many deployments |
| Dependencies | Explicitly declare and isolate (with exact versions) |
| Configuration | Store config in the environment, not the code |
| Backing services | Treat as attached resources, attachable/detachable without code changes |
| Build, release, run | Strictly separate the stages; release = immutable, uniquely identified artifact |
| Processes | Execute as one or more stateless, share-nothing processes |
| Port binding | Self-contained; export services via port binding (one app can back another) |
| Concurrency | Scale out horizontally via the process model |
| Disposability | Fast startup, graceful shutdown; robust against crashes |
| Dev/prod parity | Keep environments as similar as possible (e.g. via containers) |
| Logs | Treat logs as event streams to stdout/stderr; let the environment route them |
| Admin processes | Run one-off admin tasks against the same code/config as production |
- Processes → no sticky sessions; cache via a distributed store (Redis, Memcached) instead of in-process memory.
- Logs → app doesn’t manage log files; the execution environment captures and routes the stream (see Cross-cutting concerns).
Related concepts
Section titled “Related concepts”Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.8 “Cloud-native applications”, pp. 663-688.