We spoke with Max Körbächer, a Co-Founder and Cloud Native Advocate at Liquid Reply, and also a member of the Kubernetes release team. Max's expertise is primarily in designing and building cloud native solutions using Kubernetes in various environments, as well as platform engineering to address complex system challenges. Here's what he shared with us about his area of expertise.

devmio: Hello Max, thank you for taking the time to answer our questions! First of all, could you tell our readers a little bit about yourself and your background?

Max Körbächer: Yes, sure, thank you for having me! Well, where should I start? I come from an old-fashioned career category known as Enterprise Architecture. I was intrigued with this topic for some reason throughout the first part of my career, which led me to work for and inside various CIO teams in Germany. At the time, I also came across Kubernetes and, more specifically, OpenShift. I got addicted to the whole cloud-native stuff and eventually moved on to consulting and am now running a consulting company focusing on cloud-agnostic, Kubernetes-based platforms and developing microservices. I worked on the Kubernetes Release Team for three years, contributed to the Kubernetes Docs, and founded and co-chaired the Cloud Native Computing Foundation (CNCF) Technical Advisory Group (TAG) for Environmental Sustainability. The TAG focuses on how to bring situational awareness and best practices to the open source community for optimizing tools in terms of CO2e (e for equivalent) output, as well as how to make Kubernetes capable of minimizing CO2e output for applications running on it. In addition, I recently became a CNCF Ambassador and a member of the Linux Foundation Europe Advisory Board.

devmio: What are some common misconceptions about cloud native and Kubernetes, and how do you dispel them?

Max Körbächer: Kubernetes is often seen as a tool for running containers, similar to VMware's hypervisor for running virtual machines. However, Kubernetes performs two key functions: it orchestrates and manages the containers running on a host within a container runtime like containerd. Kubernetes does not run the container; it can be fully disabled, but the container may still run. Second, it is a platform or environment in which more tools can be built and integrated. Kubernetes provides a standardized way for all of those systems to integrate with one another.

Cloud native causes a lot of misunderstanding in my opinion because it is difficult to explain. Companies who run, build on, or provide services for public cloud providers such as AWS or GCP overuse it. They typically mean that something is created specifically for or on a particular cloud. There is one approach, for example, to fix a problem on a cloud provider. It is native to the cloud. However, if you respond to the problem cloud natively, you may have 2-3 more options. You will undoubtedly need to install more tools, but you may use it the same way practically anywhere, including another public cloud, your private cloud, or even your local machine for development and testing.

I agree with the Cloud Native Computing Foundation's (CNCF) definition which says that cloud native is about scalability, resilient systems, declarative APIs, microservices, immutable infrastructure, speed, and flexibility.

What you can count on is that Kubernetes can be deployed anywhere and will adhere to the same principles and approaches.

devmio: What are the common challenges organizations face when migrating to cloud native and Kubernetes, and how do you help them address these challenges?

Max Körbächer: After many years of migrating and mentoring, the major issue is knowledge, and classic applications are not designed to be as dynamic. Those who embrace cloud native have less budget and time. We commonly encounter "fast" training consisting of a few short videos online and that's it. People that are really interested use this as a starting point and then move on, driven by their own curiosity. However, this instance only applies to only a handful of people.

We encourage our partners to attend regional, one- or two-day, more personal conferences like the Kubernetes Community Days. As a result, you have an excellent chance to catch the speaker right after. Furthermore, we provide training as well as knowledge-sharing and workshop sessions. This is often challenging. Pushing all the knowledge and complexity of Kubernetes and cloud native causes many heads to spin.

devmio: Can you discuss your approach to training and onboarding teams for cloud native and Kubernetes?

Max Körbächer: It is essential to identify what the provided baseline is. Also, we often talk about the cloud and how modern everything is. The fundamentals of networking, system management, and CICD/automation must be included. If this is not provided, it can be supplemented with some online courses and hands-on training events, such as the Linux Foundation's cloud engineering and DevOps boot camp. It will not make anyone an expert in that topic, but it will alleviate the fear of trying something new.

We next proceed to personalized training, which is tailored to the needs of the customer. A large portion of the required knowledge is common. We frequently come with varied wordings and governance standards that we must examine. From small to big, we work on containers, container networking, container building, Kubernetes architecture, different API objects, and how to write a manifest to deploy a container using Kubernetes. From here, we distinguish whether you are a Developer or a Platform Engineer. This is important for hands-on experience and troubleshooting environments or apps. Finally, we discuss Helm, GitOps, Security, and Observability. That's a long way to go, and if done right, it's seen as a journey and change rather than a relaxing Sunday afternoon stroll.

If you want to build a Kubernetes-based micro service system, not a monolith, you need to know a lot today.

devmio: What are the benefits of using Kubernetes over some other container orchestration solutions?

Max Körbächer: Costs, flexibility, and versatility. To be honest, the majority of container orchestration solutions are based on or revolve around Kubernetes. In such cases, operational costs are sometimes overlooked. In reality, there is no discernible difference between running a commercially licensed platform and a self-built one. The time it takes to create and implement a project varies depending on how good your team is and how complex your requirements are. The advantage is that teams that went the hard road and built everything from scratch are experts. They can continue to transform the platform and resolve any problems that arise. If you buy it, you don't have this experience.

What you can count on is that Kubernetes can be deployed anywhere and will adhere to the same principles and approaches. It allows you to customize it as much as you want. This can be both painful and useful. Kubernetes has handled point-of-presence nodes and globally connected clusters running across continents while complying to local laws.

However, it may appear to the end user that Kubernetes is too complex and that they need a simple container drop-in solution.

devmio: What are some of the challenges developers face when using Kubernetes?

Max Körbächer: An extensive debate is taking place regarding how much knowledge about Kubernetes a developer needs.

If you want to build a Kubernetes-based micro service system, not a monolith, you need to know a lot today. This may not be ideal, but it is the situation. And this is exactly the current challenge. If development teams are not properly trained, we commonly see companies fail or struggle to implement containers and Kubernetes. But perhaps we should reconsider the role of developers. When it comes to the role of a system administrator, it has evolved with the cloud, then with DevOps, and now with platform engineering. What are the major changes in the developer role? Could Kubernetes be the catalyst for this transition now?

The open source market surrounding Kubernetes and the cloud native space is evolving and changing at breakneck speed.

devmio: What are some of the best practices for managing and monitoring a Kubernetes cluster?

Max Körbächer: I'm an advocate of a lightweight stack like Grafana and all of its various implementations. OpenTelemtry and Prometheus Agents are the de facto standard at the node level. Both can be integrated into practically any observability solution on the market. I see major challenges with multi-tenant clusters and the separation of all telemetry data. The proper use of labels and tags is the best practice. Unfortunately, we frequently see this missing across all cluster layers.

Managing clusters is an interesting topic. Why? Because the concepts surrounding them constantly change. Crossplane, for example, runs on Kubernetes, which allows you to throw in yaml files and it will create new ones on any cloud provider's new Kubernetes clusters. But how do you get the initial cluster? Where do you draw the line between infrastructure as code, which requires you to first build the landing zone within a cloud provider? Terraform, on the other hand, is also used to deploy apps on Kubernetes. But just because you can, does not mean you should. The life cycles of infrastructure and applications are different. Binding them together will drag you down in one direction or the other. At the moment, I strongly suggest:

• Build your infrastructure foundation with Terraform and, depending on the complexity of your environments, use a professional tool such as env0 or Terraform Cloud in addition to a GitHub/GitLab pipeline.
• Furthermore, it is time to move on to solutions that simplify cluster management. I see companies working for years to complete something, while you should take the opportunity to focus on your surroundings.
• Speaking of surroundings, this is where we have the greatest challenge. This is possible with IaC, but it always requires CI/CD pipelines, which feel cumbersome today. In the coming years, we will see significant changes in this area.

We are strongly moving in the direction that we abstract away the cloud providers. Kubernetes is getting more than the cloud of clouds. Not that we have to run everything in containers, but that we have one unified API through which you can tell what your criteria are (costs, sustainability, speed, latency etc.), what is the application you want to run, and the rest will be optimized and decided for you.

devmio: How does one optimize the resource utilization and cost efficiency of Kubernetes clusters?

Max Körbächer: There are many ways to get started, ranging from simple infrastructure analysis to reviewing the entire system setup and architecture, and even down to the code. However, you must also look to the left and right of the system, such as the CI/CD pipelines.

Checking the cloud provider resources used is the quickest and easiest way to reduce resource use. You can do this using specialized tools or by analyzing monitoring data about your software's activity and resource requirements. The typical overprovisioning, yes, even with containers, is a prevalent anti-pattern. Misconfigured managed services for Serverless or API management. Finally, the "We need HA and high performance everywhere" configuration of databases, communications systems, and other systems. What you should also look at is your data:

• How and where do you store it?
• How often do you need to access it? Can you reduce the storage class?
• How much data is outbound?
• Do you have to send so much data all the time?

Data, you see, is a major cost driver. API gateways, on the other hand, are also quite expensive solutions. You must re-architect your solution, implement caches, run your own API gateway, and so on to optimize this.

In addition, completely shutting off resources is incredibly efficient. Internal systems that require simply Mo-Fr from 8 to 8 will immediately save you 50% of your costs. When you are not in your regular sales hours, you can at least lower redundancy or big scaled compute power for customer-facing products.

There can be a difference if you want to optimize your system for resource efficiency, say, to cut energy use and reduce your "green" footprint. Because if latency isn't an issue and you don't have a lot of outgoing data, you can run your system somewhere else on the planet, where it's now less expensive than the nearest data center. It also requires a change in the system's architecture.

devmio: How do you stay current with developments in cloud native and Kubernetes?

Max Körbächer: That's the most challenging part. The open source market surrounding Kubernetes and the cloud native space is evolving and changing at breakneck speed. The good news is that you have a variety of formats to choose from. You will find something that suits your preferences.

Every day, I listen to the Google Kubernets Podcast, receive the AWS EKS and CNCF KubeWeekly Newsletters, and participate in various OSS Slack channels. This covers the basics, and I also follow other sources based on what I'm currently interested in. I try to attend meetings and conferences whenever possible. There are fantastic free events for almost every technology and focus area. However, my team is ultimately the best source of knowledge and knowledge sharing because everyone has their own area of interest and expertise that they share with the team.

The key is to stay active and curious. You must look into actively informing yourself to keep track.