Kubernetes
A container orchestration platform we use to run, scale, and coordinate many containers across a cluster of machines — applied where a system's scale and complexity genuinely need it, not adopted as a default way to run containerised workloads.
Kubernetes is a container orchestration platform we use to run, scale, and manage many containers across a fleet of machines — scheduling workloads, handling failover, and automating rollouts once a system has outgrown what a single managed-container service can reasonably handle. It's a genuine operational commitment, not a default way to run containers, and for many projects a simpler managed-container service achieves the same outcome at far less operational cost.
Where it fits
Once a business is running more than a handful of containerised services — several backend services, background workers, scheduled jobs, all needing to scale independently and recover from failure without manual intervention — coordinating them by hand becomes a real operational burden. Kubernetes automates that coordination: scheduling containers onto available machines, restarting failed ones, scaling services up or down based on load, and rolling out updates without downtime.
That coordination is valuable specifically at a certain scale and complexity, and we're direct about where that threshold sits. A single service, or a handful of services with modest and predictable traffic, doesn't generate enough orchestration problems to justify running Kubernetes — the coordination Kubernetes automates barely exists yet at that scale, so most of what it adds is the platform's own overhead.
We treat the decision to run Kubernetes as a genuine trade-off between orchestration capability and operational cost, not a default infrastructure choice for containerised systems. For businesses that are past that threshold — multiple teams shipping services independently, workloads that need to scale elastically and reliably, or multi-region resilience requirements — the trade-off is usually worth it. For businesses that aren't, we say so and recommend a simpler managed-container service instead.
Where Kubernetes is the right fit, we typically run it on a managed Kubernetes service (such as AWS EKS, Google GKE, or Azure AKS) rather than operating the control plane ourselves, which removes a substantial share of the platform's own operational burden while keeping its orchestration capabilities.
Core capabilities
- Automated placement of containers across available cluster capacity
- Horizontal scaling of services based on real load
- Self-healing — automatic restart and rescheduling of failed containers
- Rolling updates and automated rollbacks across many services at once
- Coordinated deployment of interdependent services
- Configuration and secrets management across environments
- A consistent operating model across many independently deployed services
- Resource isolation and quotas between teams or workloads sharing a cluster
- A foundation for multi-region or multi-cluster resilience
Common use cases
- Multi-service backend platformsCoordinating many independently deployable backend services that need to scale, restart, and deploy without manual orchestration.
- Workloads with variable, unpredictable loadSystems that need to scale containers up and down automatically in response to real, fluctuating traffic or processing demand.
- Multi-team engineering organisationsOrganisations where several teams ship services independently and need a shared, consistent way to deploy and operate them.
- High-availability and multi-region systemsPlatforms with resilience requirements that call for orchestrated failover and workload distribution across zones or regions.
Architecture & integration considerations
- Managed control plane by defaultUsing a managed Kubernetes service rather than self-hosting the control plane, to avoid taking on the platform's most demanding operational burden without a specific reason to.
- Right cluster topologyCluster size, node pools, and namespace structure scoped to the workload's actual scale, not provisioned for hypothetical future growth.
- Observability from day oneCentralised logging, metrics, and tracing across the cluster, since debugging a distributed system without them is significantly harder than debugging a single application.
- Security and access boundariesNetwork policies, role-based access control, and secrets handling configured explicitly per project rather than left at cluster defaults.
Strengths
- Automated orchestration at scaleHandles scheduling, scaling, and recovery across many containers and services without manual intervention.
- Consistent operating modelThe same deployment, scaling, and configuration approach applies across every service on the cluster, which matters once there are many services and teams.
- Portable across cloud providersA Kubernetes-based architecture can move between major cloud providers, or to on-premises infrastructure, with less rework than provider-specific compute services.
- Mature ecosystemA large, well-established ecosystem of tooling for networking, observability, security, and deployment automation built around the platform.
Trade-offs & limitations
- Significant operational complexityKubernetes introduces its own concepts, failure modes, and configuration surface — networking, storage, RBAC, autoscaling policies — that someone on the team has to learn and operate, on top of the application itself. This is not a one-time setup cost; it's ongoing operational work for as long as the cluster runs.
- Wrong fit below a certain scaleFor a single service, or a small number of services with modest traffic, Kubernetes' orchestration capabilities go largely unused while its operational overhead is paid in full. A simpler managed-container service, such as AWS ECS or Fargate, achieves the same practical outcome — running containers reliably — at a fraction of the setup and ongoing operational cost.
- A dedicated skill set to operate wellRunning Kubernetes reliably in production takes real, specific expertise. Teams without that expertise either under-invest in it and accumulate operational risk, or spend disproportionate time managing the platform instead of building the product.
- Cost is not automatically lowerThe cluster itself, plus the engineering time to operate it, is a real and ongoing cost. Kubernetes can improve resource utilisation at scale, but below that scale it frequently costs more, in infrastructure and people's time, than the simpler alternative it replaced.
- Debugging distributed failures is harderFailures in a Kubernetes system can originate in the application, the cluster's scheduling decisions, its networking layer, or the underlying nodes — diagnosing which one requires broader system knowledge than debugging a single deployed service.
When to use it
- The system genuinely comprises many containerised services that need independent, coordinated scaling and deployment
- Multiple teams ship services independently and need a consistent, shared operating model
- Load is variable enough that automated, fine-grained scaling delivers a real operational or cost benefit
- Multi-region or multi-cluster resilience is an actual requirement, not a hypothetical one
- The team has, or is prepared to build, the operational expertise to run it well
When another option may be more appropriate
- The system is a single service or a small number of services with modest, predictable traffic
- A simpler managed-container service, such as AWS ECS or Fargate, would run the same workloads reliably at lower setup and operational cost
- There's no dedicated capacity to learn and operate Kubernetes on an ongoing basis
- The project's timeline or budget doesn't justify the platform's setup and operational overhead relative to what it would deliver
Relevant services
- DevOps & Cloud InfrastructureDevOps engineering for teams with manual, risky deployments: CI/CD, infrastructure-as-code, and observability built as a real discipline.
- Custom Software DevelopmentDesign and development of secure, scalable custom software for companies across Sweden and the Nordic region.
- Legacy System ModernizationAudit-led legacy system modernization with incremental, strangler-fig migration and phased cutover for companies across Sweden and the Nordic region.
Relevant industries
- ManufacturingCustom manufacturing software, operational platforms and connected systems for companies modernising production across Sweden and the Nordic region.
- Logistics and MobilityCustom logistics, fleet, mobility and transport software for companies managing complex operations across the Nordic region.
- FinTechCustom fintech software: open banking API integration, KYC workflow automation and data platforms. North Tech Labs is not a licensed payment institution.
Alternatives & complementary technologies
- AWS ECS / FargateA simpler managed-container service that runs containers reliably without cluster-management overhead — the right-sized choice for most projects below Kubernetes' genuine scale threshold.
- Google Cloud RunA managed container platform that scales containerised services with minimal operational overhead, well suited to workloads that don't need Kubernetes' full orchestration surface.
- A single well-configured server or small VM groupFor genuinely small systems, running containers directly (with Docker) on one or a few servers, without any orchestration layer, is sometimes simpler and cheaper than any orchestration platform.
Frequently asked questions
Do we need Kubernetes?
Probably not, unless you're running many independently scaled services, have multiple teams deploying independently, or have concrete multi-region resilience requirements. Below that scale, a simpler managed-container service like AWS ECS or Fargate runs containers reliably with far less operational overhead, and we'll recommend that instead.
Isn't Kubernetes just how you run containers in production now?
No. It's one way to run containers at scale, with real operational cost attached. Plenty of production systems run containers reliably on simpler managed-container services without ever needing an orchestration layer.
Does Kubernetes make a system cheaper to run?
Not automatically. At sufficient scale it can improve resource utilisation, but the cluster and the engineering time to operate it are real, ongoing costs — below that scale it frequently costs more than the simpler alternative it would replace.
If we adopt Kubernetes, do we need to manage the control plane ourselves?
No, and we generally recommend against it unless there's a specific reason to. A managed Kubernetes service from a major cloud provider removes a substantial share of the operational burden while keeping the orchestration capabilities.
What's the difference between this and Docker?
Docker packages and runs individual containers. Kubernetes is the layer above that — it coordinates many containers across many machines: scheduling them, scaling them, restarting them on failure, and rolling out updates. You can use Docker without Kubernetes; Kubernetes assumes containers already exist and orchestrates them.
Further reading
- CI/CD for Software Teams - Building a Reliable PipelineA practical guide to building a CI/CD pipeline: core stages, canary and blue-green deployments, feature flags, environment parity, and a team maturity model.
- A Practical Framework for Cloud MigrationA technical framework for cloud migration: assessment, the 6 Rs strategy model, sequencing, containerization, cutover, and post-migration cost governance.
- Microservices vs. Monolith: Choosing the Right ArchitectureA technical comparison of microservices and monolithic architecture: tradeoffs, Conway's Law, data consistency, and a practical decision framework.
Considering Kubernetes for your next project?
Tell us what you're building — we'll confirm whether this is the right technology choice before recommending anything.