In this article
A small service with an expensive platform
Imagine one product team running a web application, a worker and a database. Deployments are infrequent, but the team spends days maintaining its cluster and CI controller. A platform discussion should begin with that imbalance. Would a managed application runtime meet the actual availability, network and deployment constraints? Which capability would be lost by simplifying?
Now change the scenario: several teams have different release schedules, workloads need distinct resource profiles, and policy must be enforced consistently. Orchestration may become useful. The distinction is an operating requirement, not a user-count threshold. Kubernetes documents a platform for managing containerised workloads, but adopting it does not supply your team with an incident rota, a recovery plan or application expertise.
Start with promotion criteria
Kubernetes is not a maturity badge. Name the constraints that a simpler deployment no longer satisfies: isolation, independent scaling, scheduling, policy enforcement, multi-team ownership or recovery behavior.
Jenkins is also a product to operate. Existing CI may already provide the required build, approval, artifact and deployment controls without adding a separate controller and plugin surface.
Price the operating surface
Include cluster and controller upgrades, identity, network policy, secrets, observability, capacity, backups, incident response and the people who own them. Infrastructure cost alone is not the decision.
If no named owner can rehearse restore, rotate credentials and diagnose a failed rollout, the platform boundary is ahead of the organisation.
What does the platform need to justify?
Compare operating responsibilities before adding infrastructure.
Simpler baseline
A smaller deployment surface, with fewer moving parts to own.
Platform investment
Additional scheduling and delivery capabilities, plus upgrades, incidents and ownership.
Decision evidence
A real workload constraint, a named operator and a recovery plan.
Use a reversible promotion decision
Define measurable triggers and the simpler baseline. Promote only the workloads that need the capability, preserve an artifact rollback path and review whether the added layer removed the original constraint.
A decision record should also state what would cause consolidation back to a managed service or simpler runtime.
Separate the CI decision from the runtime decision
A build pipeline produces and verifies an artefact. A runtime starts and operates that artefact. Choosing Kubernetes does not require Jenkins, and keeping Jenkins does not require Kubernetes. Evaluate each against its own constraints: private network access, existing pipelines, approval requirements, build isolation and the skills available to maintain it.
For a migration trial, keep the application image unchanged and deploy it through the candidate path. Rehearse a failed health check, an unavailable dependency and a configuration mistake. Record the commands and decisions needed to recover. A platform that shortens a successful deployment but makes diagnosis inaccessible to the product team may move the bottleneck rather than remove it.
A review you can repeat after the migration
Keep a short ledger of platform work: upgrades, access changes, deployment incidents and time spent helping other teams. Compare it with the previous approach alongside application recovery time and release friction. Review outliers, not just averages: a rare restore failure can matter more than a small improvement in daily deployment speed.
Choose an owner for the platform roadmap and a date to revisit the decision. If most workloads never use the added capabilities, consolidate them. If shared controls are demonstrably reducing repeated work, invest in documentation and supported templates. This makes the platform a maintained internal service with customers and costs, rather than infrastructure whose existence becomes its own justification.
Sources & further reading
Documentation consulted on .
FAQ / DECISIONS
Frequently asked questions
Does a microservice architecture require Kubernetes?+
No. Deployment topology and application boundaries are separate decisions. Choose orchestration only for capabilities the operating model can own.