Building developer-friendly platforms on Kubernetes

Bart: Welcome to KubeFM. First and foremost, could you tell me who you are, what's your role, and where you work?

Petar: Hi, my name is Petar. I'm from Zagreb, Croatia. I'm currently the co-founder and CTO of Cyclops. We're building an open-source dev tool that helps companies and developers build custom dev platforms on top of Kubernetes. We help companies create a custom UI to deploy all their applications, regardless of their use case, and fast-track the process of managing manifests and YAML from development.

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

Petar: Cyclops aside, the tools I find most attractive are those that view Kubernetes not just as a container runtime, but as a centralized place to configure all software. For example, Crossplane did a good job of creating custom control planes for developers, providing a declarative configuration style while keeping it user-friendly. Crossplane isn't new, but KRO from AWS, launched a couple of months ago, seems like a simpler version of Crossplane. Additionally, tools like Backstage are similar to our approach, giving developers full autonomy over their applications and systems.

Bart: One of our podcast guests, Hans, argues that GitOps is an excellent building block for building platforms with great developer experience. He mentioned the ability to merge, review, and discuss code changes in PRs and the additional benefit of not granting permissions. Should all platforms use GitOps? What's your experience?

Petar: Since we market ourselves as the dynamic UI for Cyclops, we get GitOps questions a lot because GitOps and ClickOps are the two ways to configure your applications. GitOps usually comes with the implication that your developers understand infrastructure as code. For example, if you want to use a GitOps tool on top of Kubernetes, like ArgoCD, your developers actually need to understand Kubernetes manifests, Kustomize, Helm, or other configuration methods.

Usually, that's not the case. Your developers are not proficient with Kubernetes and its ecosystem. I think GitOps is a good way to start and is necessary for production systems. You need to persist that configuration. However, GitOps might not be the most friendly way to communicate with Kubernetes clusters.

In my previous experiences, I've used ArgoCD extensively. It did its job, but it's crucial to consider how you'll configure it with other tools. You still need to ensure that your developers get the best development experience and that Kustomize helps, rather than hinders, application deployment.

Bart: Our guest Angel 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?

Petar: I think it goes hand in hand with the point on GitOps, where GitOps is a good building block for how you deploy and roll out your applications. A good tool for Kubernetes and platform engineering is something that provides flexibility to combine with other tools and solve a specific portion of the problem.

Platform engineers should come up with a solution that's custom to your specific use cases and applications. It should be friendly, easy to use, and do its job regarding flexibility and use cases. Platform engineers should know how to pick and choose tools from the market to create a coherent developer platform that other developers can use.

The most important thing is to remember that your developers are your customers. You need to listen to what they need and what they're using, instead of building something that's only flexible for you within the company.

Regarding tooling, companies building tools should keep in mind the flexibility they need to provide, and companies should mix and match tools to suit their requirements.

Bart: Continuing the topic of platform engineering, specifically looking at Crossplane, our guest Angel expressed interest in Crossplane for bridging the gap between platform users and owners. What tools or practices do you recommend for bridging the gap between developers and platform engineers?

Petar: I really like what Crossplane did with extending Kubernetes and being the dynamic control plane for applications. Kubernetes allows you to extend the Kubernetes API so you can do whatever you want, and Kubernetes becomes the beacon for your developers. I think that's something underutilized in companies—I didn't often see companies building custom controllers for their specific use cases, but it's definitely something that should be more utilized.

The same way you want to deploy applications through Kubernetes deployments, you should be able to provision databases on AWS through the same workflow. On top of that, you can add GitOps or other tools. What Kubernetes did is provide a good starting point for building developer platforms, bridging the gap between platform engineers and developers. Platform engineers can define a set of rules on how things are done in the company, and developers get a simple interface to applications, databases, and more—everything should be developer-friendly.

Kubernetes turned 10 years old last year. What can we expect in the next 10 years? That's a hard question. I've been working with Kubernetes for the past five years, so I can't say definitively. The one thing I'm certain about is that AI is not the answer to the challenges we're currently facing with application configuration.

I expect that in the next couple of years, the operator pattern will be much more widely used within companies and tools built on top of Kubernetes. But as a general answer, I can't really say.

Bart: What's next for you?

Petar: Since we started building the startup a year and a half ago, we are shipping new features. We are actually having a launch week now, which is pretty exciting. We are looking to solve the problem of how platform engineers build internal developer platforms for their teams. That's what I'll be doing in the next couple of years.

Bart: Petar Cvitanović suggests people can get in touch with him through Cyclops, the open-source developer tool for Kubernetes that he works with.

Petar: You can reach out to me on LinkedIn or through GitHub. Links will be available in the comments.