Microsoft’s Doug Davis on CloudEvents’ CNCF Graduation

This is Textron tv. Hi everyone. Welcome back here to Textron tv.

Really happy to have joining us today, Doug Davis. Doug is a principal technical PM architect with Microsoft, but he's here today wearing sort of another hat or maybe two hats, uh, in regard to A-C-N-C-F project that he's closely associated with. He's gonna tell us all about it.

Hey, Doug, welcome to Tech Drunk tv. It's nice to have you on. Thank you for having me on.

Appreciate it. My pleasure. So, Doug, before we jump into the CNCF and, and everything, let's talk a little bit about Doug.

As I mentioned, you're a principal technical, uh, project manager architect with Microsoft, but, um, a program manager. Why, why don't you kind of give us the deal there that would the scoop on Doug? Yeah, so, um, actually I'm relatively new to Microsoft.

I've been there a little under two years now. Before that, I was at the IBM for a long time, shall we say. Um, okay.

And in both spots though, I've been very heavily involved in the cloud native space, you know, ever since Docker really took off and the containerization of things really took off. That's where, that's been my main focus, and that's why I got involved in CNCF. 'cause as, you know, CNCF is around cloud native, which is containers and all things Kubernetes and containers and stuff.

So that's where I've been spending most of my time for what now? Seven, eight years, however long it's been out there. So that's been my main focus.

Anything related to containerization type space is where I've been sort of living for a little while now. I got it. Got it.

Um, and you know, I, well let, let's jump right into it. We're here to talk today about cloud events, which is A-C-N-C-F project, and we're gonna go dive into that in a moment. But what's, what's the connection to cloud events?

Yeah, so, um, a long time ago, the CNCF decided they really wanted to figure out what to do about serverless. It was a new and upcoming technology. They didn't know what to make of it.

And so a serverless working group that started up just to sort of evaluate serverless, what is it, what should the CNCF do with it? And stuff like that. And we produced a white paper that sort of explained the serverless ecosystem and what it's all about and why people may or may not care about it.

Um, as part of that work though, the CNCF wanted to sort of see if there's something we could do to help out the community relative to serverless. And so the serverless working group looked around and said, well, what can we do to find sort of, sort of low hanging fruit to make life easier for people in the serverless community? And we realized that serverless in many cases is about not just setting up functions, but functions for processing events, right?

Take the, the classic function platform lambda, right? It's very much focused on, you get a set of events coming in, you process it really quickly, then you take down the event, the function, right? And so we started looking at this, this eventing space and say, well, is there something in the eventing space that, that's sort of a pain point for users?

And we've realized that there are tons of events flowing around in the environment or in the ecosystem, but there's very little to help people out in terms of processing or routing of those events to the proper location. And that may not sound like a very big flashy, exciting problem space, but it's actually a very sort of nagging problem for people, right? So let me give you an, an analogy here.

'cause it's one that I like and it, 'cause I think it's very, um, appropriate for cloud events. If you think about an HTP server or how you routed h HP message from one location to another, there are these things along the way, pieces of middleware, HCP servers, and ultimately it reaches an application. Well, every piece of middleware doesn't really know what it's doing, right?

It looks at things like the HCP header, it looks at the path, it looks at the content type, different bits of, of metadata at, at an HP header level. So route to the proper location, right? But they don't really understand what it's doing it.

But what a GP did in its most basic form is said, look, we're gonna define a hetero section common attributes so that these mid pieces of middleware can get it to the right location. And then the application that receives it can say, okay, now I'm gonna crack open the body and figure out what to do with this thing. Right?

Well, that's what cloud events is kind of trying to do. It says, look, we, we, we wanna take this event to the, we wanna get an event to the proper destination. How do we help the routing mechanism get there?

Because without cloud events, most middleware have to crack open the message. They have to understand the schema of the message, they can parse it properly. They have to figure out which properties in there, tell it, what is this message about?

How do I know how to route it properly? And that's a lot of work. It's not rocket science, but what it means is every piece of middleware has to now have sort of intimate knowledge of the event itself, right?

You can't just look at some generic thing, do do some like regular expression or string matching thing to route it to the right location. You have to understand the actual event itself. Well, cloud events took a step back and said, well, can we do anything here to help this?

Right? And so what we did is we defined a common bits of metadata, in other words, properties, um, like, um, the type of the message, um, uh, the source where it came from, its id a small set of attributes and said, look, every event has to have these three or four attributes. And that, that alone allows middleware to route it properly to the right location.

Because with those attributes, you could say, I know what the message is about. I know who it came from. And if when you set up your middleware, you could say, oh, if this event type comes in, send to that application over there.

If this event type comes in, send it to this one over here. Right? The middleware no longer needs to understand the content or business logic of the event itself.

So it makes life easier for people setting up these middleware, uh, routing systems basically. And that's really all it is. It's actually a really, really simple spec.

It just defines some common bit of metadata where it appears on existing messages. So where it appears on HP message, where it appears on an A MQP message, right? Which is, you know, the same location, all of 'em, they all typically have this notion of headers or extra metadata, right?

So it goes in there and that way your middleware, if it detects that it's there, can now be really smart and routed appropriately. But at the same time, if your middleware doesn't understand cloud events, because this is extra metadata that's already on the existing events that are flowing, it can still do whatever processing it does today if it, you know, understands the body in other, in other words, right? But a, to become a cloud aware event or cloud aware piece of middleware, it just says, Hey, if this extra property is there, the cloud event property, I know what to do with it.

I can do this routing in a much smarter way. I know what have to parse the message, don't need the scheme of the message. All this stuff.

I, I apologize, I rambled there, but it's really not that complicated of a spec. It's actually a really simple spec and scratches one very particular itch. How do we get an event from source destination as quickly and easily as possible when setting up that middleware?

That's really all it is. But you know what, I, let's not minimize it either. It's a pretty important func piece of functionality.

Getting it. It is. And, and we just add in the, I I've been actually very surprised when I go to talk to customers about my day job, right?

And we, you know, you're doing the introduction, say, Hey, I, I do this and that and stuff. When I mention I work on cloud events, I can't tell you how many times people had stopped the conversation and said, thank you, thank you guys for inventing that. It's, they, they were getting their job done before, but cloud events makes setting up that middleware so much easier for them, right?

That commonality of knowing what is this event about is always in one location, the exact same spot. And I just need like a simple regular expression parsing to say, oh, it ends in, you know, poor request create or something like that. I can route it over there.

And they, and they say it's a nice little itch that we've scratched, basically. I get it. You know, I mean, and look, I, I've been in tech for a long time, right?

I'm going venture longer than you, Doug. And Maybe it's a little, A little of, and and traditionally this was the kind of bread and butter of, of open source software. It may not have been a, a soup, you know, usually open source projects are not soup to nuts applications.

They were the glue, the pieces that tie together this functionality and, and stuff, right? And this, so cloud events is kind of, in my mind, that's your typical kind of open source thing, right? That it kind of, it, it, it's in the innards, right?

It's in the guts of things, but it's an important piece that allows everything else to, to flow. And, and, and you know, what a great, what a great piece of functionality that was obviously needed, right? It was critical.

And by having it as open source, you, you're not, you know, you're not at the, the, the, the mercy of a single vendor or single kind of entity who decides, oh, I'm going to apply the choke point here, or, or something like that. Um, or it's gonna work on this and not on that and on this platform, and we're gonna favor that platform. No.

Yeah. Yeah. And, and I, I'd like to jump in.

There's a little, because I, I wanna, I need to give huge, huge kudos to the entire cloud events team because, um, I've been doing standards work, uh, for quite a few decades for a very long time. And most of the time, even the one, even the groups that have been fairly successful, their politics involved, right? Because companies come in and they have their own agenda.

They need to get something standardized. Um, and, and they have to, a lot of times they wanna standardize their stuff because they don't wanna change their code, right? This cloud events team has been, in my opinion, the best group I've ever worked with because while there may have been one or two times where it felt like somebody was trying to sort of push an agenda overall, the group itself, to be blunt, squashed it and basically said, no, we are not gonna allow politics to be played.

We set up the governance model in such a way that one company cannot dominate Mm-Hmm. And everybody that, that stuck around that wasn't there for clearly to get their thing done, but actually cared about the project itself as a whole, from a community perspective, everybody that stuck around has been so welcoming, so friendly, and so open to making sure we're doing the right thing for the community as opposed to just what their organization or company needs. And as a result, if you actually look at sort of the, the life cycle of our group, we have it set up square where people go off and they, they work on a change request or something like that, right?

And they come back with a proposal, but ultimately if they can't agree on something, it comes down to, okay, fine, we're gonna have to take a formal vote and the group is just gonna decide A or B, right? The number of times that we have that we've actually taken a formal vote over something that's, that's really controversial within the group as opposed to something mindless like, oh, let's vote on what our icon looks like. Right?

Something actually real, right? It's, I i, I, I believe it's like an order of three or four times over the entire multi-year life cycle of the entire project. That's how well the group gets along.

And usually those times that it's happened, it's not because you get the sense that that people, um, are pushing an agenda as opposed to they just have very strong opinions because obviously there's a personality preference kind of thing. Some, and sometimes that pops up, but it's never been about politics. It's not been people come to me in the background and say, oh my gosh, that company's pushing agenda.

How do we stop this kind of thing? Or something like that. It's always been purely hey preference kind of thing.

But as I said, it's only come down to three or four times, which means over the, what, five years, six year period, I'm not sure how long they've been around. People have really worked hard to find consensus because they understand if the project isn't broadly adoptable by everybody and everybody looks at it and says, yes, this wasn't promoted by one company. It's, it's, it's, uh, clear this was designed for the community.

If it's not that way, they're not gonna implement it because we're not necessarily producing code here. We're producing a spec at its core. And that means people have to like the spec because they're gonna be writing their own code for it in many cases.

And so we have to do it right. And everybody's on the same page with that. And I, that's why I had to give immense kudos to the entire team itself for keeping politics outta the organization and being an incredibly welcoming group for everybody that comes and goes over the many years that we've been around.

And I just wanna get that out there. 'cause without it, without the team being the way it is, we would not have been as successful as we are. Excellent.

And you know what, that's well deserved, and I'm glad you brought that up, Doug. So Doug, you know, not everyone out here is familiar with kind of the life cycle, if you will, of open source projects at CNCF cloud events is now a graduated project or will be a graduated project, if you wouldn't mind, explain what that means. Yeah, so let's first back up a little and talk about sort of the, the three steps of projects inside the CNCF.

Um, yeah, I believe that the base one is sandbox, then incubator, and then graduated sandbox is basically what it sounds like, right? A new project has come along, they're just getting started. It's, it's a sort of a, a, a proof of concept.

Not, well, not necessarily from a coding perspective. 'cause you can have a fairly mature project based sandbox, but more of it hasn't necessarily proven itself to the broader community to be a value for the ecosystem at, at, at large, right? Even though the project itself could be really relatively mature, it maybe doesn't have the breadth of, of, of, uh, familiar familiarity with the entire ecosystem.

So it starts out at a sandbox, then it moves to incubator, which is sort of this middle ground that says, okay, yeah, you have some value. Uh, people are starting to use you, you're getting more mature in the community. People recognize you're out there and now it's time for you to sort of become a little more mature from a process and organizational perspective, right?

Sort governance model kind of thing. Make sure you're a good open source project. You have all the right rules, that code of conduct, governance model, all those other kind of things in place.

And, and you can then, uh, expand your scope in terms of who knows about you in the community and who's using you. And you get to be more well known basically. And then eventually when sort of everything comes together from a, uh, maturity perspective, from a code or spec perspective, the community has recognized you as, yes, we value you being there.

Um, we would be lost without you kind of stuff. That kind of thing. That's when people say, okay, it's time for you to take the final step and says, yes, you've hit the, you've hit the peak, and that's the graduated status, and that's what we got approved for, what, last Thursday, the 25th or something like that?

Yeah. Yep. And, and, and I should mention, you know, from what little I know about this stuff is there's actually metrics attached to each of these stages, right?

To move from one stage to the next. It's not like the, the committee takes a vote and says, yeah, it kind of feels like that, right? There's, there's actual, you gotta have a certain amount of downloads, a certain amount of people contributing, a certain amount of, of maintainers, a certain amount of, you know, verified uses in the markets.

It's stuff, you know, those are the kinds of things that the, the committee looks at in order to, you know, move the, move any project from one stage to the next. Yeah, that definitely is part of it. Yeah.

Mm-Hmm. And I, I don't remember all the specifics of it, but, but you're right. It, it, it, it, it also varies from project to project, right?

Because for example, uh, cloud events is at its core a spec. So you can't really measure and say, downloads of a spec per se. If you have code, they can say, okay, how often are people downloading the, the SDKs or the, or the code itself, and how often is it being used?

That's a little bit easier to measure. Um, so different projects will have a, they'll focus on different metrics, but you are correct, there are metrics there. And one of the really big ones, um, I think for all projects is community adoption, right?

Yep. How many people are using you, you know, if you're only used by, you know, one-off developers, that may be interesting, but that may not necessarily get you to graduate status. Now if you're being used by, you know, the big enterprises, that's gonna get more notice, right?

So it, it does vary from type of project. Um, but those are the kind of metrics that you mentioned that they do look for, right? Yeah.

Yeah. Well, the important thing to me there is, you know, it's objective, not subjective or predominantly objective anyway. Yeah.

Doug, we're, we're over time, but I, I, you know what, we didn't mention people who maybe aren't familiar with cloud events and, and want to go get some information or dive in a bit. Where can they go? What's the best, uh, place to go for that?

io. That's the home for it itself appointed to the gator repo, the specifications and all things related to cloud events. io is the place.

Excellent. And we should also mention, you know, we're just, oh, a month and a half, almost two months out from, uh, CubeCon Paris, CubeCon Europe, which is in Paris this year. And, um, of course all things the NCF take place there, uh, will cloud event, and there's, I think there's a zero day on Tuesday of that week.

I think it's, I want to say Tuesday's, maybe March 18th, um, something like that, 18th or 19th, whatever that Tuesday is. Um, is cloud events having, uh, sort of a pre-con kind of gathering there, or do you know? I, I, yeah.

At this point in time, I don't think we necess have a, a pre-event type gathering thing. We will definitely be there. It, I'm not sure who from the organization, uh, will be able to go, but we would definitely will have, you know, the regular maintainer session, uh, booth so people can ask questions and there would be some representation there.

I'm not sure the specific details yet. Um, I'm not sure who on the various co from the various companies has gotten approval of to travel yet. That's why it's a little bit up in the air.

Sure. But we definitely have some presence there. And in particular, we definitely will have a booth for people to ask questions as well as the maintainer session.

So yeah. Fantastic. We will, Textron will be of course, broadcasting live as we usually do at CubeCon.

And I, just a heads up, we're working with the Linux Foundation right now about setting up a bunch of, uh, slots to interview the maintainers and, you know, all of the, some of the key, not all of, 'cause there's a lot of CNCF projects now, but some of the key CNCF projects that will be spotlighting over in Paris, so hopefully cloud events will be there being newly graduated. Yeah. Um, Doug, thank you so much for coming on and, and telling us about cloud events and, and kind of making us a little smarter here today.

Keep up the great work, you know, if no one tells you thank you right. For what you do, because yes, you work at Microsoft, yes. You get your paycheck there, but yes, you put an awful lot of time.

Anyone who gets involved in these projects knows, right? A a lot of times they're labors of love and they're not necessarily monetarily driven. And so thank you for your time and effort and, and making cloud events successful.

Well, thank you for that, Alan, and I appreciate it. And thank you again for having me on. I gimme an opportunity to talk about cloud events.

It's been fun. Cool. Doug Davis, principal technical PM architect at Microsoft, but also one of the main guys over at the CNCF Cloud Events Project, which is recently graduated.

You can find out more, especially if you're gonna be a CubeCon Paris. We're gonna take a break here on Text Drunk tv. We'll be back in a little bit.