The future of databases and observability in Kubernetes

Bart: Who are you? Tell me about your role and who you work for.

Peter: My name is Peter Zaitsev. You can think of me as a portfolio entrepreneur these days. Specifically, I'm well known as the founder of Percona, and now I'm also involved as a co-founder in Coroot.

Bart: What are three emerging Kubernetes tools that you're keeping an eye on?

Peter: I won't try to be unbiased in answering this, and I'll mention some projects I'm involved with, which I'm excited about. One is Percona Everest, a project currently in beta, which provides a cool GUI, similar to Amazon RDS, to run databases on Kubernetes. It's essentially a GUI on top of the Kubernetes operators, and it's open source. The second one is Coroot. We just recently released the first GA version, so it's a pretty emerging tool that provides easy-to-use observability for Kubernetes. The third project I'd like to mention is Victoria Metrics. Although it's not specifically a Kubernetes-specific tool, it's a very efficient Prometheus replacement, which I think is very important these days as Kubernetes clusters grow larger and larger, requiring more and more telemetry to be stored efficiently.

Bart: One of our guests, Steven Sklar, shared that you can and should run databases on Kubernetes. The two-item practices have matured since Kubernetes began, and you should run stateful applications there. What's your experience and advice when it comes to running stateful applications in Kubernetes?

Peter: I think Steven Sklar is right. I also see that as an option, a hot button, because of an early days Kubernetes story that Kubernetes is designed for stateless applications. Many people still hold to that truth from years ago. At Percona, specifically, we have Kubernetes operators for all the databases we support, and we have very large customers running serious workloads in Kubernetes, which works pretty well. What I think is important, though, is that you need to exercise proper care because Kubernetes can still play pretty fast and loose with your pods. If you don't configure it properly, you can lose your data, which is quite unpleasant.

Bart: One of our guests, Matt, shared that most teams store logs and metrics in Kubernetes without considering the implications of the data they collect. Consequently, they end up paying a hefty price for data that is not actually used. What's your advice on ingesting, storing, and querying metrics in Kubernetes?

Peter: I think this is true. It's very interesting. Besides the complexity of Kubernetes, you hear about folks who have almost as much infrastructure supporting collecting and processing telemetry for the main application. This is bizarre, as the main application is the primary focus. There are two key considerations: first, be selective and don't store all the data just because you can; second, use proper, state-of-the-art technologies that allow for efficient storage, such as Victoria Metrics, which features data compression and new vectorized processing techniques, providing a significant difference - at least 10x - between storing logs in last-generation systems and using the most optimized modern systems.

Bart: Learning cost optimization, ARM instances. One of our guests, Miguel Bernabeu, shared that Adevinta migrated their Kubernetes cluster to support ARM instances and workloads because they are more cost-effective. Do you have any practical advice on reducing your Kubernetes cost optimization?

Peter: I think moving to ARM can be a good cost optimization, especially if cloud vendors make ARM instances more cost-attractive for performance. However, the caveat is that not all software is supported or well-optimized to run on ARM, so results may vary. I wouldn't rely on this as a sole solution, because it's possible to waste resources, even if they are cheaper. With Kubernetes clusters, it's very important to right-size to avoid running with a lot of slack, as well as follow best practices. In many cases, developers leave unused instances or forget about unnecessary resources. Having a policy to only run necessary workloads in Kubernetes and ensuring they are properly optimized is, I think, the majority of the solution.

Bart: Kubernetes is turning 10 years old this year. What should we expect in the next 10 years to come?

Peter: It's hard to make predictions, especially about the future. But I think what's interesting is that over the past 10 years, we've been able to build a lot of things in Kubernetes. And I think you can see an increasing number of people saying that Kubernetes is kind of very complicated, with a steep learning curve. I think that over the next 10 years, Kubernetes should focus on being easy, maybe by building frameworks on top of it, so that the complexity can be hidden for users who don't need it. What's next for you? I recently got involved with Coroot as a co-founder, so building and growing this project is my next focus.

Bart: What's the best way for people to get in touch with you?

Peter: You can get in touch with me by email at [email protected].