Icing on the Cake

Finally, the question arises as to whether smaller organizations can also benefit from the colorful world of cloud-native applications. Remember, cloud native means a form of application development that does away with large monoliths and instead relies on a network of microprograms that communicate with each other over defined interfaces. Each mini-app has a single, specific task.

The model has many advantages in practice. For example, it means that the individual components can be developed completely independently of each other and do not require common release cycles. It also implicitly avoids the horror scenario of release day fails, where a huge, monolithic application finally finds its way into production after months of development. Often enough, companies only discover what is not working at this point and frantically beat a retreat. The cloud-native development model avoids this issue.

That said, many SMEs do not use in-house applications that would have these issues. This situation is all the more true if the company's focus is not on IT, but IT is a means to an end. If you do not develop applications in-house, you will not benefit from the cloud-native principle initially. On the other hand, if you have existing applications with an old design, you will certainly benefit from migrating to a cloud-native approach. Many large companies have shown how this can be done by consistently ditching old habits and, in some cases, discarding applications that have been used for decades and rebuilding them on cloud-native lines. Of course, this presupposes the luxury of having the time and resources to do so. For many SMEs, this is probably not the case.

Cloud-Native Help

From an admin's point of view, it might be worthwhile to take a closer look at some of the principles of cloud-native design. Even if your own application is a containerized monolith, the cloud-native approach has brought about a number of changes that make sense outside of native cloud apps. One good example of this is sidecars, which can be installed in Kubernetes parallel to the containers with the applications. In the above example with MariaDB and Galera, one sidecar would definitely add some value.

The one I have in mind is Istio (Figure 6), a tool that controls the connections between the individual components in micro-apps, encrypts them, and acts as a load balancer. However, even a Galera cluster needs a load balancer to offer meaningful access to clients because you can't give most database clients multiple IP addresses. On top of that, doing so would be clumsy because – in the worst case – the client might just connect to a Galera instance that is not working.

Figure 6: Although Istio is intended for the world of cloud-native applications, it can also be used meaningfully with conventional services such as MySQL or Galera. © Istio

Kubernetes only offers a simple balancer in the form of a service IP, whereas Istio can do far more and can be rolled out as a sidecar to Galera. Because Istio runs as a highly available component in Kubernetes, you can even save yourself the trouble of running a separate load balancer, regardless of whether it uses Linux or comes in the form of an appliance.

Words of Warning

Despite all the euphoria about container orchestration and the added value that containers undoubtedly offer, even for small companies, a warning will not go amiss at the end of this article. Many have already proclaimed this warning several times, but the problem has hardly changed in the meantime.

The idea of shipping an application and its userland as a container has many merits, but in a corporate environment, you should only use vendor-provided images for which you have no doubt about how they were built and only if you can be sure that the vendor regularly maintains its images.

If this is not the case, it makes more sense in most cases to bite the bullet and bundle the application in a container of your own design. A CI/CD system for this can be implemented without too much hardware, as mentioned earlier. The reward for this extra work is the certainty that, as an admin, you can respond quickly to problems such as vulnerabilities without having to rely on a provider.

Customers of vendors that offer their applications as black box containers also need to communicate clearly to the vendor that this is unacceptable. In your own interest, you should only use containers in production if you are familiar with and understand their inner workings.