Cloud Native Investment Boom – Cloud Native Now Podcast EP26

Hello and welcome to the latest edition of the Cloud Native Now podcast. I'm your host, Mike Vizard. We're with Mitch Ashley, who's vice president and practice lead for DevOps and application development and anything else related to software at the Futur Group.

Mitch, how you doing? Hey, great. Great to be on again in this new role.

Right? There You go, man. Yeah, yeah, an upgrade, I'm sure.

Awesome. And you know, as you're transitioning this role, there was a report that you did for Techstrong Research and all of this is now coming together under a futurum, but, um, one of the interesting aspects of this whole thing was in the report it kind of looked at adoption of containers and, uh, orchestration platforms. And of course that's core interest to the cloud native folks.

And I wanna get your take on that. 'cause it kind of suggests, well, that 60% of the folks are increasing their investments in the next two years and 20% are gonna be very aggressive about that. I'm like, where does that level of investment go?

Because I've seen this kind of interesting dichotomy where people are embracing containers, but they're not so quick to embrace the orchestration side of it, which is a little more challenging and maybe a little more difficult, and certainly, uh, requires a lot more expertise. So what is your sense of how are containers and orchestration and this move to microservices and cloud native evolving? Well, I think that's the right way to break it down.

Think of it as containers, orchestration and microservices. You don't have to do all three, right? I mean, you probably need to do containers to do orchestration, but cloud, uh, microservices is not, doesn't have to be there though.

If you're doing microservice, you're gonna want to do it. Um, containers are relatively easy to adopt, right? It's a packaging mechanism.

Um, and, you know, whether stocker or open source or whatever it might be, um, it's, and the runtime for it is not, uh, heavy lift to involve. So a lot of people are doing that because just portability of moving across machines. They don't have to worry about like running guitar file to install everything on some local directory.

It kind of is like a virtualized, if you will, without the hardware, you know, interpretation layer. Um, and orchestration comes into play, I think even more so when you have microservices. 'cause you have literally hundreds if not thousands of microservices or instances of them running.

You know, when we did the research on DevOps next, we were looking at sort of this full spectrum of DevOps, the across the STLC. And one of the questions, or one set of questions was around cloud native and its adoption. Uh, so it didn't dial into a lot of depth on that, but it, there, it was over half, I think it was around 56% of people said that they had deployed applications using microservices.

Now, when you do a DevOps survey, there's a, there's a little bit of selection bias when people say, I'd like to fill that out, right? 'cause I'm interested in this topic. So sometimes that, that kind of increases your, your numbers a bit.

'cause I, that to me, I thought was a little higher than I would've expected to go all the way to microservices. Now you're redesigning the architecture of your applications. So, but I think, I think the, the point being containers are very easy to get into.

Orchestration involves Kubernetes, that gets complex as well as m services do too. Yeah. There's a lot to take apart here.

We're headed in the cube con and almost every cube con now has the same kind of, um, vibe. We all show up and we go, wow, isn't this amazing? And 10 years on and this is great.

And then about we have three or four hours in and we start going, man, this is hard. How do we make it easier? And now we get all these data scientists complaining about how hard it is too.

And, um, is there something to be done to make orchestration simpler? And how can we get to that? Or is it always gonna be inherently complex?

Well even go back to, I think Alan interviewed one of the creators, Alan Shimmel, the, uh, the CEO and, uh, chief editor, whatever his title is with these days with Techstrong. Um, and even, even the creators of of Kubernetes say it's too complex. Um, but there's some very, you know, very sophisticated things.

I I think most people have gone down the path of I'm not gonna build it myself. I'm not gonna try and run and operate all of it myself. Maybe if I'm in a cloud hyperscaler I'll use their Kubernetes offering and at least get some help with the management of it.

Now, it's not an outsource run, run it for me kind of thing. But it does take a lot of the configuration and setup and maintenance off your hands, which is, it's still part of the complexity of it as well. And then, then the question is, what are, are you using it for?

One things I find fascinating about Kubernetes in particular is 'cause you're using Kubernetes if you're using, or containers, if you're using Kubernetes, as we're starting to see Kubernetes show up in, in technology products that are being sold to IT, organizations that are delivered on the cloud, maybe delivered at the edge or running a K three or K zero lightweight version of Kubernetes. So, you know, all of those. Point two, there's something to this, it may be complex, um, but I think that Kon my observation the last couple is it's almost a, just a developer conference as much as it is about, uh, Kubernetes more.

So I think that's why we see all the different people coming and you know, it's, it's, it's my friends. It's the, the black shirt and uh, and backpack crowd, which I know I'm home. And, and to your point, I might not see Kubernetes, right?

It's supposed to be a platform for building platforms and it may be embedded in an application or it may be a managed service with an API. And you know, theoretically I need to know less and less about it as we go along, hopefully. Well, and that, I think that's what people are trying to do is like, how do I not have to deal with all of it?

Is there a better way than than us, you know, taking all of the burden on ourselves. Microservices, uh, some people love them, some people hate them. Um, and you've heard stories about people embracing microservices only to run back to monoliths.

And um, and I guess I'm trying to figure out where are we on this kind of giant adventure? 'cause sometimes I talk to other folks and they're like, well yeah, it's a microservice. I put it in a container and I stuck an API on it.

And uh, you can call it. And some of us refer to that as, you know, a big ask microservice some, you know, is that, are we just getting more practical about all this stuff? And we're saying, you know, let's not get caught up in the size of the thing and just say, so long as it's a component and it's callable, that's what we're aiming for.

Well, it's sort of the hammer and nail. If everything is software, it doesn't mean everything has to be a microservice, right? Mm-Hmm.

So it's, it's what is it good for and what do you the why are you gonna go down that path? There's the, we're supposed to do it 'cause everybody's the cool kids are doing it right. Let's go do, do microservices.

And then there's the, well, let's see, why would it help us? And usually the benefits around microservices are for scalability and also for, uh, producing code production codes faster. 'cause you can, you can deliver smaller pieces of code.

Now there's always a debate about, well what is a microservice? What do you make of microservice? How big is it?

How small is it? Um, and there sort of theoretical definitions about one immutable task that it's doing. But it really comes down to if you need lots of scalability in an application, but you don't need the full app to scale.

Maybe it's the, I don't need the credit app check microservices to scale. Maybe I don't don't need to go rebuild that. Let's just call the credit app, uh, credit check app, uh, to do that.

But I do want to, to put the orchestrator, the handles, the routing of where applications are in the process so they get to the next step is the fastest possible place or maybe the ingestion of it from our receive it, uh, a user end user experience so that that's fast. When can scale if we have a big, you know, push to, uh, sell at the end of the year or we're, you know, whatever the latest toys are us are, you know, we wanna order as many things as we can. That's, I think you wanna look there for it.

So my own pre experience was we had a monolith application in ASP net application and we wanted to change, we wanted to do more with it, but a lot of it, nobody knew how to touch anymore. So we carved off just a piece of it and said, let's use that part and we'll make that microservices. It turned out really well 'cause we didn't go bigger than we needed to.

And we could experiment more, experiment more and put some new services in market more quickly. Yeah, I feel like we got caught up in some sort of religious discussion without realizing that maybe we're actually all hanging out in the same church anyway. We've never had those happen before.

Really. Just discussions around software architecture methodology. What, what, what are you trying to say, Mike?

Then you go, i, I do wonder if maybe we missed the point about microservices and we were talking about cyber resiliency, you and I and the rest of the Textron gang and a couple episodes ago. And when I look at microservices, one of the things that's trending about it is that, well, you can reroute API calls when there's an issue with a service and the whole application environment becomes more resilient as a result. And I just wonder if that's not the best use case for going to microservices or the best justification at this point.

'cause if there is an outage or if there is a cyber attack, I might have a way to kind of not have the whole thing come crashing down. It. It's a great point because, you know, resiliency can be meeting the demand as well, right?

As well as failures. There's lots and, and our, our kind of working definition around resilience, resiliency isn't recovering from a failure. It's withstanding, um, sort of really, uh, trying or untested conditions so that you still stand up, your app is still running, maybe a little bit of degraded performance maybe here and there, but you're not crashing and bringing the whole thing down to its knees.

So not everybody's in Netflix. Not everybody needs to scale up at, you know, 6:00 PM 7:00 PM and, and handle all the movies that everybody's watching across whatever region. You know, we are an online site and maybe our high demand peaks are in the holiday season or they're, um, we do an Amazon Prime kind of a special.

And so we're gonna get a lot more orders and it's, and it's those peaks that you want to be able to meet or, um, we have very kind of regional applications and, but when something happens, I don't want to be solely dependent upon that one region. Lemme fail over to another one. You better yet let me gracefully fail over by spinning up more microservices to meet the demand.

And that's the other great thing is you're not, you're not spinning up big monolith applications, multiple of them. You're spinning up the two half dozen, 10 different microservices that might be involved in that part of the engagement with the end user. So it has that big advantage.

So it can be a lot faster to bring those up and take them down. Mm-Hmm. And one of the things that always struck me was I think if once you move to cloud native and microservices and Kubernetes, it kind of requires a level of maturity around DevOps itself to succeed.

And these things are kind of closely linked. But I wonder if part of the problem with maybe moving to cloud native in general is that it does require a level of DevOps expertise that a lot of organizations don't necessarily have. So is DevOps kind of a prerequisite for being successful with Cloud native?

We had this debate actually on a, uh, round table about a year ago, maybe it was a little longer, and said, is microservices cloud native require DevOps? Can you do it without it? And if you think about it, the why they fit so naturally together is DevOps is about spinning up the flywheel.

So you can produce software at a higher velocity. And part of the way you can do that is by creating smaller units of work that goes through those pipelines instead of very large applications. And you could still do do it with very large applications, but imagine, I mean, so it fits really well with microservices and containerized parts of your application.

'cause that can flow through very quickly. It's made to do that. Now doing it without DevOps is, okay, so now I'm running a bunch of scripts and trying to orchestrate all of that myself and not using, you know, necessarily A-C-I-C-D pipeline to do it or an automated testing platform to do that.

Or essentially you'll end up at the same place. So I think the, the, a result of that debate that we had in the round table is you could try it, but, but, um, you know, the, the question would be, you know, what were you thinking? Why did you go down that path?

You should, you already know how to do DevOps, you're set up to go take it. Or if you do go down that path without DevOps, you're eventually gonna find yourself in the land of DevOps because you're going to adopt the principles. And, and instead of reinventing that wheel, you could just read the book, right?

Kind of, I guess you're backing into it, but you're there, right? You end up exactly place And it's like, look ma no hands DevOps. Hey, I guess I do have, have hands.

Okay, anyway, I'm, oh, ultimately, what are you thinking the term cloud native now means then? Because, you know, originally it was kinda like, oh, we're gonna do Kubernetes and microservices and this is all different, but now we encapsulate virtual machines into containers and everything's kinda running on some type of cloud, but it may not be a hyperscaler. So how has all this evolved in your mind?

An another panel, we had a debate about what is cloud native mean? Was that DevOps world last year? Um, yeah, I, I started 'cause I followed the CNCF definition.

It's, it's changed now, but originally it was, you're using containers, container orchestration, Kubernetes, um, microservices, um, there was another one, I can't remember what it was. And open source software. And you're designing and building applications that way.

Which, which is sort of the next architecture of, of how to evolve your applications that is as broadened, you know, like all of our terms mi right Mike, we start to apply 'em to many things. And folks that weren't going down the, the microservices path, um, of cloud native started to consider, well I'm building applications but I'm also building them differently even though I'm not using microservices, I'm building differently 'cause I'm building them in the cloud native, you know, sort of like a digital native, right? You grew up with, with a cell phone since you were, you know, a little kid.

Now, now the kids, you know, you, when did they get a cell phone? Is it two or age three or a year and a half? You know, exactly.

When can they run one of those, it's kind of the same thing for AppSec. It's built for the cloud in the cloud out to operate that way. And you can define what those attributes are.

There's no strict definition of it. You could build an app. It, it may be closer to a monolith in, in in architecture, but you're using services from AWS or Azure, Google, wherever the cloud is or, or, or Oracle, IBM, et cetera.

And designing it around, uh, a more malleable, uh, flexible infrastructure rather than I have a fixed set of this. So let me give you one example. One of the first ahas for me about why the cloud was different, you know, everybody thought, oh, it's just somebody else's computer.

Well, yeah, but when you have a really large set of computers, resources, storage, processing, et cetera, um, was at a talk at an, at the first AWS reinvent and one of the A-D-A-W-S folks was talking about how they do upgrades. They didn't do upgrades. Like I always, we've always done and everybody did, which is you have a system, we're gonna be down for the weekend or for these hours and we'll upgrade it, upgrade it, upgrade it, you know, do a lot of praying and laying of hands on the software to hope that it all worked.

And then turn it back on or back it out if we had a failure. And the, you described it as, no, you keep this running, you let that run, you bring up these servers over here, you install the new software, you start to point some traffic from here to there gradually. Okay, it's good.

Great there. Now it's all running over here. Bring this part down.

Okay. That's a different way now that, that's a, an example of something that would be cloud native and how you could build your application and also run it like that. All right folks, well you're heard it here.

If your thinking gets really rigid, chances are you might be doing yourself a disservice in a world where flexibility is everything and all these different tools and capabilities you have out there, use 'em. That's why they're there. And we didn't just create them so we can have an argument over architecture.

Hey Mitch, thanks for being on the show. Hey, thanks for having me again, Mike. We'll talk to you soon.

All right. And thank you all for watching the latest episode of the Cloud Native. Now you can find this episode and others on our website.

By all means, check them out. We'll also be on Spotify and all your favorite social distribution channels for podcasts. And until then, we'll see you next time.