Event Driven – Cloud Native Now Podcast EP16

Hello, and welcome to the latest edition of the Cloud Native Now podcast. I'm your host, Mike Gazar. Today we're with Steven Foskett, who is president of the Tech Field Day business unit of the FU group.

And we're gonna be talking about all things cloud native. As usual. Steven, welcome to show.

Hey, It's great to be here. Uh, long time listener. First time caller, I guess.

There you go. Well, actually, folks, Steven is peers on the Textron Gang video series. We invite you to check that out on Textron tv.

He's a regular, and this conversation that I'm gonna have with you today is kind of an extension of a conversation we were having over there earlier this week. It seems to me the more I think about all this software architecture stuff, and there's microservices and monoliths and serverless computing frameworks, it seems like it's all coming back to something that is event driven. And I remember when we had event driven architectures 25, 30 years ago, the problem was it was just hard.

And nobody really wanted to build those kinds of applications. Required a lot of specialty. As you kind of think about where we are, and you look at all this digital transformation stuff, are we moving towards some sort of general shift to realtime event-driven applications?

And maybe not everything is gonna be some batch oriented thing that we built 20 years ago. The search seems that way, doesn't it? Um, we are seeing so many, uh, of these, uh, uh, webscale, uh, modern applications platforms adopting, I think, in my opinion, what they learned from e-commerce, because of course, e-commerce is where so much of, uh, cloud native development came from.

Uh, you know, basically building out massive scalable platforms, uh, for purchasing, uh, you know, let's say buying books online. And, um, beyond that, I think as well, uh, you look at social media, again, it's, um, not really event driven, but it is somewhat driven in that way. Um, and, and so it makes a lot of sense.

And then the other thing that I'm seeing as well is, uh, when we look at the edge, we look at IOT, uh, there again, event driven is everywhere. Um, you know, if you've, if you've ever used home assistant, if you've ever used, uh, you know, any of these, uh, you know, uh, MQTT driven systems like that, I mean, they're all basically built around this same kind of concept. So it makes a lot of sense to me that developers would be heading in that direction because, um, it seems like a good paradigm for a lot of the applications that they're developing.

And, uh, as we see, there's a lot of, um, momentum that gets behind application development as soon as, uh, as soon as the industry heads in one direction, it seems like the rest of the industry follows. Are people not using the term event driven? Is it too passe and too old and therefore not cool enough?

Because, um, when I look at it, I'm kinda like, Hey, this is awesome. We finally figured out how to do event driven. But if I go talk to the average developer, I don't really hear them use that terminology.

Well, it's funny. Um, you, you're right. Um, I do hear the EDA term quite a lot from developers though.

Um, I, I don't think that they really think of this as a, a concept so much as just sort of how things are done in some cases. You know, I think they're, they're looking at it and they're thinking, you know, uh, this thing happens. I've got, you know, again, back to the whole, the origin of the, of, of, well, modern application development.

I've got a pub sub kind of setup, and so I'm going to subscribe and as events come in, I'm going to take an action. I don't know that they think of it as a unique concept necessarily. They might just think of it as just the way things work.

Is it generational? And I ask this question because kids growing up, they were playing games and a lot of things happened offscreen. And if I think about what makes event driven challenging is there's so many things that need to happen as part of an asynchronous workflow that you have to keep in your mind while you're focusing on some other part of the application.

And it just requires, um, a higher level of cognition of what's going on across the things. So, um, I did we have a generation of developers that were so focused on bash that they really didn't wrap their heads around and event driven? Or can the old dogs learn new tricks?

Well, I dunno about the old dogs learning new tricks, but think about the new dogs learning old tricks. I think one of the things that some of us have seen in this space over the years is, um, you know, hi history, uh, does tend to rhyme, doesn't it? And many of the lessons that were learned early on, uh, in event driven applications, on mainframes, you know, and that sort of thing, many of those applications, uh, or, or lessons weren't brought forward necessarily.

And I think that's one reason we see these kind of generational shifts in these paradigm shifts in software development, whether it's agile or, uh, you know, EDA, it, it's maybe the lessons weren't learned, and maybe that's the problem, right? And, and, and maybe people are thinking about, well, this is just how it should work. But they're not thinking about challenges like maintaining consistency across distributed components as, uh, changes come in and as things are constantly in motion, as opposed to the batch process system where basically you start at the beginning, you go to the end, everything is consistent.

Uh, I think also they're taking for granted a lot of the things that were very, very challenging in the past. I mean, if you had, uh, systems back then, I mean, we didn't have the same kind of storage performance that we have now. We certainly didn't have the same kind of networking performance we had now.

Uh, latency was a massive problem when it came to building event driven architectures back in the day. Today. I think people kind of take things like that for granted.

Basically, storage is instantaneous, capacity is free, network bandwidth is unlimited. And so we can just build things without worrying about managing resources. I think the mobile guys may have restarted this whole conversation because they were building these types of apps.

I I look at Uber as kind of a classic event driven application, and all they really did, at least to get started, was just cash the crap outta everything using something like Redis and off they went. And so I think maybe they're not even aware that it's event driven. It's mobile application developers.

If you tell 'em, they'd be like, wow, that's pretty awesome. But I didn't think about that. I just kind of tried to accomplish a task.

Yeah, absolutely. And, um, you know, this, I think all this is not to say that event driven is a bad choice. In fact, quite to the contrary, I think this is exactly how a lot of applications want to be built.

It's just we were facing so many challenges building them that way in the past. But I mean, uh, now the, the, I think the magic, uh, get outta jail free card here is the, um, incredible proliferation of open source. Um, if you look at all the work that's been done by hyperscalers on, uh, social media and e-commerce platforms, if you look at basically everything with an Apache license on it, they're all built around these kind of modern, um, distributed auto scaling applications that are very much, um, you know, microservices based.

Uh, all those things make a lot of the challenges of a event driven architecture a lot easier to tackle than kind of trying to build something yourself. So the availability of Kafka, the availability of function as a service, the availability of especially observability and monitoring tools, lets us deploy things and lets us do things that we never could have done. So frankly, maybe it's a good idea that this generation isn't listening to those old gray beards who say it can't be done.

All right, folks, you heard it here. Event driven might be the new default. Moving on to another topic.

SUSE had its big conference recently and they bought Stack State to add some observability capabilities to their rancher management platform for Kubernetes. I wonder if cloud native at the end of the day, is it the killer app for observability? I think we've been kicking this idea around for a while, but I think it's only when you get into cloud native and microservices that you wake up one morning, you go, Hey, you know, that old monitoring horse just isn't gonna carry me forward from here, and then I gotta do something about it.

Totally. And, uh, I'm really excited about this. I'm a big Rancher fan.

Uh, I myself use Rancher in my, uh, well, uh, I guess you can't call it a data center in in my own, uh, microservices application space. Um, and one of the challenges, of course, when you're building these things out is the understanding of what it, what, what is going on. Because, um, once you kind of step back from micromanaging everything and being hands on with everything, you kind of have to let the system run.

But the problem with letting the system run is you're like, whoa, what is happening here? I don't even know what's happening. Observability, I think, is the, to me, is the way to solve that.

Now, I had seen Stack Stack State Stack State before, and I was impressed by what they were doing and have that be brought into the Rancher platform, especially on the enterprise space. Those rancher prime customers who are maybe have a, a more diverse and dynamic infrastructure, certainly more than what I have. I think this is a really great move and I'm really excited to see where they go with this.

Really impressed by what they're doing with Rancher. One thing I didn't really see them talk about fully as it relates to Stack State is ai. And I bring this question up 'cause this, I talked to a lot of folks about observability.

One of the things that keeps coming back is like, wow, that's really awesome, but I don't know what questions to ask in the first place. So I really can't get the value out of all this stuff. So are we moving to a point now where the next phase of observability is that the algorithms are gonna ask the questions for us and we will tell us maybe our surface that which they think we ought to know before something truly bad happens?

Well, I guess that's kind of what they're trying to do with this rancher prime AI assistant thing that they've announced as well. Um, uh, again, uh, we're seeing so much AI everywhere. We like to laugh that, uh, we do an AI Field Day event.

Well, we like to laugh at every field day event is AI field day now, because everyone is using ai. Um, we recently had a cloud field day before that. We had app dev, field day, networking field day.

All these industries are bringing these AI assistance to bear. And they're coming in different ways. Certainly some of them are, um, semi-autonomous agents that are trying to manage your system for you, as we might talk about here in a couple minutes.

Others are, um, in my opinion, a user interface that helps the, uh, the, the lay person or the casual user to do more advanced things. I'm hearing really great, um, reports from users of the ladder especially. Essentially, somebody sits down and says, whoa, okay, observability, I've got all these metrics.

I've got all this stuff going on. How do I even approach this? And instead of, um, I guess, you know, reading a blog or a manual or something or watching a video, uh, they'll basically just hit the assistant and say, look, I really need to know if, um, storage latency is affecting the ability of the application to scale.

And the thing asks the right question, it translates that into the right system commands. That would be very, very neat. The other thing, of course, like I said, is these AI assistance that just sort of autonomously run.

We're seeing these appear all over the place as well. Um, I wonder, uh, I I I suspect that's a very different kind of ai. Um, but yet it also can have a lot of benefits because you don't even need to sit down at that console and ask it to do something.

You're right. And let's just shift to that next topic that you're talking about. 'cause they feed into each other, at least in my mind.

So Microsoft seems to be trying to drive a quiet revolution here in Cloud Native and Kubernetes. And basically they talking about automating the crap outta everything and providing a higher level of abstraction for Kubernetes, arguably long overdue. And the idea here is that I can be a mere mortal now and manage Kubernetes.

I can just be your average IT administrator. I don't have to always be a DevOps engineer who's, uh, a high priest of all the different scripts and workflows required. Are we on the cusp of filing, democratizing all this stuff?

I sure hope so. Um, um, we talked, uh, on the Textron Gang about the fact that, uh, Kubernetes really is becoming the standard deployment framework for so much of, uh, enterprise IT in addition to cloud native. it, and I will point out as well, one thing I didn't mention there, uh, it's also becoming the deployment packaging standard at the edge.

So we're getting to the point where Kubernetes really is everywhere, but to be honest with you, I'm just gonna come out and say it, Kubernetes is way too complicated and way too esoteric for most people. I think a lot of people try to get into Kubernetes and they kind of hit that wall after reading a few things or watching a few videos and the, and the con you know, the conversation starts getting complicated and they, and, and, and it starts getting beyond what they're, what they're ready for. That's why it's very exciting to see companies trying to make Kubernetes easier.

I mean, certainly we're seeing that from the hyperscalers. Um, Google presented a very similar, uh, thing at our cloud Field Day event last week, and now we've got Microsoft doing this with a Azure Kubernetes service. Um, when it comes to networking, especially they, they're basically making it, um, able to do the observability stuff without you even touching it.

Uh, as I said in the last little bit there, uh, it's one thing to be able to sit down at the console and talk to the machine and have the machine, uh, do what you want without you really knowing how to phrase that. It's quite another thing to just sort of step away and say, well, you know what, let's put this thing on. I'll say it autopilot and let it run.

Let it drive on its own. Um, you know, and, and Microsoft's automatic service, um, is a really, um, well, let's say a cutting edge example of that. I'm a little scared of this thing, um, because basically it's a drive-in for you.

Is Kubernetes the right answer or do we need something that feels like maybe Kubernetes light that we can use and is a little more accessible and has more abstraction layers around it? Or is, are we so far down the path now of Kubernetes that the only alternative is to, uh, keep driving abstraction layers on top of this thing to the point where it just, you know, finally behaves the way we want it to? Well, I, for one, miss the day of the Docker.

I love to docker. I love Docker Swarm. Um, you know, what you're describing sounds a lot like rancher to me as well.

Um, frankly, uh, I found rancher very, very approachable as a a, I don't wanna say old school, but, uh, I guess I'm old school compared to some, um, you know, person who had been experienced with, uh, vSphere in the past, sitting down at the rancher console, felt very comfortable and very familiar in a way that my first experience with Kubernetes didn't. I think you're right. I think that we do need to continually drive this thing forward and try to make it more approachable, more simple, you know, uh, more understandable, comprehensible for people.

But that being said, I really don't see us moving away from Kubernetes, at least not for the time being because it's so big and just so works that why would we not use, uh, Kubernetes under the hood, even if we're doing something different like rancher on top of it? Well, they think Kubernetes is a platform for building platforms. It seems like there's a lot of work to be done yet on the building of the platforms on top of Kubernetes.

So cross your fingers. I think things will get better sooner, but we'll see where we go. Our last topic is security and Red Hat was talking about it in a report that they put together.

And I'm trying to figure out in my mind if container applications are more secure than legacy monolithic applications. And I can argue that side of it because it's easy to rip and replace containers that have vulnerabilities, but there's a lot, a lot of containers and a lot of moving parts. So you can argue that it's more challenging to secure that environment.

I don't know which side of that coin you wanna fall on or both, but what is your take of the current state of cloud native security? Are we more secure or less secure or just differently insecure? I dunno, people may throw stones at me for at saying this, but I think we're more secure.

And this is, uh, I know there's controversy, and again, we talked about this on Textron Gang. Um, yes, there can be all sorts of problems with open source packages. And yes, like that famous XKCD comic, all of modern infrastructure rests on a tiny little component that's maintained by one guy in his spare time.

And that's where we get vulnerabilities that can affect the entire stack. But that being said, um, you know, I came into it in the age of open source. You know, my, uh, undergrad was in the early nineties, and we were all, uh, listening to the, the luminaries of open source who were saying, you know what, having the ability to look at the code, having the ability to modify the code and contribute changes upstream fixes things that would never be fixed in traditional monolithic it.

And frankly, that's what I've seen my entire career. I don't wanna sound too much like an open source fanboy because I recognize the limitations of this, but that being said, I personally feel much more comfortable using, uh, widespread, uh, widely understood, widely maintained open source software as the foundation for applications than using monolithic or proprietary things that could be, uh, misunderstood. They could have programming errors.

I mean, we all know that the programmers make mistakes. There could be errors in them, bugs, uh, but, but, and not have the ability to look into that stuff. I think that the main difference between security in the open source world and security in the closed source monolithic traditional application world is that security in the open source world is exposed to the internet and is exposed to so many people going through this stuff on a daily basis.

Whereas the other stuff just doesn't have eyes on it. There are the same, um, or I, I don't want to say that it's necessarily the same, but there are probably lots of bugs on both sides. But on the open source side, I just feel more confident that it's gonna get fixed.

Hopefully there are safety in numbers, right? Because if we're all participating and this, and this is, Linus has been saying this thing about Lennox forever, there's just sometimes with the open source packages, there aren't enough eyeballs participating, and that's where we get into trouble. The one disheartening thing in all of this was that it didn't feel to me that we were making any more progress with application security in the cloud native error because the reports, you know, highlighted that there's just the disconnect still between the security people and the developers.

And I get why security people tend to create these lists of vulnerabilities and throw them over a wall at a bunch of developers who then waste their time tracking them down to find out either A, they're not internet facing, or B, they're not actually in the application in the first place, and they stop listening 'cause they have other things they wanna do and they can only devote five to 10% of their time, the patching legacy apps. Anyway. How does this all get better someday?

Well, that's gonna be a tough one to face because you're absolutely right. I think if you talk to security professionals, uh, they would all be very frustrated by the responsiveness that they get from developers when it comes to the vulnerabilities that they discover. Because frankly, uh, a lot of these security folks are out there and they're discovering vulnerabilities all the time.

And if the developers spent all their time addressing those issues, well they would never get their regular jobs done. And I think that this all comes down, down to sort of underinvestment in terms of resources, but also in terms of attention from, uh, upper levels in the application development space. I mean, frankly, uh, fixing and uh, fixing security issues should be top of mind and should be central to CIOs.

But I don't think it really is, I think it's seen as a drag on resources. I think I it's seen as something that holds back application innovation. And I think that that's one thing that really drives a wedge between these security pros, as you said in this survey who, uh, you know, three quarters of 'em don't believe that their organization is addressing security threats.

Uh, absolutely. That's, that's, that's probably true. That doesn't mean that we should stop.

That doesn't mean we should give up, give up the fight. But what I would love to see is developers and security folks kind of coming together and saying, you know what? We're on the same side of this fight.

We are both trying to fix these problems. It's just that we are being pulled in different directions by, um, management, by the market and, and we need to resist that because there is the possibility to address these problems if only we could, uh, have the resources to do it. You know what, I think a big part of the problem is nobody stands up and cheers when somebody discovers a vulnerability and fixes it, right?

There's nobody going in the organization going, yeah, that was awesome, man, that was just high five all around you. You don't get that same vibe you do when a new feature is added to an application that somebody thinks is gonna drive revenue. So do we need to just kind of have a hero moment for application security?

Well, you know what, um, we kind of did have a hero moment for that with the, uh, execu, utils bug, didn't we? Um, I think there was a lot of folks who, uh, I mean a lot of the reporting that I read basically says, wasn't it incredible that this Microsoft researcher, um, uh, friend, um, was investigating and looking in the source code and found this thing and just, you know, raised it up the chain. Everything went right and the, the press, the tech press cheered this.

And I would love, I agree with you, I would love to see more cheering for victory, but unfortunately, I think kind of human nature makes us always looking for the bad news. I mean, I, I don't want to bring up any sore points for anybody, but if you turn on the regular old news, you're not gonna see a lot of cheering for victory. You're gonna see a lot of booze about, uh, problems.

I understand your point. Yet part of my soul's a little terrified that there's a lot more of those instances out there where somebody's been contributing to code and nobody's been really looking too closely and what that code has and what was the motivation for it being added to a project. So we may have some more trouble there than we're counting on in the near future.

Totally. But yeah, all things said we're still better off than we were if we did nothing. Right?

So progress is progress. Progress is progress, absolutely. And uh, you know, I woke up this morning reading about, uh, supply chain attack on WordPress plugins and uh, of course my first thought was, oh no, do I use one of those spoiler?

I don't. But yeah, I think that there are similar supply chain attacks happening across the open source space constantly. We have to be vigilant for them.

But I think that that doesn't mean that there's a problem with open source. I think it means that we are doing the right thing, even if we don't get a lot of pats on the back for it. All right, folks, that's it.

I gotta go now. Check all these word plus plugins that we have because we've been a little happy with plugging in things to WordPress over the years and some of us have lost track of what that might be. But hey Steven, thanks for being on the show.

Enjoyed the chat as always. Thank you for having me. Uh, I'm very glad to be contributing here and I'll see you on the Textron Gang on Tuesday.

Alright, And thank you all for watching the latest episode, listening as the case may be. You can find this episode on the Cloud Native Now podcast site, as well as Spotify and every other place that you can find a podcast. Until then, we'll see you next time.