Containers and Kubernetes: Do You Actually Need Them?

Adopt containers. Think hard before adopting Kubernetes. Containers give you a repeatable way to ship software that behaves the same on a laptop, in a test environment and in production, and that is worth having even for a single application. Kubernetes gives you a way to run hundreds of containers across many machines, and it charges you in expertise rather than licence fees. If you run three services and have no platform engineer, you are paying that price for capability you will not use.

The short answer

Three questions settle it. Do you deploy more than a handful of independent services? Do you need to run them across several machines with automatic replacement when one dies? Do you have someone who will own the platform, patch it and be on call for it? Two yeses and a clear owner mean Kubernetes is reasonable. Anything less and a managed container service will do the same job with a fraction of the surface area.

This is not a fashionable position, and it is not anti-Kubernetes. We run Kubernetes for clients who need it. It is simply that the cost of running it is paid in attention, and attention is the scarcest resource in a small technical team.

What containers actually solve

A container packages your application with its dependencies and a declaration of how to start it. The practical gains are specific rather than philosophical.

• The environment stops being a variable. The image that passed your tests is the image that runs in production, down to the library versions.
• Deployments become reversible. Rolling back is pointing at the previous image tag rather than reinstalling packages and hoping.
• Onboarding gets shorter. A new developer runs one command instead of following a page of setup instructions that went stale last March.
• Hosting becomes portable. The same image runs on a single virtual machine today and on a managed platform next year without a rewrite.

You can have all four of those without an orchestrator. One container per service on one well-maintained virtual machine, deployed by a simple pipeline, is a perfectly respectable architecture for a business with a few hundred users. Plenty of profitable software runs exactly that way.

What Kubernetes adds, and what it charges

Kubernetes is a scheduler with opinions. You describe the state you want, how many copies of each service, how much memory each needs, what counts as healthy, and it works to keep reality matching that description. It replaces failed containers, spreads them across machines, rolls out new versions gradually and rolls back when health checks fail.

The bill has two halves. The control plane is a published, predictable figure: USD 0.10 per cluster per hour on both Amazon EKS and Google Kubernetes Engine, which is about USD 73 a month before a single workload runs. The nodes, storage and load balancers are the larger half, and they cost the same as they would without Kubernetes. The third half, the one that is not on any pricing page, is the person who understands it.

Two of those bars deserve comment. The GKE free tier gives every billing account USD 74.40 of monthly credit, which Google describes as the equivalent of one free Autopilot or zonal Standard cluster, so a first cluster really can cost nothing for the control plane. And the EKS extended support bar is what happens when nobody upgrades: USD 0.60 per cluster per hour, six times the standard rate, applied automatically once your version ages out.

Managed Kubernetes compared: EKS, AKS and GKE

All three major providers run conformant upstream Kubernetes, so your manifests travel. The differences are in the commercial terms and the operational defaults, and these are the figures from each vendor’s own pricing page in October 2026.

The practical reading: if you want a free cluster to learn on, Azure’s Free tier and Google’s free-tier credit both give you one, and neither is appropriate for production because one has no SLA and the other covers a single zonal cluster. If you want a financially backed promise about the control plane, you are paying somewhere between nothing and USD 73 a month for it, which is noise compared with the node bill.

The upgrade treadmill nobody budgets for

Kubernetes moves. The project’s release history shows version 1.37 released in September 2026 with end of life set for October 2027, and the patch release documentation states that each active series is supported for roughly fourteen months. Three minor releases a year, each supported for a bit over a year, means you are upgrading continuously rather than occasionally.

For a team with a platform engineer, that is routine maintenance. For a team of two developers who also build features, it is the thing that slips. And slipping has a price now rather than just a risk: AWS moves clusters onto extended support automatically and charges the higher rate, so the upgrade you deferred appears on next month’s invoice.

A ladder worth climbing one rung at a time

The useful way to approach this is as a ladder. Each rung is a complete, defensible place to stop, and you only climb when something forces you to.

1. Containerise, deploy to one host. You get reproducibility and easy rollbacks with almost no new concepts. Most small businesses should be here or on the next rung.
2. Move to a managed container runtime. Google Cloud Run, AWS App Runner or Azure Container Apps take your image, scale it and handle the plumbing. No cluster, no node patching, and you keep the same artefact.
3. Adopt managed Kubernetes with the provider’s automatic mode. Autopilot on GKE, Auto Mode on EKS, Automatic on AKS. You get the Kubernetes API with far fewer decisions.
4. Run a full managed cluster yourself. Node pools, networking policy, admission control, observability. Appropriate when you have multiple teams deploying independently.
5. Multiple clusters across regions. Real platform engineering, with a real platform engineer.

Rung two is where we land most clients, and where we often move people who climbed to rung four too early. The tell is a cluster running three services, last upgraded eighteen months ago, that nobody wants to touch. That is not a platform. That is a liability with a dashboard.

If your workloads are spiky rather than steady, consider skipping rungs entirely: our serverless piece works through the arithmetic of per-millisecond billing, and the answer is often cheaper than a cluster. If you are weighing providers at the same time, choosing a cloud provider for a global business covers region coverage and data residency.

What the industry data says, and what it does not

The CNCF’s 2025 survey is the best public dataset on adoption, and it is worth reading carefully rather than as a headline. Production Kubernetes use among container users reached 82%, up from 66% in 2023. Ninety-eight per cent of surveyed organisations reported adopting cloud native techniques of some kind. Two-thirds of respondents adopting AI said they were using Kubernetes to scale inference workloads.

Now the caveat. That survey asks organisations who already use containers and already engage with the cloud native community. It is not a sample of all businesses, and it tells you almost nothing about whether a twelve-person agency should run a cluster. The finding we would actually act on is the obstacle data: for the first time, the top reported challenge was cultural change within the development team at 47%, ahead of lack of training and security at 36% each and complexity at 34%.

That ranking matches what we see. The technology is mature and the managed services are good. The projects that go wrong go wrong because nobody owns the platform, the on-call rota never changed, or the team was asked to learn a new operational model alongside a delivery deadline.

Where we fit in

Eudora Technology works remotely with clients worldwide, and container work suits that model well. Our cloud solutions service covers containerising an existing application, building the deployment pipeline, picking the rung of the ladder that matches your team, and taking over the upgrade cadence if you would rather not own it. We will also tell you when the answer is to stay where you are, because a working deployment nobody is afraid of beats an elegant one that scares everybody.

Whichever rung you choose, the recovery story changes with it. Four cloud disaster-recovery patterns by budget covers how portable workloads make a second region much cheaper to stand up.

Not sure which rung of the ladder your application belongs on? We will look at what you run today and give you a straight answer, including when the answer is to change nothing. Get in touch with Eudora Technology to talk about your project.