Bridging development and adoption: the future of Kubernetes tooling

Bart: Welcome to KubeFM. First of all, who are you, what's your role, and where do you work?

Eyal: Hi, I'm Eyal Bukchin. I am the CTO and co-founder at MetalBear, where we build Mirrord, an open source project that lets you run a local process in the context of your Kubernetes cluster and cut down your feedback loop.

Bart: Three emerging Kubernetes tools that Eyal Bukchin is keeping an eye on are:

1. Mirrord - developed by his own company MetalBear

2. GlassKube

3. Robusta

He also mentioned LocalStack as a tool for local development.

Eyal: One interesting tool is called GlassKube. They chose a really interesting problem to tackle: providing on-prem software for clients. It's a great management platform. Another tool is Robusta, which is for incident response. This would have been very helpful in my previous work, where we had a high-scale production system that was hard to support with many people involved.

Another tool, not purely Kubernetes-related, is LocalStack. At Mirrord, we're staunch proponents of local development, and LocalStack is a big league player in this area. There are many interesting developments to keep track of.

Bart: On the subject of tooling and platform engineering, our guest stressed that standardizing everything makes cluster management easier. What's your advice for building platforms that can be used by several teams in an organization?

Eyal: I think one thing engineers tend to overlook is that building a really good product doesn't automatically mean people will use it. From our experience implementing Mirrord at various large organizations, building the product is just the first step. There's a very intricate and long process that has to follow. You have to hold many hands, track adoption, constantly detect blockers, and be passionate about gathering feedback. However, it's difficult because you don't want to force people to use it. There's a delicate balance.

To sum up: don't think your work is over when you've built a good product, even if it applies to everyone. Don't ignore the adoption process.

Bart: On the subject of using boring yet simple tools, our guest Luca built a container runtime in C in his spare time. He shared that during his career, he moved from using the latest tech to focusing on working with a more limited set of tools, becoming a real expert. What's your advice regarding adopting new technologies in your personal life and work, particularly in a Kubernetes cluster?

Eyal: I think it's a really interesting question at this time, with AI and the level of abstraction that tooling provides, which has jumped a few levels. The answer lies there. As engineers, we have a job to do, and it doesn't matter how we do it. However, it's not that simple, especially when thinking about junior engineers. There's the question of when to actually learn the basics and understand what's going on behind the scenes, because these fundamentals will inevitably affect the quality of decisions later on.

There's really no escaping abstraction and advanced tooling. The best way forward, for me personally, is to find the best tool for the job, no matter how it does it.

Bart: If we're going to be talking about platform engineering and people, our guest, Ori, shared that rushing into solutions without understanding the root cause can lead to fixing symptoms instead of the actual problem. He mentioned the case of network policies and how sometimes the root cause of a problem is a people problem, and the solution lies in addressing that. What is your experience with providing tooling and platforms on Kubernetes to other engineers? What are some of the soft challenges that you faced?

Eyal: Yes, I think I touched upon it a little bit in the first question. We're all—engineers and non-engineers—resistant to change. With engineers, in my experience, there's a lot of skepticism around new tooling. There are entrenched habits that are hard to break, and a tendency to try and build stuff yourself or trust more in things that, if you didn't build yourself, you at least know very well how they work under the hood. These are all challenges we faced at Mirrord. To summarize, you have to know and understand these specific challenges and resistances in order to disarm them.

Bart: Kubernetes turned 10 years old last year. What do you think is going to happen in the next 10 years?

Eyal: In the last few years, the trend in tooling has been that the development stage was relatively neglected compared to operations, deployment, monitoring, and observability. There's an interesting movement of catching up now, especially with AI around coding. But in the end, and this is especially painful for Kubernetes deployment, you have to have a way to run and test your code in a way that reflects production. There are a lot of interesting startups in this area, and I think this is going to undergo a really interesting change in the next couple of years.

Bart: I notice that the transcript snippet is very short and lacks context about what "next" refers to. Without more context from the surrounding conversation, I cannot confidently add hyperlinks. Could you provide more of the transcript or context around this question?

Eyal: We are working hard on Mirrord. Last year, we released what we're calling Mirrord for Teams, which is a paid version of Mirrord and makes it more suitable for enterprises. This is our main focus at the moment. We're seeing great traction and growing the team. Mirrord will be my focus for the next couple of years.

Bart: How can people get in touch with you? MetalBear has a Discord where people can connect with the team.

Eyal: I'm available through various channels: Twitter, our Discord, or by email.