|Blog

Not too long ago, it was unheard of to put persistent data on Kubernetes. The wise operator would almost certainly have reached for a comparable cloud service and sacrificed functionality for the sake of simplicity and peace of mind.But over the past few years, Kubernetes has matured and grown into areas that would not previously have been considered suitable for container orchestration. This is largely due to the increased stability and feature set of Kubernetes and its growing sophistication as a platform. One of the more powerful features to have emerged in recent releases is the combination of [Custom Resource Definitions] (CRDs) and the [Operator Pattern].

The more distributed a software system is designed, the more you should think about resilience. Because of the distribution, calling the involved communication partners can and will often lead to errors. In order to keep the effects of these errors as small as possible, or to avoid them completely, it has become the norm to work with the necessary resilience patterns. But what is the right approach for dealing with resilience? A service mesh tool or a framework? Both approaches have their pros and cons.

In the future, many companies will try to grow their IT infrastructure with the help of the Cloud or even relocate it completely to the Cloud. Larger companies often request multi-cloud solutions. In terms of serverless frameworks, there are several ways to achieve multi-cloud operation. Using AWS Lambda, a function can be provided and the whole thing can be made cloud-independent with Knative.

Service Meshes are currently a very popular topic in IT: Microservices architectures are growing continuously and with them the difficulty of keeping track. We spoke with Patrick Arnold, IT consultant at Pentasys AG, about service meshes such as Istio, Linkerd and solo.io and best practices when using them.