CDEvents Simplifies AI-Ready Developer Platforms

Hey everybody, we're back here in Minneapolis at the Open Source Summit, and we're having a little chat about, well, internal developer platforms, otherwise known as IDPs, and how to make them a whole lot simpler to build and maintain. Dadisi, welcome to the show. Thank you so much.

All right. So you guys had an announcement talking about how we can build these things in a way that reduces the integration complexity. So I'm going to let you explain what it is you guys are doing, and we'll go from there.

Wonderful. I appreciate that. So I'm Dadisi Sangukinn.

I'm the governing board chair of the Continuous Delivery Foundation. And so one of the projects that we have right now that's actually kind of pre-incubation that we're moving over is a product called Conduit, and it is like an IDPC. It's a platform engineer's engineering platform is really what we're trying to develop.

And the whole goal of it is how do you match the process of what you do in each tool to our actual natural language, right? And by matching it to natural language, it works better with AI. And so we're trying to map that to both of those principles in a way that's completely tool-agnostic.

So I think a lot of people have built an IDP, and they're having a hard time living with it because you have to constantly upgrade this thing every time there's a new integration. So how is what you guys are going to do make everybody's life simpler? Well, it's based on CD events, which is the open-source specification that's in the CDF that describes how SDLC and build events should actually look.

And if each tool is producing the events, if you have a build started event or a build finish event, and it looks the same from every tool, now all you're doing is building against that event system. So as they come out of the system, then you just move forward through the IDP. " But because the event looks the same, you can actually just have the same code work over and over and over.

So it minimizes not only the integration work, but if you switch tools or want to try tools, it just works. How widely adopted is CD events itself within the DevOps workflow? Is that something where- I don't have the numbers for the downloads itself.

Yeah. But it is getting adopted by more and more companies each day. Mostly we see it in the financial industry, where you're heavily regulated, and you want to do something where you need the attestation or the verifiability.

Where those things matter, teams will reach for CD events. And since we have so many of those types of teams with complex systems, you want to simplify that. But then everybody gets that benefit, right?

And so we can sit in the space between where you can have verification and work, and by sitting there and just watching the systems, taking those events, and letting you take action, then you're working in a safe space with receipts, and you just move forward. So are you providing the actual IDP to folks, or do you want folks more or less just to adopt CD events within their existing workflows, or a little bit of both? Well, what we're providing is a platform engineer's platform, and we're providing a space to do the language.

It's not going to be prescribed. One of the things that we are really, really cognizant of is this has to work for everybody. It can't just work for one company.

It can't just work for one ideal. It has to be able to go in and help customers that want to pick it up and build to it themselves, but also support the things that our vendors want to be able to do with their systems. And so we're giving them all the primitives.

Think Lego, like master builders. " Right. But it's up to you to decide what you do.

So it's a lot like Kubernetes in the sense that it's a platform for building platforms. Ah, it's Linux, right? It's the Linux Foundation.

There you go. What's your sense at how much people are kind of moving down the path towards platform engineering? Because it seems to me IDPs are kind of at the core of that shift.

Yes. And when I look at it, it's kind of like, all right, we're going to try to manage DevOps at scale more efficiently, and maybe we won't have 14 teams using 16 different CI/CD platforms. But what's the level of maturity that you're seeing out there with this adoption, and what's going on?

I think we're solving a common problem where it is just as you said it in the beginning, right? It is tough to keep up with the changes and with AI being introduced and trying to find the best paradigm and the best practice. We took it upon us in the CDF to kind of figure out what it was.

" We applied that to common DevOps principles that already exist, the one that Alan and I used to talk about on the CD Pipeline show, right? And so if you take that same information, those same people who are passionate about this space, something's going to come out of it. CD events was already there before I showed up, and then we were just trying to figure out how do we make this interoperable?

And so what we came up with was Sedaris expressions, which are the combinations of CD events that get something done. And because it's never just one event, it's going to be a series of events. And so if you define what those series do very clearly and very publicly, then each team can be slightly different in their approach to this problem, but still do a build.

If you think about that word build, what does it really mean, right? It's hard to tell because every team does it different. Right.

And how do we give them that flexibility is what we were trying to figure out, and not only give them that flexibility, but give them complete ownership of what they do. Right. I think a lot of DevOps managers kind of feel like the air traffic control guy, where it was hard enough doing that job.

Mm-hmm. And now a bunch of AI agents are adding more planes into the sky, and they all want to land on my runways that aren't getting any bigger. Mm-hmm.

So people are trying to figure out, so what do I got to do to change the DevOps workflows or the pipelines to accommodate all this code that wants to land on these pipelines and-Do I need to just fix my workflows, or do I need new platforms and tools ultimately to accommodate all this stuff? Well, the short of it is what you need is a better language, right? We need to be able to turn the DevOps language and the DevOps practices of things like I just said, build has so many different definitions to make it really, really definitive for your AI.

" And I know that build started in Jenkins. I know that build started in TechTalk. Here's the things that came out of that.

Here's this places where something was done, and I want you to do this work right here. I want you to be super focused and do this work right here, and here's the information that you need to do it. So if you can templatize that, now when you're building your skill, it just works, right?

It's not guessing. It's not trying to figure out your system. It says, "Hey, here's the body of work.

Here's the information you need to do the work. " Will AI agents kind of force that conversation? " And eventually, it will expose to me the fact that I have seven different definitions for builds.

And since the way that our system works, each one of those builds, we can define the steps. And for build number two, it has a completely different set of steps than build number three. And so you can say in build two, at this step, do this thing.

And that's the big difference, right? " Let's say you're a compliance officer, okay? And all you want to know is for production builds from one group, I want to know, did they get their artifact signed?

You can ask that question directly in the system because the system understands that their build will have that artifact sign in it, and you'll be able to match it to that work. Will that ultimately make the building and the management of the DevOps platforms in the age of AI less expensive because I won't be shoving so much stuff into the context window? Yeah.

And I'll have that baked into the system, right? Yeah. And it's open source.

That's exactly it. It's about control at the open source level, right? It's about being able to control the system where you do the work in a way that makes it accessible to AI.

You've got to think about the problem and approach it by how AI works, not how I would like it to work. And so if it works in a natural language way, we need to take our natural language, where we have definitions and words that mean lots of things, and explain that simply to AI so it knows exactly what we mean. And so if it's a dev build, you're not going to need the same things.

But it still used the word build, and we have to let it know, and we do. We know that it's a dev build. We put it in our REAMLs when we're setting up the dev, right?

We know that this build doesn't have the same importance as our production builds. And since we're putting that information right in the AMLs that we use to do it, it's the same thing. " And at each step we take, we're going to emit a CD event because that's already described.

The industry has already figured out, hey, this is what these steps should have. And all we need beyond that is the ability to say, this is the thing that I want to do that's specific to my company. And then we have custom data for you to carry that through.

I mean, everything's there. We just have to line it up with a system that shows that the pub/sub portion of that in an enclosed space can be safe. So we're kind of on the eve of this great AI revolution in DevOps, and that's awesome.

" I'm going to say something that's going to make me really unpopular. But I've got to say it because it's the truth. If your DevOps principles have to do with distributed pub/sub, you're already looking at the problem the wrong way.

You're creating too many surfaces. One of the things about the execution plane that we're building, it lets you bring everything to a central place, kind of like a FedEx, right? This is how FedEx worked, the revolution that FedEx created.

You bring that data straight from the tool to the execution plane. Now you only have one hop to verify against. Once that hop's verified against with a receipt, now you can do work in a safe space.

But as soon as you go, "Hey, I'm going to subscribe to it for this group, I'm going to subscribe to it for this group, I'm going to subscribe to it for that group," compliance officers have to run around and chase everybody and figure out, hey, are you implementing this right? Is this really what's going on? " That's what we're giving going forward.

You know, it's not just the compliance people, because it occurs to me that project management people have the same problem. Exactly. Everyone has it.

That's just an example. But every watcher of any software project, every stakeholder wants to get information about that project in their own way. And if you can say definitively the information you're looking for is at this step in the build, here's the receipt for the work being done.

What would you like to do with that information? Now they're effective. Right.

And the alternative is these people become really annoying, and everybody hates them because they're basically calling you up looking for information that you know is in the system already, and you're like, "Well, why are you asking me this? " Right. Or you're building integrations for it, right?

Right. And so that's the glue code that we're building over and over again. And what we want to do is keep you focused on building the features that you need in your system and building those features in a way that you expose them, but everyone can use them, right?

And so it's leverageable, it's repeatable, it's accessible. All right. Well, nice job on this, but what are you doing next?

Come on. What am I doing next? Well, we've got to get this out.

This is going to land, and if it works well, it's adopted well. My company is really going to focus on interoperability and orchestration beyond DevOps, right? Because this is a common problem.

We're just starting here, but we want to solve this problem for the folks that we love the most, right? Because this is where we discovered the solution. This is where we got a deeper understanding of the problem.

But we want to prepare everybody for language-based orchestration. Don't think about semantic interoperability. Think about semantic orchestration and making that work.

All right. Folks, you heard it here. Hey, maybe the problem with DevOps isn't necessarily going to be the AI agents.

It's maybe actually going to be the wetware between the brains of the people using the AI agents. Hey, thanks for coming by. All right.

Thank you. All right. And we'll be back in a minute.