Making the case for Kubernetes

Every growing software organization reaches the point where releases depend on the two people who know which server runs what, crashed processes sit dead until someone notices, and every team ships its own way. Nothing is broken, exactly; everything is held together by memory.

Kubernetes is the industry's standard answer to that point. It is also a real commitment, with real costs, and it is the wrong answer for plenty of teams. This piece is written the way the case should be made to an architect or a leadership team: what it is in plain terms, what it buys, what it costs, where it fits, and a way to find out with a small, reversible bet.

To

Architecture review and engineering leadership

From

Engineering

Subject

Running services on Kubernetes

Ask

Approve a time-boxed pilot: one service on managed Kubernetes, measured against today, with a go or no-go review at the end.

Most systems start the same way: an app goes on a server, then another app goes on another server, and each one gets set up by hand. That works for a long time. The cost shows up slowly, as symptoms:

• Deploys are rituals. A release is a checklist someone runs, and it goes differently when a different person runs it.
• Servers become irreplaceable. Each one has a history of small fixes nobody wrote down. Rebuilding one is a project.
• Failures wait for a person. When a process dies at 2 a.m., it stays dead until an alert wakes someone up.
• Capacity is guesswork. Some machines run hot while others sit idle, because apps were placed where there was room at the time.
• Every team ships differently. Each new service invents its own deploy, its own logging, its own way to roll back.

None of these symptoms is fatal on its own. Together they are a tax on every release and every incident, and the tax grows with each new service and each new team.

Kubernetes is open-source software that runs applications across a group of machines and treats the group as one computer. Google released it in 2014, based on the systems it used to run its own services, and it is now maintained by a large vendor-neutral community under the Cloud Native Computing Foundation. Every major cloud sells it as a managed service, and it runs just as well in a company's own data center.

The one idea worth understanding is desired state. Instead of running steps ("start this app on that server"), the team writes down the end result ("three copies of the web app, version 2.4, always"). Kubernetes then watches the real world and keeps it matching what was written. If a copy crashes, it starts another. If a machine dies, it moves the work. If the team changes the version, it rolls the new one out a few copies at a time.

Five words cover most conversations about it:

Container

An app packaged with everything it needs, so it runs the same on a laptop, in test and in production.

Cluster

The pool of machines Kubernetes manages as one.

Node

One machine in that pool. Nodes are interchangeable; none of them is special.

Deployment

The written-down instruction for one app: which version, how many copies, how to roll out a change.

Service

A stable address for an app, wherever its copies happen to be running.

A fair proposal puts both columns on the same page. The left side is what the organization gets. The right side is what it pays, and most of that payment is people and attention, not licenses.

What it buys

It heals itself

Crashed apps restart and failed machines are routed around, with no 2 a.m. page.

Every service ships the same way

One deploy process, one rollback, one place to look. New services start from a template.

Releases get smaller and safer

Rolling updates replace a few copies at a time, and a bad version rolls back with one command.

Capacity follows demand

Apps add copies under load and shed them after. Shared machines usually means fewer machines.

Environments match

Dev, test, staging and production are described the same way, so "it worked in staging" means something.

Less lock-in

The same definitions run on AWS, Azure, Google Cloud or company servers. Identity, load balancers and storage still differ per cloud, so moving is work, but not a rewrite.

A standard, not a snowflake

A large tool ecosystem and a common skill set that hires and vendors already have.

What it costs

A learning curve

New concepts for every app team, and a steeper climb for whoever runs the platform.

Someone has to own it

A person or team accountable for the cluster, its upgrades and its guardrails.

A steady upgrade cycle

Kubernetes ships about three releases a year, and each gets roughly a year of fixes. Staying current is ongoing work.

New security surface

Access control, network rules and container images all need policy. The defaults are permissive.

Data is the hard part

Stateless apps move easily. Most teams keep databases on managed database services.

More moving parts to watch

Monitoring, logging and alerting must be set up on purpose, and failures have more layers to search.

Overkill when small

For a handful of apps and one team, the overhead can outweigh everything in the left column.

The shape of the ledger is the key point for a decision-maker. Most of the costs are paid once per platform: learning it, owning it, securing it, keeping it upgraded. Most of the benefits are earned once per service, per release and per incident. A platform that carries a couple of services rarely pays back. A platform that carries many usually does.

Kubernetes is one option on a range of ways to run software, and AWS and Azure offer the same five choices under different names. Moving down the range buys more control and costs more work. The right answer is the most managed option that still meets the need, and most real systems mix several.

Least control, least workDown: more control, more work

Serverless functions and workflows

Code or a workflow runs when an event arrives. The cloud runs everything else, and billing is per run.

Team manages: the code or the workflow

Outgrown by long-running jobs, heavy compute, or a need to move between clouds.

AWS

LambdaStep FunctionsEventBridgeSQS

Azure

FunctionsLogic AppsEvent GridService Bus

Serverless containers

Hand over a container image. The cloud runs and scales it, with no servers or cluster to manage. Some services scale to zero when idle.

Team manages: the container image

Outgrown when the team needs to tune the cluster underneath.

AWS

ECS Express ModeECS on Fargate

Azure

Container Apps

Managed app platform

Deploy a web app or API. The platform handles servers, patching and basic scaling.

Team manages: the app and its settings

Outgrown by custom networking, unusual software, or many services that need one deploy method.

AWS

Elastic Beanstalk

Azure

App Service

Managed Kubernetes

The cloud runs the Kubernetes control plane. The team controls networking, security policy, scaling and add-ons, and the same setup runs on any cloud.

Team manages: apps, cluster settings, upgrades

The most control of the options that still automate operations. The usual starting point for this proposal.

AWS

EKS

Azure

AKS

Virtual machines

Full control of the operating system. Every patch, deploy, restart and scaling rule is the team's job unless the team builds it. Self-run Kubernetes on company hardware or edge sites lives here too, often managed with Rancher.

Team manages: everything

Worth it for legacy software, special operating-system needs, or on-premises sites. The most to run.

AWS

EC2Auto Scaling groups

Azure

Virtual MachinesVM Scale Sets

In front of any of them: an API gateway, Amazon API Gateway or Azure API Management, handles sign-in, rate limits and API versions for every option on this list.

Kubernetes earns its keep when there are many services or several teams, releases are frequent, uptime matters to customers, the organization needs the same setup across environments or clouds, or workloads must run on its own hardware.

It is the wrong call when there are a handful of apps and one small team, a serverless or managed app platform already covers the need, or nobody can be given time to own the platform. In those cases the higher rows are faster, cheaper and less to learn, and it can be revisited later.

Kubernetes itself is free. The budget lines are elsewhere, and the largest one does not appear on a cloud bill.

01

The control plane · small or free when managed

The managed services run the Kubernetes brain for the organization. Amazon EKS and Google GKE charge about $0.10 per cluster per hour; Azure AKS offers a free tier. Running it on company hardware has no fee but makes the team responsible for it.

02

Compute · the same machines, packed tighter

Apps still run on ordinary virtual machines at ordinary prices. Sharing machines across apps and scaling with demand usually needs fewer of them than one-app-per-server.

03

People · the real line item

An owner for the platform, time for upgrades, and training for every team that ships on it. This is the cost that decides whether the investment pays back.

04

Tooling · mostly open source

Monitoring, logging, automated deploys and security scanning all have strong free options. The cost is the time to set them up once and keep them running.

Nobody should move everything at once. The path below makes each step small enough to stop after, and earns the next step with evidence.

1. 1

   Pilot one service

   Pick one stateless service and run it on managed Kubernetes for a fixed period. Measure deploy time, recovery time after a failure, and monthly cost against today.

2. 2

   Pave the road

   Build the shared basics once: automated deploys from source control, monitoring and logs, single sign-on access, and a starter template for new services.

3. 3

   Move by value

   Migrate the services that gain most from self-healing and scaling first. Keep databases on managed database services.

4. 4

   Operate on a rhythm

   Schedule upgrades around the release cycle, review cost monthly, and add a cluster only when a real boundary calls for one.

The proposal is not "move to Kubernetes." It is a bounded experiment with a named owner, three measures agreed in advance, and a review date. If the pilot service deploys faster, recovers on its own and costs about the same or less, the organization has evidence for step two. If it doesn't, the cost was one service and a few weeks, and the team learned where its real bottleneck is.

The trade is plain: more platform to learn and run, in exchange for every service deploying, healing and scaling the same way.

For the organization that later outgrows a single cluster — separate production, compliance-scoped workloads, sites that must run on their own — the Rancher resource covers the next layer: managing many clusters from one place.