Kubernetes stopped being a hype topic a long time ago. The platform has arrived at mid-sized companies, IT service providers offer it as their standard runtime, and hardly a single job ad for DevOps engineers goes without it. Still, our answer to the question in the headline is surprisingly often: No – at least not yet.
Kubernetes shows its strengths as soon as many applications are built, rolled out and operated according to a uniform scheme. Without that, Kubernetes mainly increases one thing: the complexity of your IT landscape.
As a CTO or CIO, you should therefore answer three questions before you commit:
- Do our applications actually need Kubernetes?
- Does Kubernetes fit the strategic IT direction of our company?
- Which changes, skills and costs are coming our way?
What can run on Kubernetes?
In theory, anything that runs in a container. Classically, these are web and network applications based on Linux, from web-based time tracking to a database management system. Modern .NET applications and Microsoft SQL Server now run in Linux containers as well.
Classic Windows applications, on the other hand, are left out. Accounting software, control software for phone systems or locking systems often rely on native functions of the Windows operating system and cannot be containerised in any sensible way.
Kubernetes for internal applications
For internal IT and classic business applications, we advise against Kubernetes in the vast majority of cases. The following questions help with the decision:
- Do you have enough time to get into Kubernetes? Complexity increases, both conceptually and technically. Your team has to deal intensively with networking, storage, certificates, upgrades and monitoring inside the cluster, permanently and not just during the rollout.
- Should databases run in Kubernetes?
It is possible with MySQL, PostgreSQL, Microsoft SQL Server and Oracle. Reasons against it include:
- Memory-intensive and performance-critical queries can become noticeably slower due to the additional abstraction layer.
- Backups are harder to integrate into your central backup mechanisms.
- Changed or virtualised hardware can lead to new licence costs. This applies to Oracle in particular.
- Are there enough applications that can run as containers? Without a larger number of containerisable applications, the effort for operations and for changing your update and upgrade processes does not pay off in most cases.
- Which systems have to run outside anyway? Exchange, SharePoint or Windows server roles such as Active Directory and certificate services stay on your existing systems.
- Is there software development know-how? Kubernetes is an API-driven platform. It only unfolds its full potential once you automate your workflows: with infrastructure as code, CI/CD and GitOps.
The conclusion: classic infrastructure services such as domain services, mail, storage and databases usually don't belong in Kubernetes. For business applications, you have to weigh whether the effort is worth the benefit.
Kubernetes for web applications
Web applications are where Kubernetes shines. Infrastructure tasks such as automatically issuing X.509 certificates via Let's Encrypt can be solved quickly and uniformly with tools like cert-manager. Encryption requirements can be enforced centrally for all applications, for example "TLS 1.2 and newer only", as demanded by certifications such as TISAX.
With larger or fluctuating loads, Kubernetes responds with autoscaling: more resources for processing requests are available within a short time.
Above the infrastructure layer, however, Kubernetes only pays off if the application is continuously developed and released frequently.
Simple web applications
For a static website or a simple PWA with a few hundred page views per second, you don't need a Kubernetes cluster. Any larger hosting provider offers the resources required.
Our take: For simple web applications or PHP scripts, Kubernetes is unnecessary in most cases.
Portals and shops
For portals such as online shops or forums with high traffic and relatively long processing times (for example with WooCommerce or Magento), Kubernetes can be interesting. When a marketing campaign goes live, the cluster distributes requests across more resources. Always check, though, whether your cloud provider's autoscaling would be easier to implement.
Answer at least these questions beforehand:
- Can the application store and address images and other files centrally?
- Can the application handle distributed sessions, or does it need session stickiness?
- Is there already a development process that allows continuous building and rollout?
Our take: For a portal, the decision for or against Kubernetes is usually made only after analysing the existing application and the development process.
SaaS products
SaaS software usually follows one of three architectural concepts:
- Multi-instance: every customer gets their own virtual or physical server. Data is physically and logically separated.
- Multi-host: the application exists several times in different directories on the same server. Customers share the resources.
- Multi-tenant: the application itself manages several tenants. It is installed once and provided to many customers. This saves resources but increases the complexity of the software.
With multi-instance and multi-host, the effort for every release grows linearly with the number of customers unless you have a suitable CI/CD workflow. This is exactly where Kubernetes drastically reduces the organisational overhead, because every instance is rolled out according to the same scheme. For multi-tenant applications, Kubernetes mainly plays to its strength in autoscaling.
And today: managed Kubernetes and platform engineering
A lot has happened since this article was first published. Managed offerings such as Amazon EKS, Azure Kubernetes Service or SUSE Rancher take over part of the operations. The basic question remains the same, though: upgrades, networking, security, monitoring and the know-how in your team are still your job.
At the same time, platform engineering has become the guiding idea: a platform team provides development teams with an internal platform through which they roll out applications on their own, following uniform rules. Kubernetes is often the foundation for this, but it only makes sense if there are enough teams and applications that actually use the platform.
For many scenarios, there are also leaner alternatives:
| Scenario | Often the better choice |
|---|---|
| Few containers, low load | Virtual machine with Docker Compose |
| Individual services in the cloud | Managed container services such as AWS ECS or Azure Container Apps |
| Classic web application without special requirements | Platform as a service or a classic hosting provider |
| Many teams, many services, frequent releases | Kubernetes, ideally with GitOps |
Conclusion
Whether Kubernetes makes sense for your software products has to be assessed individually. Kubernetes is no cure-all for existing IT problems: in many cases, mainly the complexity goes up. It shows its strengths when many applications are built and operated according to a uniform scheme and your team can carry the platform in the long run.
Facing exactly this decision right now, or already running Kubernetes and unsure whether the decisions made so far will hold up? That's what our architecture review is for. Or ask your questions directly in our advisory.
Originally published on October 3, 2020.