Running on the cloud is not the same as being cloud native
Imagine you rent a flat in a modern high-rise society in Pune — one with a lift, 24×7 water backup, security guards and power backup for every floor. If you move in but keep using a diesel generator you dragged from your old bungalow, never use the lift, and store your own water in drums — you're technically "in" the building, but you're not using anything the building was built to give you.
That's most "cloud" apps before they become cloud native. A cloud native app is built, from day one, to actually use what cloud infrastructure gives you: the ability to add more servers in seconds, to survive a server dying without anyone noticing, and to update software without switching it off. It's an approach to building, deploying and running software — not tied to any one provider like AWS, Azure or GCP.
Tap each promise to see the plain-language version. The rest of this article walks through how each one is actually delivered.
The dock grows more berths on a busy day, and shrinks back after
Picture a container port. On a normal Tuesday, 4 berths handle every ship that arrives. But right before a big festival — say, the week before Diwali — three times as many ships show up loaded with goods. A well-run port doesn't turn ships away; it opens more berths, brings in more cranes, and once the rush passes, quietly closes them again so it isn't paying for idle cranes all year.
An e-commerce app behaves the same way. On a normal day 4 running copies ("instances") of the checkout service are enough. During a flash sale, traffic can jump 5–10x in minutes. A cloud native app is built to notice that jump and scale out — add more instances automatically — and later scale in once the rush is over. Elasticity is this ability to grow and shrink; scalability is the ceiling on how far it can grow at all.
Drag the traffic slider up to festival-sale levels and watch the port open new berths — computed live from the formula above, not pre-drawn.
One big crate vs. many small, labelled crates
Old-style apps are often built as one giant program — a monolith — where the login page, the catalogue, the cart and the payment logic are all bundled into a single deployable unit. Change one line in the payment logic, and you have to rebuild, retest and redeploy the entire application.
A cloud native app instead breaks the same functionality into small, independent services — microservices — each one its own labelled crate: a "cart service", a "catalogue service", a "payment service". Each crate has its own code, its own release schedule, and can be picked up, upgraded and put back down without touching any other crate on the dock. This independence is what lets one team ship a payment-service fix on a Tuesday afternoon without anyone re-testing the whole website.
A joint family cooking together in one kitchen (a monolith) is efficient until someone wants to change the recipe — everyone's meal is affected. A tiffin service (microservices) has separate cooks for dal, sabzi and roti; each can change their recipe, fall sick, or get replaced, without stopping the others from delivering their box on time.
Each crate below is a microservice with its own version. Click "Ship update" on any one — notice the others don't even blink.
Never repaint the ship at sea — swap it for a new one
Old-school deployment logs into a running server and edits it in place: patch this file, restart that process. It works, but every such server slowly becomes a unique, hand-tweaked snowflake that's hard to reproduce — and usually needs a moment of downtime to restart.
Immutable infrastructure takes the opposite approach: you never modify a running container. Instead you build a brand-new container image with the update baked in, and let it stand up next to the old one. Once the new one is healthy, traffic is switched over and the old one is destroyed. Kubernetes does this automatically during a rolling update — a few new copies come up, get proven healthy, take over traffic, and only then are the old copies retired — so there is no window where the service is "down for maintenance."
Currently serving: App v1.0 on 3 instances — 0% downtime so far.
One crane breaking down shouldn't shut the whole port
Failures are not an edge case in distributed systems — they're a certainty. A server will die, a network link will flicker, a whole cloud region can go down for a few hours. Resiliency is not about preventing failure; it's about designing so that one failure doesn't cascade into every failure.
Concretely: if the payment microservice on an e-commerce site goes down, a resilient system doesn't crash the entire checkout page — it catches the failure (often via a pattern called a circuit breaker), shows a graceful "payments are temporarily delayed, please retry" message, and keeps the catalogue and cart working normally for everyone else.
Click Microservice C to simulate a failure, then see how the request path reacts — and how many "nines" of availability that failure pattern works out to over a year.
The gate matters as much as the cranes
A port with the fastest cranes in the world is still useless if anyone can walk in and swap the contents of a container. Cloud native security means every microservice proves who it is before talking to another (usually via short-lived certificates, not shared passwords), every request is encrypted in transit, and traffic in and out of the cluster is checked at a clearly defined gate rather than trusted by default.
This matters most for e-commerce and fintech-style apps where fraud detection, payment data and personal information move between dozens of independent microservices every second — a single unguarded gate is enough to compromise the lot.
Containers are the crate, Kubernetes is the port authority, the mesh is the radio channel
Put the ideas above into real technology and three layers do almost all the work:
The smallest unit of compute. A container packages one microservice together with just enough of an operating system to run it — so it behaves identically on a developer's laptop, a test server, or production. Docker is the tool most commonly used to build and run these.
The "port authority." It decides which physical server each container runs on, restarts a container that crashes, performs rolling updates, and scales the number of copies up or down as traffic changes — all without a human clicking anything.
Neither of those two, on their own, manages how microservices talk to each other — for that, cloud native apps add a service mesh.
Toggle the mesh on and off to see what changes about the path a request takes between two microservices.
A service mesh runs a lightweight proxy alongside every microservice. Every request quietly passes through this proxy first — which is where encryption (mTLS), retries, circuit breaking and traffic metrics all get applied consistently, without any microservice's own code having to implement them. Istio is the best-known example; Dapr offers similar capabilities and adds more building blocks for the microservice's own runtime logic too.
Every technical promise above is really a cost argument
None of elasticity, resiliency or independence survive a budget review unless they translate into money. And they do, directly: elasticity means you pay for extra capacity only during the festival-sale week, not all year; independence means smaller, faster-moving teams instead of one large team blocking each other; no-downtime deploys mean lost-sales-from-an-outage stops being a recurring line item.
The CNCF landscape — a large, constantly growing map of open-source projects (Kubernetes, Istio, Argo, Prometheus, OpenTelemetry, and hundreds more) — exists precisely so a team doesn't have to build any of this from scratch. The real skill isn't knowing that the landscape exists; it's picking the small subset of it that actually fits your app's requirements.
The whole article, in one dock
Every idea above maps to one working part of a shipping port — carry this picture forward and the jargon mostly falls away on its own.
Elasticity & scalability
Open more berths as traffic rises, close them after — automatically.
Independence & microservices
Small, separately-shippable crates instead of one giant, all-or-nothing cargo hold.
No downtime & resiliency
Swap ships instead of repainting at sea; isolate failures instead of letting them cascade.
Security
Every crate proves who it is at the gate and on every internal call — usually via the mesh, not hand-written per service.
Next in this series: how Dapr extends the service-mesh idea further into the microservice's own runtime — state management, pub/sub and bindings included.
Comments
Comments and likes aren't connected to a backend yet — check groundwork-config.js. They'll still work on this screen, but won't be saved or shown to other visitors until that's done.