Kubernetes needs a reason beyond future growth
For a small company, compare Kubernetes with a managed platform by the work left to own: recovery, upgrades, access and handover after an engineer leaves.
By 
Paul. Architecture and infrastructure
A company with a handful of services and no platform team should start by evaluating a managed application platform or a small number of well-run virtual machines. Kubernetes should enter the comparison when a specific requirement earns back its operating work. Anticipated growth, without a concrete constraint, is a weak reason to acquire another system to maintain.
This is an ownership argument, not a claim that Kubernetes always costs more or fails more often. A team already skilled in it may operate a small deployment efficiently. A poorly maintained virtual machine can be a serious liability. The decision must compare credible operating plans, including who takes over when the original engineer leaves.
An anniversary does not select your infrastructure
The Kubernetes project's 6 June 2024 anniversary article marked ten years of the project. Longevity and ecosystem maturity matter when choosing software. They do not establish that a particular small company needs a cluster.
A useful starting document describes the application rather than the orchestration product. Record which processes run continuously, which perform scheduled work, where persistent data lives and which failures stop customers working. Identify required recovery times with the business before selecting infrastructure intended to meet them.
This often exposes a gap between the problem named in the proposal and the problem being solved. If the immediate issue is a fragile deployment script, a cluster may be a much larger response than necessary. If the issue is coordinating many independently released workloads with distinct resource needs, orchestration may address the actual constraint.
Managed does not mean nobody owns the remainder
The current Kubernetes production guidance distinguishes options such as a managed control plane and managed worker nodes. Those choices transfer different responsibilities. They should not all be priced as if the provider operates the complete application.
For a proposed managed cluster, write down what remains with the business or its supplier. Include workload configuration, application updates, access policy and the connections to databases, storage and external services. Ask which party responds when a customer-facing request fails and several providers appear healthy individually.
The same discipline applies to a managed application platform. It may remove cluster administration while imposing deployment, networking or execution constraints. Virtual machines require their own patching, process supervision and recovery arrangements. A fair comparison includes these obligations on every side.
The important output is a responsibility map that survives a staffing change. A low infrastructure invoice is incomplete evidence if operating labor and the cost of finding replacement expertise are missing. Equally, a larger invoice can be a reasonable purchase if it removes work the team would otherwise have to perform.
Price the handover while the author is present
Imagine, as a planning exercise, that the engineer who introduced the system becomes unavailable next month. Ask what another qualified engineer would need to identify the running version, deploy a correction and restore service.
For Kubernetes, that might involve manifests, Helm chart values, container images and access to the appropriate registry. A list of files is insufficient if nobody knows which configuration actually controls production. Record the path from reviewed source to running workloads and how to recover the credentials required to use it.
Recovery also needs a data plan. Recreating application containers does not restore a lost database. Require a description of where persistent data is backed up, what consistency assumptions matter and how restoration will be checked. These acceptance questions need demonstration in the actual environment.
Ask for an upgrade procedure as well. It should identify the application-specific dependencies that need checking and the action to take when an upgrade cannot proceed. An environment that can be created once but cannot be maintained predictably is unfinished operational work.
Three questions can justify the extra machinery
First, what present requirement is difficult to meet with a simpler platform? Examples might include many independently scaled workloads, a required deployment environment or a customer contract specifying Kubernetes. The requirement should be observable, rather than a general desire to be ready for success.
Second, who owns operations throughout the support period? The answer may be an internal team, a supplier or a clearly divided arrangement. It needs time and access as well as a name. A single enthusiastic engineer without replacement cover is a fragile staffing plan on any infrastructure.
Third, what will prove the system recoverable and transferable? Define evidence before approving the platform. A reviewable handover and a controlled recovery exercise reveal more about ownership than a successful initial deployment.
Tenant isolation needs particular care. The current multi-tenancy documentation describes isolation as a range of designs and tradeoffs. A namespace alone is not a hard security boundary. Stronger requirements may demand additional controls or separate clusters. “We need isolation” should begin that analysis, not end it.
Keep an existing cluster until change has a case
The strongest counterargument is standardization. A company whose staff and deployment tools already use Kubernetes may reduce complexity by keeping that standard. Customers who operate their own installations can also make a common deployment target commercially important. These are concrete reasons, even when service counts are modest.
An inherited cluster therefore does not automatically need removal. Migration brings risk and consumes the same people who keep customers working. First establish whether the problem is the platform choice, poor documentation or neglected maintenance. Repairing the latter two may be the less costly path.
For a new system, compare the work required over the operating period and choose the least complicated arrangement that meets the real requirements. During a software takeover, make deployability, recovery and access ownership explicit deliverables. Infrastructure earns its place when the next responsible person can operate it, not merely when the first person can launch it.