Cloud Native Now Podcast EP 17 – Microservices Madness

Hello and welcome to the latest edition of the Cloud Native Now podcast. I'm here once again with Paul nti, and we're talking about all things related to cloud needed beauty, and we're gonna start off talking about microservices. Hey Paul, welcome the show.

Hey, great to be here. Good, great topics and, uh, great conversation to be had on this, on this day. We've been banging on this microservices drum for quite some time, and I kind of feel like maybe I should open up like a little therapy office for developers.

'cause it seems like everybody's kinda stressing out about all this stuff. And, um, we have a couple of articles on cloud native now this past week with some advice about how to deal with all this. And we recommend that and go check them out please.

But what is your perspective on what's going on here? Because, um, there are folks who are, you know, they give involved and then they throw up their hands and we wanna go home to model it. And then there are others who swear by it, and it seems like we're all over the place.

Yeah, it's, it's great kind of conversation to have and, and I'm, I'm glad to be on this, uh, this discussion, this week's conversation because I think that there's a lot to talk about when it comes to microservices. Um, you know, as, as you or the audience may know, or as you know, um, I am, I cover the application development monetization practice at, at future room. And, um, one of the things, excuse me, one of the things I cover and I talk about in the narrative is the, the, the context of past, present, and future when it comes to applications.

And there's a ton of applications that are still in this monolithic past kind of state. And those applications that are living in that state are really, um, organizations are really looking, there's a desire to modernize, right? And, and modernization doesn't come just for the fact that, hey, it's the new cool whizzbang thing to do.

It's because of security issues. It's because of resource issues. It's because of, you know, uh, whether it's, uh, you know, ESG issues, uh, you know, all sorts of reasons like data compliance and regulation.

Um, all sorts of reasons why, uh, organizations are looking at modernizing their applications. And when you look at microservices, uh, a lot of challenges organizations run into is the fact that, um, uh, there's skill gap issues, right? There's modernizing into, uh, from heritage applications to, to, um, microservices requires an understanding of how to break down that, that application.

So there is a huge desire to move forward from a monetization perspective. What exactly are we modernizing? 'cause it seems like a lot of times, if I look at the history of cloud, 90% of it was lift and shift.

Okay, that's great. And, you know, basically, you know, you're a mess over here. Um, are we going back into those applications and carving out the functions that lend themselves to be more like microservices so that they are reused and exposed through an API, but the bulk of that application is still somewhat monolithic.

Well, and so, okay. I guess the way I would frame it is when I tell and talk to organizations, I talk about this, this maturity model of, of application modernization. And in that maturity model, you have, I have five phases that I talk through.

And one phase, a first phase is when you have the heritage of monolithic applications. Okay? And then from there, the next level of maturity is to encapsulate and make that monolithic application into it, maybe a v app, a virtual machine.

And then from there, maybe in phase three would be moving from a VM to a fat container, and then from a fat container to phase four, which would be to move that fat container to microservices, breaking down that application. And then phase five would be having a fully elastic, cloud native, uh, application. Now, organizations can have applications that live in any one of these stages or these phases because not all applications need to be refactored.

Uh, and frankly, you're not going to, maybe you, Excuse me, maybe you'll have applications that go from, um, phase one to phase two and get encapsulated in a cloud ready state. But then, um, never, never mature any more, anything more than that. Those may, those applications may stay as a system of record, and then new applications may be built as systems of engagement that access to that environment.

So it's not just about modernizing for the sake of modernizing, it's not just about moving to microservices. Uh, it's really about the advantages to move to micro to have fully elastic environments take advantage of those cloud native architectures. And then also the portability across multiple clouds, if that's needed.

Well, I scratch my head sometimes 'cause I'm a simple guy and I can't help but wonder if we're overthinking this and that to a certain degree, everything is a service. There are microservices and mid-size services and model Xs that are essentially services that I'm calling through APIs. And you can call those big ass microservices if you want, but, you know, do we just need to have like this microservices mindset and not get caught up with how big is a particular microservice in any given?

Yeah, and that's a great, great question. I mean, it really, uh, I I would have to say it depends on the business need, right? Um, the reason why you would wanna break down these applications into smaller microservices is because there's less of an impact to the overall ecosystem when you have to do an update to that individual service within that application.

Also, the other factor is to consider is when you're looking at, excuse me, when you're looking at security, security, um, it also means reducing the attack space by breaking down that application into smaller components and having less of an attack space by having those smaller components. So it really does depend on the application and the organization's maturity model. And some of this has to do with maintaining availability of the application, right?

Because, um, microservices, if there's an outage somewhere, you can reroute API calls to something that's redundant and maybe keep that application going. Of course it might drive yourself crazy looking for where that outage is for several months before you figure out the three minutes worth of work that's required to fix it. And then other folks could say the monolith, you know, is a little easier to deal with maybe if for a small team or an individual developer, but if something goes wrong, the whole app crashes and you're on a look.

Yeah. And, and again, I think it comes down to breaking down that application environment and the ecosystem, depending on where you want to isolate the problem, you can isolate the problem down to the individual service and not bring down the entire ecosystem. That's an advantage of having a microservice.

Um, and, and that's why there was a, there's a desire to move to that, uh, what I was calling that phase four of the maturity model of applications. Now, again, sometimes what will happen is heritage applications will be, uh, encapsulated and left into avac container. So they could take advantage of, say, Kubernetes in the orchestration layer to manage the entire, um, application layer.

But, but you still want that, um, uh, ability to isolate smaller sets of the environment so you can, uh, basically manage that environment appropriately without having to bring down the entire application to do so. Do you think developers tend to give up a little bit too soon moving to microservices and they run back to model us when that happens? Or did they just make a, you know, the wrong decision upfront, then they make the right decision?

You know, upon further review, and it's just the, the nature of whatever the project is, Um, developers are looking at ways to, um, modernize their entire ecosystem. Okay, so when I started this conversation, I talk, as I said, I talk about the narrative of past, present, and future. What we're not talking about here is where I go into future, and sometimes one or one way that organizations will overcome the complexities of microservices is to utilize technologies such as web assembly, for example, bypass microservices altogether and modernize to a cloud native environment using web assembly where appropriate.

I mean, that might be a good solution for say, edge locations or locations that have different underlying hardware architecture. So you don't have to recompile the code and just use that, uh, application in an, in a cloud native space, um, on whatever architecture's underneath it, right? So that's an option to, to not go microservices, but to go, uh, web assembly.

Now, is that ready for primetime? Probably not for all applications, but it's definitely an alternative to learning the skillset of, of developing all applications or refactoring all applications within a microservices architecture. Alright, last question on this particular topic, but do you think AI might one day make it easier for us to cope with all this?

Uh, oh, AI's the answer to everything, Mike. Every, it really is. I mean, it's gonna solve every, every problem that we have now.

Um, I think that, yeah, uh, well, I think that AI definitely is an, is an enabler for, uh, increasing productivity. It's definitely an enabler for helping where, uh, where some organizations may be looking at utilizing AI to, uh, to help with that refactoring opportunity, but there still needs to be a human in the loop. I mean, there still needs to be, uh, an understanding of how to utilize those codes, uh, or those refactored applications and make sure it's really appropriate for that organization's needs.

Ultimately, AI is a tool, and the organizations cannot default on the fact that AI is produced something, therefore the organization's not responsible for what it created. That's not true. Um, you know, if an organization uses a tool and that tool creates something, that organization is still responsible for what it's been created.

So AI can produce junk as well as it can produce good quality, um, results. And I think that that human in the loop is still required to today to help accelerate those, those, those efforts. All right.

Let's shift gears to, I don't know, you know, if you've heard, but there's this little rou ha going on around Broadcom and VMware. It seems to be getting a lot of attention these days, and, um, almost everybody who provides some sort of rival platform has mentioned the fact that A, they exist, and b, you know, you can run something on their platform. The latest is Mirandas, which is talking about, uh, some new capabilities that they add that kind of resemble some of the capabilities you might find in a VMware environment on top of their instance of OpenStack that runs on top of Kubernetes, and they're making that a little more resilient.

How feasible is it to actually move a workload that sits on VMware over to something else? I mean, is this a, is this a project that's easy or is it'll take a long time and does that not wind up being more costly than just sucking up the bill from VMware? Yeah, it's a great question.

Like, I think that all many organizations are looking at alternatives at this point, and they're just, uh, trying to understand what's available in the market, uh, given the changes that are happening with VMware from Broadcom and, and what Broadcom is bringing to the table. Um, you know, there's, uh, there's definitely licensing costs is definitely changes. Um, and, you know, like you said, there may be reasons to just stay on a VMware platform, uh, because it's the most quote, cost effective way to do it.

However, um, many organizations, including morant's, uh, OpenStack that runs on top of Kubernetes, um, offer ways to, uh, as alternatives. There's, there's, there's a porting cost that goes, that goes along with moving out of a VMware environment to another environment. Um, the vendors that are making it frictionless and more seamless, like mirantis that has with this solution that they're providing, those, those vendors are going to provide ways to make it easier to move off of those environments.

But if you recall, this was what the back in the early days of VMware, this is what VMware's, uh, you know, kind of approach was, right? If you remember, uh, P two V physical to virtual and virtual to virtual and, and virtual to physical, those were all tools that were used back in the day in order to migrate from a physical environment to a virtual environment. Now we're looking at that V two V, the virtual to another virtual environment, or virtual to container V two C by using tools like co uh, KU Convert and, and other technologies to kinda get you there.

Mortis OpenStack for Kubernetes is another tool to kinda get you there, definitely worth looking at. Um, they, they have the, the open, um, uh, the alternative to open V switch, uh, for, for software defined networking. That's another alternative that they have to offer within their, uh, their tech stack.

And, you know, they, their, uh, their open stack, uh, for 2024, uh, which is the name with the code name that's using Car cartel caral caracol is the kind of the code name that they're using. But, uh, but basically this is using ways to use open source and software defined storage technologies to help with those, uh, more to more, um, advanced kind of applications that are running within VMware environments to move over to, uh, mortis. So there's options, I would say definitely if you're in that space to explore, uh, to go ahead and check out mortis.

But what I, to answer your original question, Mike, this is not gonna happen overnight. This is not a change. It's like, okay, I, I found a solution, I'm gonna move right now.

It's going to be a staged approach. As, as organizations are looking at their renewal costs and their licensing costs, and their moving from their heritage environments or their previous environments to a new environment mortis is about, is a, is an option that they can move to. Um, there's, there's many in the market right now that are going after the same space.

I think it's up to the organization to decide what is the right approach for their own business needs. How much of this is gonna be more like, I'm just gonna draw a line in the sand and say every new workload I build, I'm gonna put somewhere else but the, and, and just try to contain my losses per se, as it were, if I perceive it that way, versus going back in and messing around and moving data and workflows. Um, well, I guess it depends.

I mean, if you're going to move your environment from a VMware instantiation to, you know, a KBM instantiation, for example, you're moving from one virtual environment to another, um, is that really the direction that you may wanna go? One may seem more portable, you'll have, certainly, you'll, you'll have licensing costs to consider with different models. There're, but is that the objective?

Because previously in the conversation in this video, we were talking about, uh, you know, moving to microservices, right? If the goal here is to modernize and move that VM to a microservices architecture is moving to another vm, strategically the right direction to go. Or maybe what you do is you take that, uh, heritage environment that may be on a vm, uh, a VMware vm, and you may wanna move it to a KVM solution to reduce the licensing cost, but keep it as a cloud ready state as a system of record, have it left in place, and then build new systems of engagement in containers to have that modernization effect across the board.

All right, folks. Well, I would just point out one thing. If you're doing something because you're mad about it outta 10, because chances are it's not gonna work out the way you think about.

All right, next question. We're onto security. We have a couple of pieces on cloud native now talking about how to secure Kubernetes environments.

And I think this is becoming a bigger issue simply because there are more Kubernetes environments showing up in production environments, but I always felt that security was a little bit of an afterthought in the land of Kubernetes. So is that getting better? A lot of people specifically complain about world based access controls and, and it's just complicated.

Yeah, security is something that, um, I, you know, I think that it's important to go slower before you in order to go faster, right? You have to have security as part of your strategy whenever you're looking at modernization as well as Kubernetes deployments. Um, if you don't, you're making your obviously organization, your environment and your organization vulnerable to those secure security issues.

Um, with regards to Kubernetes and security, um, you know, I mentioned reducing the attack space, excuse me, reducing the attack space by utilizing microservices and having Kubernetes to allow you to do that. We see that 71% of container workloads are, are open to root privileges, which opens up a whole bunch of challenges as you can read this in the article that's on, on, uh, the cloud native now, right? That, that, that basically we're seeing that those challenges that, uh, you know, those need to be taken into consideration before you do the actual deployment.

So there's a faster deployment model for containerization and Kubernetes. So we're seeing more exposure and security, but that needs to be at the forefront of the modernization effort as part of that pipeline. All right, now, in a somewhat related conversation, but, um, whenever the things go bad, disaster recovery always comes to mind.

And we got a, a little wake up call this past week with, uh, hurricane s slamming into Texas and now rain, pretty intense, rain at least working its way through the, uh, southeast. Um, we're probably gonna see more of these storms this year or so. They're forecasting.

Um, what makes recovery in Kubernetes environments perhaps a little more challenging than other environments? And what should people be thinking through here? Yeah, I mean, this is where, excuse me, this is where a lot of organizations, uh, in our recent survey, uh, indicated that they're running, um, 92% of respondents actually indicate that they're running on two or more clouds.

Uh, 65% are running on four or more clouds. And application portability was considered to be critical by 20% of the respondents. And because of that, um, this is the, the BCDR story is, is incredibly important because of either manmade or, or natural disasters.

I mean, there is, there's natural disasters like the hurricane we just saw and, and the storms that are coming through, but there's also other disasters that occur, but business continuity needs to continue to happen, and the business continuity that occurs, um, needs to, uh, continue to drive, uh, ways around it. Now, when you asked about Kubernetes being, uh, uh, and, and containerization being, uh, a little bit more complicated, well, that's because there has to be integration between the storage layer, so the data moves with the application appropriately. So where the application is moving, so synchronizing not only your application, but your data sets to go along with it is equally important.

And that's, that's where you run into challenges with, um, using different technology stacks and different ways of deploying, um, with, with Kubernetes, uh, versus, versus traditional models where it may be in an all encapsulated environment versus a more distributed environment that you would find on the Kubernetes or, or, or microservices, containerization environment. Yeah, and you know, for all the talk of hurricanes, I sometimes feel like, you know, these incidents are more likely to involve, you know, silly things where somebody just accidentally kicked over a box and then took down the pods and the cluster, and we don't have a way to respond. Yeah, I mean, that, that to me is an architecture design, uh, challenge.

I mean, I think that if you don't architect, uh, redundancy within your environment where you have, you know, a, a a, an active active or an active passive kind of environment where if a box get kicked over, uh, then they can flip on the other one, uh, more seamlessly. That would be an architecture design, uh, deployment model. And again, there are many solutions in the market today that can address the, both the storage backend as well as the, the microservices and containerization front end in order to do that orchestration appropriately.

So, um, and then frankly, you can do it automated if, if there's a, a redundancy, and if, if you, you're pinging a host and a host is no longer there, it'll automatically transfer over to another host. So, so these things are in place and they're, they're available. Um, but again, it's, I can't stress the importance of the way the architecture is de delivered and deployed versus, uh, making a single point of failure.

On the plus side, it looks like all the vendors in the backup recovery space are discovering Kubernetes. We saw a rubric is adding support for Red Hat OpenShift, and there's probably gonna be a lot more of these things. So ultimately, does this finally just become part of the, uh, traditional IT operations motion and it won't be such a unique circumstance?

Yeah, I mean, Rurik is a good, is a good example of, uh, extending protection to OpenShift. OpenShift as well as, uh, prox, ve, right? I mean, there's, there's definitely a, a focus there around, um, I would have to say it has to do with that mon that that amplification modernization, where organizations are moving from heritage environments to more what I would call today's standards, which is microservice and containerization.

Obviously, data protection has to move and modernize with that, right? So if you're not doing that as a data protection company, you're going to be left behind, right? So leveraging the, uh, you know, the, the appropriate Kubernetes drivers for a stateful environment to make sure you're taking the appropriate snapshots, all of that is available and has been available for some time.

So utilizing that tech stack in order to, uh, follow, call it, follow the application where it may go, um, that is incredibly important. And when you're looking at, like we were just talking about with OpenShift, being able to follow across different clouds, different architectures, different locations from core to edge to, to different cloud locations, that making sure that you have the protection across each one of those different locales is incredibly important. That's what I'm seeing with the, uh, the data protection space as well.

When it comes to application monetization, it's a different world, right? It's not just this ENC encapsulated big monolithics, you know, uh, application environment. It's microservices distributed across multiple environments.

And understanding those different groupings of, of dependencies is really what these, uh, data protection companies need to be looking at. All right, folks, you're here. There's an old saying about how, um, small children, small problems, big children, big problems.

Well, that same rule applies to clusters, it turns out. Hey, Paul, thanks. Yeah, Thank you, Mike.

It's great to be here. All right, back to you guys later, and thank you all for watching the latest episode. You can find this on Spotify and all your favorite other channels out there, plus the Cloud native now website, tech Strong tv.

We'll see you next.