Bart Farrell: So first things first, who are you, what's your role and where do you work?
Sebastien Allamand: So I'm Sebastien Allamand, I'm a solution and containers specialist working in EMEA based in France, south of France and working mainly on Kubernetes and EKS stuff.
Bart Farrell: What are three emerging Kubernetes tools that you're keeping an eye on?
Sebastien Allamand: I would say the first one is Karpenter, the open source tool that allows you to just define the application you want to deploy and let the tool create the nodes you want to have. The second one maybe will be like, it's not really a Kubernetes thing, but it's like the Kiro CLI that allows you to do some troubleshooting, working nodes with the EKS MCP, so know how to talk to Kubernetes. And maybe lastly will be like a K-agent, which is also very promising to work with agents, troubleshooting DevOps agents for your Kubernetes management.
Bart Farrell: Platform engineers have a running joke. I just need to deploy a simple web app. And then you realize that Simple needs a container, a database, an S3 bucket, a cache, a queue, some IAM roles, and about 47 YAML files that all need to work together. What's actually happening here that makes Simple so complicated?
Sebastien Allamand: So Simple is complicated because we do a lot of micro services, we have a lot of managed services that we want to connect to, and the glue is difficult for that. Like we have the ACK service that works for many years today that allows to define some Kubernetes object that will create AWS resources. But all of those resources are just independent. Like you just create maybe a VPC, which have VPC ID, and then how you link that to what you want to create. If you create a database, how you put the database credentials into your deployment. This is difficult and needs complex tools to do that.
Bart Farrell: What did AWS build to solve this issue? And what does this mean for developers and SaaS platform teams managing multi-tenant infrastructure?
Sebastien Allamand: So one of the tools that we built is KRO, so KRO for Kubernetes Resource Orchestration. And these tools allow you to just define compositions and define new API. So KRO allows you to create new API directly in Kubernetes. So you just define your new API, the input, the output, and all the resources that will be created from that. So let's say we want to take back my first example. I want to first create a database when I deploy my applications. So I define my application in resource. I will first create an ACK object to create the database, maybe store the secret in secret management. Then I mean my deployments, which will retrieve the secret from secret management, retrieve the endpoints from the database. So KRO allows you to do all the glue for that. And we just, the user simply just instantiate my application, define the name, and all the dependent resources will be created and linked automatically with KRO.
Bart Farrell: Once platform teams have built these reusable abstractions with KRO, what does this actually change for the organization? How does this shift? the way platform teams and developers work together.
Sebastien Allamand: So before that, we can see like many Terraform pipelines, so different teams managing Terraform, maybe Terraform to create some VPC, Terraform to create some database, and you need to have the organization to link people together to check how to talk together, how to retrieve the output from Terraform. So when moving this shift and work only with Kubernetes, everything is stored in just one state which is the etcd database. You just define your components, your resources, the platform team just define some reasonable, hardened components and just the users just can use them and deploy everything without meaning to create some meetings with different teams and talk to each other.
Bart Farrell: How do they work together and where can teams learn more?
Sebastien Allamand: Okay so for working together it's just like basically using the Kubernetes API, the KRO abstractions, so defining some of those resources and to learn more on that maybe the first task will be to go to the KRO website, so kro.run. websites where you can see lots of examples. And obviously that works on AWS, that works on Google, that works on Microsoft. And again, you can define anything from KRO, even your own manifest that you want to deploy, maybe for some specific stuff that you have on your own, you can just use KRO for that also.
Bart Farrell: Kubernetes turned 10 years old about two years ago. What can we expect in the next 10 years?
Sebastien Allamand: So I will see a lot of shifting management API in Kubernetes. We see also a lot of engagement with GenAI tools and agentic. So I think we will have more and more agents that are working in Kubernetes, allow you to manage more and more applications and work on the fly for what you want.
Bart Farrell: What about you, Sebastian? What's next for you?
Sebastien Allamand: So for me, I'm specializing in Kubernetes. I want also to work more on the old GenAI stuff and work more on how to build and maintain a platform agentics we touch a lot from few years back how to do GitOps to manage deployments. And now I don't want like to have an agent that will do some ClickOps. So we want to enforce agents that will work back with GitOps. Just do, just read anything, but don't write anything to the API or to the cloud providers, but just write anything back to Git. and then let the pipeline GitHub that we built many years, that worked together. So, what we want for that, for Kubernetes for the future years also coming.
Bart Farrell: And if people want to get in touch with you, what's the best way to do that?
Sebastien Allamand: The best way would be on LinkedIn or on many GitHub repos that I maintain. Just go up on issue and discuss, but LinkedIn will be the more efficient.
