In most cases, the use of Kubernetes is not advisable, as the complexity of the infrastructure will be unnecessarily increased. Kubernetes shows its strengths as soon as a uniform scheme can be used for the deployment of applications.

In 2014, Google released the first version of Kubernetes on GitHub. Even then it became clear that the software would not only be relevant exclusively for Google and some highly specialized technology companies. Other global players such as Microsoft, RedHat, IBM and Huawei joined the Kubernetes community in 2014 and 2015, respectively.

In the following years, more and more software products that were operated on the basis of Kubernetes appeared. Particularly noteworthy is the [Case Study](https://cloud.google.com/blog/products/gcp/bringing-pokemon-go-to-life-on-google-cloud on Pokémon GO from 2016. The massive computing power required for Pokémon GO could only be satisfied because Kubernetes was able to scale the resources required for it.

Kubernetes is no longer just a hype. The platform has also arrived in productive environments apart from classic software development companies. With the transformation of business models in medium-sized companies towards digital products and services, IT service providers are increasingly offering Kubernetes as an operating platform.

CTOs and CIOs now face the questions together:

  • to what extent Kubernetes is necessary at all,
  • how Kubernetes fit the strategic (IT) direction of your company
  • and what changes and costs to come.

What can run on Kubernetes?

Theoretically, all applications can run in Kubernetes that can also run within a Docker container. Classically, these are web or network applications based on Linux. This starts with the web-based time recording and ends with a database management system. However, this is not the end of Microsoft's open source initiative. In the meantime, specific .NET applications and the Microsoft SQL Server can also be operated in a Docker container, and thus also in Kubernetes.

Classic Windows applications cannot run within Kubernetes. Software such as Lexware, aber auch, but also control software for the telephone systems or locks, often fall back on native functions of the Windows operating system.

Kubernetes for internal software products

In the vast majority of cases, the use of Kubernetes for internal IT and software solutions is not advisable. The following questions can help you decide whether or not to use it:

  • Is there enough time to look at Kubernetes?

    Both conceptually and technically, the complexity of the IT landscape is increasing. The administrators have to deal extensively with the effects and necessary changes.

  • Should database management systems be operated in Kubernetes?

    Theoretically, MySQL, Microsoft SQL Server, PostgreSQL and Oracle can be operated in Kubernetes. Reasons against operating in Kubernetes include:

    • Memory-intensive and performance-critical SQL queries may take significantly longer due to increasing complexity.
    • The data backup of the underlying files can be more complex or no longer integrated into the central backup mechanisms.
    • The changed or virtualized hardware may result in new license costs. This is particularly true of Oracle.

  • Are there many applications that can run as containers?

    Without a large number of containerizable applications, a Kubernetes solution makes little sense. In most cases, the effort involved in operating and converting the previous update and upgrade processes is not profitable.

  • Which applications still have to run on physical or virtualized hardware?

    Applications such as Microsoft Exchange Server or SharePoint, as well as Windows server roles such as Active Directory or certificate services must continue to run on the existing systems outside of the Kubernetes cluster.

  • Is there any knowledge in the area of ​​software development?

    Kubernetes provides an API that can be used to automate workflows.

Based on the questions mentioned, it can already be deduced that classic infrastructure services (domain operation, mail, storage and databases) cannot or should not run in Kubernetes. In the case of business applications, it is important to consider whether the effort does justice to the benefit.

Kubernetes for operating web applications

Kubernetes has one of its strengths in the area of ​​web applications. Administrative infrastructure tasks such as B. the establishment of free X.509 certificates via Let’s Encrypt or Amazon Certificate Manager for encrypted transmission via HTTPS can be implemented very quickly. Furthermore, encryption requirements, for example, can be implemented directly across all applications. This is particularly interesting if the encryption of TLS 1.2-only is required due to a necessary certification such as TISAX, but the hoster also offers TLS 1.0 and 1.1.

Especially in the case of larger or changing loads, Kubernetes can react to the changing number through autoscaling: With suitable measures, more resources can be made available for processing the requests within a short period of time.

Above the infrastructure layer, the use of Kubernetes only makes sense if the web application is continuously developed and published more often.

Simple web applications

With a simple web application (static website and/or PWA) with a few hundred page views per second, the need for a Kubernetes cluster is almost non-existent. Every major German web host provides the necessary resources for this.

!! In most cases, the use of Kubernetes is unnecessary for simple web applications or PHP scripts.

Portals

The use of Kubernetes can be interesting for portals such as online shops or forums with high traffic and a relatively long processing time due to the underlying programming language (e.g. PHP for WooCommerce or Magento). At times with high loads, e.g. during marketing campaigns are switched on television, the requests can be distributed to more resources. Here, however, it must always be evaluated whether it is easier to implement auto scaling via the cloud provider that is subject to it: The complexity of the infrastructure through Kubernetes increases sharply.

At least the following questions should be answered when evaluating Kubernetes:

  • Can assets such as images and other files be stored and addressed centrally by the application?
  • Can the application handle distributed sessions or is so-called session stickiness required?
  • Does a development process already exist that enables the application to be built and rolled out continuously?

!!! The decision for or against Kubernetes for a web portal is usually made after analyzing the existing application and the existing software development process.

SaaS

There are three basic architectural concepts of how SaaS software is implemented:

  • multi.instance
  • multi-host
  • multi-tenant

Multi-instance means that a separate virtual or physical server is set up for each customer. The advantage of this solution is that the data are physically and logically separated from one another.

Multi-host, however, means that the application exists in different directories on the same physical or virtualized server. The customers thus share the resources.

With multi-instance and multi-host, the time required for the rollout of new versions without a suitable CI / CD workflow increases linearly with the number of customers. The same version must be rolled out on each host.

Multi-Tenant refers to an application that can already manage several customers or tenants on its own. The software can effectively be installed once and made available to several customers. The advantage of this approach is that the software theoretically requires fewer resources, but its complexity increases significantly.

!!!! Depending on the implementation of the SaaS solution, the same analyzes must be carried out as with a web portal. When managing multiple customers (multi-instance, multi-host) at the latest, the organizational overhead is drastically reduced. For multi-tenant applications, Kubernetes shows its advantage when it comes to autoscaling.

Conclusion

Whether or not Kubernetes should be used has to be considered individually. Kubernetes is definitely not the panacea for existing IT problems: in most cases, the complexity of the existing IT landscape is unnecessarily increased.