Under New Management? – Cloud Native Now Podcast EP4

Welcome back to the Cloud Native Now podcast. I am Sharon Florentine once again, I am here with Mike Vizard, and we have some awesome, awesome issues to get into with you this week. Uh, the first one being as an organization, when you're putting together your Kubernetes team, how do you go about doing that?

What is the best way to staff those folks? Do you want to start building and upskilling in-house? Do you wanna bring in freelancers?

What are the pros and cons of these two approaches? Yeah. Or sometimes not just freelancers, but actual professionals with skills, because there's a whole class of folks who are managed service providers who you and I are both pretty familiar with and have a lot of expertise in this space, and Yep.

So I, I think the debate though is, uh, do I go hire folks or try to hire folks and retain them when they are hard to find and in high demand or, And very expensive, Right? Or do I go with contractors that are available, but you know, they come and go and they may not be around when I need them versus, you know, you're starting to see some managed services from outfits like Fairwinds and others, but, um, you know, they've developed a team. They have a framework, they manage these Kubernetes clusters, and that becomes a bigger issue as you start dealing with fleets of clusters versus onesies, twosies.

And I think we're gonna see, you know, everybody using a mix of all of those things, but maybe more reliance on managed services. Because if I look in the cloud, most of what people are using from AWS and Google and Microsoft and the like, is the managed services version of Kubernetes. They're not provisioning it there.

So it's not clear to me they want to provision it in a local data center at the edge themselves, either. But what's your sense? No, I agree.

And I think that's, that's where the success of, um, so like you mentioned, the, the AWS managed Kubernetes, uh, service is, you know, that's, that's kind of what's driving that is folks are looking at this and saying, this is, as you say, many times, Mike, this is one of the most powerful but one of the most complex technologies to ever hit it. And people are looking at that and going, you know what? If I can find someone that I can pay to do this for me and make sure that everything works together correctly and runs smoothly and achieves the outcomes that I wanna achieve, I am just gonna offload that and, you know, be, be happy with it.

Mm-Hmm. Um, And there are a lot of places where they have platform engineering teams with that level of expertise, but the closer you get down to the mid-market and SMB, the less expertise there is. So the tendency to rely more on managed services, I think edge computing all will force this issue because, um, if I start having clusters that are distributed at the network edge, they're physically in places that I don't have an IT team to get to anyway.

Right? So I'm kind of have to find some way to centrally manage all that. And sometimes it's just easier to hire somebody to do that than to do that myself.

Especially when, um, my internal IT team probably has a handle on my virtual machines and my monolithic applications. But do they know Kubernetes and client Right systems Attached to that and, and cloud native applications that are built on top of the clusters themselves? Um, I'm well wondering.

I got my doubts. Yep. Yep.

And I think people make a lot of, of, uh, noise about the cultural aspects in a previous life. One of my coverage areas was hiring and upskilling and, uh, and all that, that good fuzzy stuff. And, uh, you know, there, I think there's something to be said for that team cohesion aspect that you work with these folks every day, you have a shared goal within the business that you're all working for full time.

But I think there's also a place for bringing in external folks, whether that's via managed service or a, a freelance or, or a contract worker because you get a fresh perspective. Maybe they use different tools, maybe they have different approaches or ways to look at a problem that you don't. And, uh, so I think they're, it's once again, it's unique to the organization and everybody's gotta do what is best for them and what's gonna get them to the outcome that they wanna achieve.

I think there's kind of three yardsticks to look at. I mean, the first one is, yeah, how much do I need to continue to do this every day? Do I need my team to do that every day?

Or is this a task that we need to do one time only? It's kind of the reason why you see so many organizations rely on contractors to build applications for 'em. 'cause they're basically like, well, once we get the application up and running, we can take care of that part, but we don't really wanna hire a full-time developer just to write the code for us.

We can get that from somebody who's a contractor. And then I think the third leg then becomes, what, what level of scale am I gonna deploy and do I have have the skills and expertise to do that? And if I don't, but my scale is gonna be large, like, I don't know, I'm gonna be using Kubernetes in, in, you know, a thousand retail stores.

Maybe I am gonna look towards a managed service. So it all comes down to that. But you and I know that historically there's always been a bias against managed service providers.

Internal IT team is always a little wiggy about the fact that somebody's coming for their jobs. And, um, a lot of times the MSPs are, uh, inconsistent, shall we say. And they're, uh, their flexibility and they're even desire to, you know, they'll say all the right things, but in reality they got a hundred customers and they're trying to manage this thing in some way that scales and is centrally, uh, consistent.

So their tolerance for exceptions is small. Yeah. Yeah.

That is an excellent point as well. Very true. Let's Move on.

Let's move on to this next topic, which is kind of related, but there's a post up there on the site talking about automation and Kubernetes. And if ever there was a need for automation Kubernetes, is it, there's more knobs and things to turn that can go wrong on Kubernetes and misconfigurations? And I think it's part of the problem is that, you know, it's the most powerful yet complex platform to come down the enterprise.

IT pike in a long time. So we need automation. We need to find some level of abstraction up here that allows us to manage this at scale.

And I think, uh, part of the reason it's holding Kubernetes back somewhat is that there isn't enough automation framework in the IT environment in the first place. So it's not clear to me where's the, who's the chicken and who's the egg here? Is the automation the thing I need first before I get Kubernetes?

Or if I bring Kubernetes in and figure out I need automation, either way I gotta get there. Yeah. And it, it seems like from my perspective, a lot of folks take, take the second route where they get Kubernetes into their environments and then go, oh my God, we gotta automate this somehow because this is way, way too much.

Um, you know, and as the article talks about Kubernetes operators as a way within Kubernetes itself to do that, um, I don't know, not being a Kubernetes specialist myself, how effective that actually is. Um, tends to be, Yeah, let's talk about operators and helm charts and all this other fun stuff that's out there. So we kind of have helm charts and, and other tools to help provision the infrastructure and Kubernetes, and then we have operators for deploying the software on top of that platform.

It's kind of a loose way of thinking about that. The challenge is, uh, you know, so let's say I have six things running on Kubernetes, well, that's six operators now. So, you know, that's, you know, too much of a good thing.

And if you get into some of these areas, some software, you know, open source, there's seven operators that exist that somebody built because they didn't like somebody else's operators. And now I got seven choices for that, and I gotta figure out which one to standardize on that. And hopefully sometimes the vendor or the community drives that conversation and sometimes not.

Um, I think that there's a, a big opportunity to create custom operators for organizations where, so I have a stack of software. I've got six things that I deploy rather than having six operators, maybe I'll have my one operator that I created that will span all six elements of my stack. And I'll just provision that with a single operator.

If you look at some of the, uh, global system integrators, that's clearly what they're doing. And you know, it's an, it is a good way to think about how to do something at scale. So, uh, don't be afraid to, you know, go in there and build your own operator.

'cause at least that one, you know, and you know, you won't be trying to figure out how to make operator A, B, C, and D actually maybe talk to each other someday. Yeah, indeed. And it seems there's also built-in tools with a lot of the common CI/CD, uh, tools, as I use that word again, um, you know, Jenkins, GitLab, GitHub actions, all of those seem to have added ways for folks to, to include automation as they're trying to get these tools to work together.

So it seems like, you know, there's, there's lots of options out there to be able to do that. The other thing about automation is automation for who, so there's a world of difference between a DevOps team that has programming expertise and knows how to work with APIs and can, uh, do things that, you know, your average IT administrator cannot do. They are, um, not trained to program.

Remember having this conversation one fellow about all this stuff about how, uh, he may have to learn programming skills to, uh, continue in his line of work. And he looked at me and laughed. He said, brother, if I could program, I wouldn't be in my line of work.

Right? Yep, exactly. So, um, I think we do need to have more of these graphical type of automation tools that are made for mere mortals in the average IT administrator so they can manage Kubernetes clusters at scale.

And let's be honest, even the DevOps folks don't always want to write code to go do something if they can push a button. So, um, we need to find a way to strike a balance between, you know, the classic IT service management mentality and the DevOps mentality about what to manage when using code and what can just be done with a button. Yeah, good point.

Good point. Um, I want to move on to something that always confuses me a little bit, and, uh, I'm sure there are folks out there who are a lot smarter than I am, but, uh, we had an article this week talking about the maintainers of cross plane have added Python support to their control plane. Mm-Hmm.

And, uh, first can we get into what is a control plane? What does it do? And you know how this ties into our kind of management discussion, All right.

In the beginning of time. No, I'm just kidding. Uh, but you know, for the most part, with DevOps, we rely heavily on APIs and scripts to automate various things.

A control plane essentially pushed that up a level of abstraction and, and really was driven by the cloud service providers. If you look at, um, how they manage their environments, they have a control plane through which they enable their teams to. And it's a mix of folks with different levels of expertise to manage things at higher levels of scale.

Cross plane is trying to take that notion and make it more applicable a outside of the cloud and for, you know, to apply it to whether it's the edge or local data centers, but also to have ultimately one control plane to rule them all. Because part of the problem you run into in this multi-cloud universe is that now, uh, you know, I got an AWS environment, I got a Google environment, and I got a Microsoft environment every time I had a new environment, I gotta add more people, right? To go manage that.

And that's where the total cost of it starts to increase. So a control point provides the mechanism in Crosspoint specifically for unifying the management of these hybrid cloud computing environments and beyond just having multiple clouds, right? And kind of, we throw around these terms all the time, right?

Like somehow or other multi-cloud equals hybrid cloud. Well, in my mind, multi-cloud is just a bunch of clouds and it's a mess. Hybrid cloud is, you know, I'm bringing some adult supervision to this thing and I'm unifying the management thereof, and I am reducing the total cost of it, which as far as I can tell in this current economic climate is an issue, Seems to be Okay.

Well, that, that helps. That helps a lot. And you know, going back to what we were talking about before, you don't, you don't necessarily wanna have six different control planes, right?

Because if your, if your goal is to reduce the complexity by adding that level of abstraction or unifying something, then why would you need to do that six times? I mean, the issue with cross plane though, it's like I have to first figure out that I need Kubernetes and then I need to figure out how Kubernetes works, and then I've got this thing cross plane as an extension of the Kubernetes API. So this a significant bar of skill to get to before I realize that there's this thing out there that can make my life a whole lot simpler.

But, um, I think what will happen is as you start to see more Kubernetes clusters starting to show up in the enterprise, people will start saying, uh, well how can we centralize the management of that? And then they'll get to control planes and then they'll be like, well, can I apply this to our legacy stuff? And people will go, yeah.

And then we'll get to some rational behavior. Versus I think trying to, you know, take a legacy monitoring platform and trying to turn it into something that manages both, uh, monolithic AppSec and Kubernetes environments might be a bridge too far as they say. Yeah.

Um, so you had an interesting conversation too earlier this week that, uh, I think we wanna wrap up with With, yeah. We were having a chat with, uh, Marcus Elli from, uh, red Hat about internal developer portals. And you know, in the context of Red Hat, that's always a conversation about, um, using their OpenShift platform, which is a flavor of Kubernetes.

You could argue it's a highly extended version of Kubernetes. But, um, we were talking about the notion of internal developer portals, and there's a lot of interest in this idea as it applies to platform engineering, which is kind a methodology for managing DevOps at scale. That's starting to catch on with folks.

And a lot of the times it starts with, the first thing that these teams do is they go, well, let's build an IDP, which is hardly a new idea. IDPs been around since time began, but it feels like we're trying to find some way to build these things. The uh, red Hat platform is based on the IDP that, uh, Spotify originally built, which is what a lot of people are doing using Right Backstage, right?

Yeah. Truth of the matter is backstage is almost as a complicated as Kubernetes to deploy. So indeed, red Hat is basically saying, we will curate that process for you and streamline it, and, uh, it's part of the great subscription service that they provide.

Uh, some folks may look for something that's a little simpler, uh, depends on, you know, what your, uh, favorite approach may be and how complicated your development efforts are. But it seems to me at least that a lot of this platform engineering and IDP conversation is starting with Cloud Native because it's only then that I have enough moving parts and microservices and complexity that makes this a real issue That I am, I am seeing that too. And it, it definitely, that seems to be true to me as well.

On the DevOps side, I would say it's, it's taking hold. But in much, much larger organizations, which again speaks to, we have too many moving parts. Everybody's trying to use different tools and different things to reach the same goal.

We need to standardize, we need to get everybody on the same page. How do we do that? And seems to be the way, Well, here's the paradox, right?

So we embrace DevOps to get out from underneath centralized it so that individual groups and departments can enjoy more flexibility and develop software faster. Fast forward to today, and it's like platform engineering is back with a hard centralization flavor to it, and it kind of feels like sometimes we're talking about the revenge of it. Yep.

The balance is how do you do that in a way that enables scale but is not so heavy handed? And by that we mean it enables developers to kind of bring in new tools when they feel like it or, um, is flexible enough to enable different teams that wanna work it slightly different way to do that way versus, you know, saying thou sh all the time. And you know, there's a big difference between, I guess, uh, guardrails and fences.

And I think if you're on guardrails, you're okay. And if you're building fences that force everybody down a path, I can almost guarantee that the rebellion is not far away. Indeed.

And it will be fierce and swift. There you go. Well, I think that's all we got for this week, right?

I believe so folks, thank you so much for tuning in and listening to us chat. If there's, uh, anything you want us to talk about, please feel free to reach out and let us know. Uh, if you are an IT cloud native professional who wants to come on and have this conversation with us, we would love to have you shoot us an email.

We'll put our contact info in the show notes and, uh, we'll get you here on camera. We'll pepper you with questions. And of course, if you're happy to be going to CubeCon in Paris in March, by all means stop by by the booth.

Indeed, indeed. And, uh, in the meantime, check out we've got some great content coming in from some of the folks who are also going to be at, uh, at CubeCon. com.

You can check it out there. All right folks, well thank you again. We will talk to you next week.