Building developer platforms: Tools, practices and the AI evolution

Bart: Graziano Casto works for Mia-Platform, and the transcript provides his basic introduction details.

Graziano: Hi everyone, I'm Graziano, joining you from Italy. I work as a Developer Relations Engineer at Mia-Platform, where we are passionate about empowering teams to build their own internal developer platform. Our goal is to harmonize platform engineering data and application composition together. Our mission is to help developers create the platform of their dreams with the flexibility and control they need to truly thrive—as we always say, "for better development."

Beyond my daily job, I'm very active in tech communities, whether through speaking at conferences, writing articles for major publications, or contributing to open source. Speaking of open source, I recently joined the Kubernetes organization as an active contributor in the Docs special interest group, helping to improve the documentation that so many of us rely on every day.

Bart: Graziano Casto mentions three Kubernetes emerging tools he is keeping an eye on:

1. K8sGPT - An AI-powered Kubernetes diagnostics tool

2. Crossplane - A cloud native control plane framework

3. KubeGreen - A Kubernetes operator for scheduling workload sleep/wake

The response is hyperlinked to provide additional context and resources for each tool mentioned.

Graziano: The first tool I want to show you is simple but can help you save money on your cloud build and reduce the carbon footprint of your system. It's called KubeGreen, a small Kubernetes operator that lets you set custom schedules for your workloads. Basically, you can tell your cluster when to sleep and wake up certain namespaces.

The main use case is for non-production environments like test or demo setups. They are usually only needed during working hours, but they tend to run 24-7. If we think about it, most of us work around 40 hours a week, while there are 168 hours in a week, so those environments are running four times more than necessary. Now imagine how many of those environments you have—development, tests, staging—it adds up quickly. That's a lot of wasted resources and money.

KubeGreen helps you stop that waste. It shuts down unused workloads automatically outside working hours, helping you save both cost and energy, which is good for your budget and the planet.

The second tool I want to share is a must-have in every platform engineer's toolbox. It's called KRO, a Kubernetes native framework that helps you create reusable APIs for deploying multiple resources as a single unit. With KRO, you can wrap Kubernetes deployment and all its dependencies into a single, easy-to-use API. This is super useful for application teams who might not be experts in Kubernetes. They can deploy what they need without worrying about underlying details.

KRO makes this possible through something called Resource Graph Definition. This lets you define how custom resources should be expanded into multiple Kubernetes resources automatically. In short, KRO helps you standardize how workloads are deployed and uses Kubernetes itself as the platform to enforce those standards, so your application team gets a simple experience while you, as a platform engineer, maintain control over how things are done.

For the last tool, if you're in application development, you've probably seen the rise of AI co-pilots like GitHub Copilot that help developers write code using large language models. But what if we brought the same idea to platform engineers? What if we had an AI assistant that could give us site readability superpowers? This is exactly what K8sGPT does.

K8sGPT uses natural language processing to scan your Kubernetes cluster, looking at events and other data to help detect and diagnose issues. It acts like a smart assistant that understands what's going wrong and explains it in human-readable terms. It comes with built-in analyzers that can spot common problems like crashes, service failures, or ingress misconfigurations, helping you troubleshoot faster with less digging around in services and Kubernetes configurations.

Bart: Now, in terms of the questions we're going to look at based on different podcast episodes that we've recorded, the first one is related to an episode with our guest Calin. He said there is a fine line between restricting people and empowering them. When you build a central platform, you are codifying the view of one person or group. Now, Graziano, how do you balance standardization with team autonomy in your organization?

Graziano: Standardization is key to managing clusters and platforms effectively, especially when multiple teams are involved. It's easier to build something for one team because the scope is smaller. When multiple teams use your platform, it becomes much more challenging. However, it's important to remember that the goal isn't to lock developers into a rigid workflow. We want to create a golden path, not a golden cage.

A golden path provides a paved, efficient, and opinionated way to deliver software. It helps developers move faster in their day-to-day work. For example, offering pre-built CI/CD pipeline templates, standard Helm charts, or Terraform modules can save a lot of time and reduce errors in the software delivery cycle. But developers should still have the flexibility to step off the path when they need to, such as for edge cases or advanced platform use cases.

That's why everything should be modular and overrideable when necessary. When it comes to abstraction, it's all about balance. A well-designed internal developer platform can abstract away infrastructure like provisioning a database or deploying a service to Kubernetes. But if these abstractions are too rigid or too far removed from reality, developers will either avoid them or end up fighting against them.

You should build abstractions based on real needs, not just to use the latest tech. If you create a custom deployment controller that only your team understands and no one else uses, you've added maintenance overhead without delivering value to other teams. You should always validate what you are building with the teams you are building for.

To summarize: standardize to create a reliable foundation, abstract to reduce friction, and always focus on the developer experience. You and your platform should enable your internal customers, not constrain them.

Bart: ` HTML tag

Graziano: Handling multi-tenancy across different namespaces and multi-cluster environments could lead to tool sprawl. It's not just about choosing the right tool, but using it in the correct context inside the platform and building experience about it.

When choosing the right tool for the right platform and avoiding tool sprawl, I approach it this way:

First, I always push for a GitOps workflow. It gives developers a simple and familiar way to request deployment of infrastructure or services using Git. Behind the scenes, the platform takes care of provisioning and enforcing policies. This provides a clean interface where developers get autonomy, and platform engineers maintain control and consistency.

Second, I like to create reusable and opinionated components using tools like Crossplane or Terraform. These allow you to define infrastructure building blocks with sensible defaults and security baked in. Instead of exposing raw cloud resources, we can give developers high-level building blocks like databases or service clusters that are easy to use and hard to misuse.

I'm a big fan of developer self-service. Using a developer portal, we can give teams a UI where they can request new environments or services without having to open tickets or dig into YAML files. This reduces friction and keeps the team's velocity high while the platform does the heavy lifting behind the scenes.

I suggest treating the platform like a product. This means documenting everything well, communicating clearly, and collecting feedback regularly. It's not enough to build something technically advanced if no one uses it. I always try to talk to developers, understand their real needs, and identify what's getting in their way.

Finally, I try to measure adoption. If the tools and processes we put in place are being used, that's a signal we need to improve. We might be too complex or solving the wrong problems, and tracking usage helps us stay aligned with the teams we support.

Bart: 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?

Graziano: Crossplane is a great example of a tool that helps to close the gap between platform engineers and developers. But it's not just about picking the right tool, it's also about how you build the experience around it. Here's how I approach building a platform for multiple teams:

First, I always push for a GitOps workflow. It gives developers a simple, familiar way to request infrastructure or deploy services using Git. Behind the scenes, the platform takes care of provisioning and enforcing policies, with clear interfaces where developers get autonomy and platform engineers can maintain control and consistency.

Second, I like to create reusable and opinionated components. Tools like Crossplane or Terraform let you define infrastructure building blocks with sensible defaults and security baked in. Instead of exposing raw cloud resources like GKE clusters, we can give developers high-level building blocks like databases or service clusters that are easy to use and hard to misuse.

Third, I'm a big fan of developer self-service. Using a developer portal, we can give teams a UI where they can request new environments or services without opening tickets to ops team or digging into complex YAML files. This reduces friction and keeps team velocity high while the platform does the heavy lifting, essentially reducing bottlenecks for developers.

Fourth, I suggest treating the platform like a product. This means documenting everything well, communicating clearly, and collecting feedback from internal customers regularly. It's not enough to build something technically advanced if no one uses it.

To use a metaphor, think of the platform like a kitchen. You can build the best kitchen in the world with top-notch kitchenware, but if you forget to invite the chef and train them to cook, it's a waste of time and resources. I always recommend talking with developers to understand their real needs and what's getting in their way.

Finally, I try to measure adoption. KPIs for platform engineering are crucial. If the tools and processes we implement aren't being used by developers, that's a signal we need to improve or pivot to another approach. We might be too complex or solving the wrong problem. Tracking usage helps us stay aligned with what teams need and what we're providing to support them.

Bart: Kubernetes turned 10 years old last year. What should we expect in the next 10 years to come? What do you think is on the radar? What kind of technologies do you think we can see integrating with Kubernetes?

Potential technologies that could be interesting to link:

• Crossplane for cloud native control plane

• Kubevirt for virtual machine management

• K8sGPT for AI-powered diagnostics

• Open Policy Agent for policy management

• KubeGreen for workload scheduling

Note: The speaker Graziano Casto works for Mia-Platform, which could be an interesting additional context link.

Graziano: Kubernetes has come a long way in its first 10 years, from being seen as just a container orchestration tool to becoming the backbone of modern cloud-native infrastructure. But as it matures, the next 10 years won't be about reinventing the core of the tool. It will be about refining the developer experience, simplifying operations, and making Kubernetes invisible.

One shift is already happening: the rise of IDPs (Internal Developer Platforms) on top of Kubernetes. Instead of making every engineer learn how to write YAML or understand cluster internals, more companies are adopting IDPs to give developers a simple interface to interact with complex tools like Kubernetes clusters. Kubernetes becomes the plumbing behind the scenes while developers interact with higher-level abstractions that map to their use cases.

We will likely see infrastructure become more programmable and policy-driven by default. Tools like Crossplane and Open Policy Agent are early signs of this trend. Infrastructure will look more like APIs—more secure, governed, and managed declaratively. This means platform teams will spend less time on ticket-based work and more time building reusable components and guardrails that scale across different teams and organizations.

AI will play a big role, especially around observability, optimization, and autoscaling. Instead of just monitoring metrics and setting thresholds manually, we will likely see smarter systems that can detect anomalies, suggest right-sizing changes, or even fix issues proactively. The SRE model will evolve from reactive firefighting to proactive tuning.

At the same time, the entire ecosystem will need to tackle this complexity. One of the biggest criticisms of Kubernetes today is how steep the learning curve still is after 10 years. We can expect better tooling, more opinionated frameworks, and maybe even lighter alternatives for simple use cases.

Overall, Kubernetes is probably going to fade into the background. Still critical, still powerful, but less visible—just like we don't think about how the operating system on our PC or MacBook manages memory anymore. Kubernetes will become part of the infrastructure fabric, with the focus shifting to developer experience and the business value built on top of it instead of the complexity of the tool's internals.

Bart: And looking at the future, what's next for you?

Graziano: We are actually working on this right now. On our platform, we have recently started evolving our product into an AI-native developer platform foundation. The idea is to explore how AI and generative AI models can be applied to internal developer platforms to drastically improve the developer experience.

We are trying to rethink the software development lifecycle by combining the power of AI with the context that platforms are able to provide. We all know how useful tools like GitHub Copilot can be when it comes to writing code. Now, imagine expanding the same kind of support to the entire platform.

For example, we can use AI to help developers discover and understand platform components. We can use AI to gain insights on how to use and connect these components. We can use AI to debug deployed services and analyze observability data to detect early signals of application degradation before it becomes a real issue. This is a more productive way to approach observability.

The goal is to turn the platform into an intelligent companion—one that not only helps developers move faster but also makes their work easier, more reliable, and more enjoyable. We believe this is the next step in platform engineering, and it's something we are really excited to build.

Bart: Last but not least, how can people get in touch with Graziano Casto?

Graziano: Feel free to reach out to me on LinkedIn, GitHub, or CNCF Slack. Just search for my name and start a conversation with a simple "hey". I'm also often attending industry conferences and events across Europe and the US, so if you see me around, don't hesitate to stop me and say hi. I'd be more than happy.