Kubernetes Strategy: When It’s a Fit and Who Should Run It
Many organizations that use containers now run at least some production workloads on Kubernetes, and it comes up in most infrastructure discussions. But not every organization actually needs it or needs to run it themselves.
Kubernetes Strategy: When It’s a Fit and Who Should Run It
Many organizations that use containers now run at least some production workloads on Kubernetes, and it comes up in most infrastructure discussions. But not every organization actually needs it or needs to run it themselves. This Q&A explains when Kubernetes is a good fit, when it’s overkill, what skills you need, and how to choose between running it yourself and using a managed service. It’s written for Chief Technology Officers (CTOs), platform leaders, and engineering managers who are deciding whether Kubernetes is the right foundation for their applications and services.
What Kinds of Workloads Are a Good Fit for Kubernetes?
Short answer: Kubernetes fits best when you have many services, ship changes frequently, and must handle meaningful scale or strict reliability requirements.
When does that actually show up in the real world? Good candidates include:
Customer‑facing applications where uptime and latency affect revenue (e‑commerce, SaaS, APIs).
Microservice architectures with many independently deployable components.
Workloads with spiky or seasonal traffic that benefit from automatic horizontal scaling.
Teams that want a consistent platform across clouds, regions, and environments.
If you expect ongoing change and growth in your applications and infrastructure, Kubernetes gives you a solid, customizable foundation.
When Is Kubernetes Overkill?
Short answer: It’s overkill if your app portfolio is small, traffic is predictable, and you don’t plan to build a platform team.
It may be overkill when:
You run a small number of services or a single monolith with predictable, low‑to‑moderate traffic.
A basic PaaS, serverless functions, or a few VMs can meet your availability and scaling needs.
You don’t intend to build any dedicated platform or Site Reliability Engineering (SRE) capability.
You deploy infrequently and don’t need complex rollout or multi‑region strategies.
If a simpler managed service (for example, a PaaS or serverless offering) can meet your requirements with less operational burden, you should question whether introducing Kubernetes now is worth the cost and complexity. The tradeoff is the cost of compute, which will generally be higher on PaaS or serverless.
What Skills and Team Capacity Do We Need to Run Kubernetes Ourselves?
Short answer: You need real platform engineering skills plus enough dedicated time to design, operate, and secure the clusters.
You typically need:
Strong skills in Linux, networking, and your cloud provider’s primitives (VPCs, load balancers, IAM, storage).
Familiarity with Kubernetes concepts and troubleshooting (scheduling, control plane, controllers).
A handle on observability, incident response, and release engineering.
Security and compliance basics, including RBAC, network policies, admission controls, and guardrails.
In terms of capacity, it works best when:
You have at least a small, focused platform/SRE group rather than relying on whomever has time in a given week.
Those engineers can invest in designing the platform, handling upgrades, and closing reliability gaps.
If you only have one or two engineers who are also responsible for core product development, running Kubernetes end‑to‑end in‑house will likely strain your team.
What Alternatives Should We Consider if Kubernetes Isn’t a Fit Right Now?
Short answer: Use managed PaaS, serverless, or simple VM auto‑scaling when they can meet your needs with less operational burden than Kubernetes.
Common alternatives:
Managed PaaS / app platforms: Deploy code or containers without managing the underlying cluster. Good for small app portfolios or when speed to market is the priority.
Serverless and functions: Ideal for event‑driven workloads, APIs, and background jobs that don’t need a long‑running, stateful platform.
VM‑based auto‑scaling: Autoscaling groups or similar can handle a monolith or a few services without introducing a container orchestrator.
You can also start with these options and move to Kubernetes later when your architecture, team, and growth justify the additional complexity.
How Do We Evaluate Kubernetes from a Business Perspective?
Short answer: Tie Kubernetes to cost, efficiency, agility, and reliability metrics; if you can’t, it may not be the right time.
For each area below, ask what changes you expect:
Cost: What is your current total cost of ownership (TCO) for infrastructure, and where is waste coming from? Do you expect Kubernetes to reduce or increase that cost, once you include platform engineering?
Operational efficiency: How much time do engineers spend on manual deployments, emergency fixes, and environment drift? How much of that could Kubernetes automation and standardization actually remove?
Agility: How long does it take to ship a change today? Would a shared platform, consistent pipelines, and self‑service environments shorten that cycle in a measurable way?
Reliability and risk: What are your uptime and incident patterns now? Could Kubernetes features and objects, such as health probes, autoscaling, and policies help you meet clearer service level objectives (SLOs), or would they just add moving parts you can’t yet support?
If you cannot draw a believable line from Kubernetes adoption to better cost, speed, reliability, or risk, it may not be the right time.
Managed Kubernetes vs. Building Our Own Platform: How Should We Choose?
Short answer: Run it yourself only if the platform is a core strategy; otherwise, a managed Kubernetes service is usually more efficient.
Running Kubernetes yourself means:
You design and operate the clusters, add-ons, and underlying cloud infrastructure.
Your team handles upgrades, patching, security hardening, and day‑to‑day operations.
You own on‑call and incident response for both the platform and the applications.
Using a managed Kubernetes service or partner means:
The provider runs and maintains the Kubernetes platform and core components.
You focus on your applications, delivery workflows, and developer experience.
You still get Kubernetes’ scaling and reliability benefits, but without building a full platform team from scratch.
A simple rule of thumb:
If building and operating an internal platform is a deliberate, funded strategy for your organization, running Kubernetes yourself can make sense.
If your primary goal is to ship products and features and you don’t want to grow a large platform team, a managed solution will likely get you there faster with less operational risk.
Where Does Fairwinds Fit Into This Decision?
Short answer: Fairwinds runs Kubernetes for you so your teams can focus on applications, not cluster operations.
Fairwinds provides Managed Kubernetes‑as‑a‑Service so that:
Fairwinds engineers handle the design, day‑to‑day management, and hardening of your Kubernetes environment.
Your teams keep control over how applications are built, deployed, and evolved on top of that environment.
If you’re considering Kubernetes and want help deciding whether it’s the right strategic fit, and whether you should run it or have it managed, Fairwinds can help you evaluate the trade‑offs and choose a path that supports your business goals.
*** This is a Security Bloggers Network syndicated blog from Fairwinds | Blog authored by Andy Suderman. Read the original post at: https://www.fairwinds.com/blog/kubernetes-strategy-when-its-a-fit-who-should-run-it
About Author
