Rob, Hello, I'm Rob Hirschfeld, CEO and co founder of RackN and your host for the cloud 2030 podcast. In this episode of The Tech op series, we step back and talk about cloud self managed infrastructure and really how you balance the competing concerns? Can you have a cloud broker? Can you do multi cloud, some sort of tried and true topics for cloud consideration, but through a new filter, through this repatriation idea of mixing and matching your IT. Infrastructure, spend more. And we started from a report that RackN had commissioned, talking about on premises Kubernetes, and mixing that into your IT, infrastructure, so a lot of good fodder to start a fantastic conversation that I know you will enjoy applause. The we just posted the results of some the Kubernetes survey that we did. I'll post it again. I can't know because it's taken over my talking about a survey that we did about Kubernetes on premises, self managed Kubernetes, and we were just posting a summary of the results for it.
I'm assuming that 2% Susan is rancher. I
would assume that too, yeah,
surprisingly low. I was expected to be larger than canonicals.
I think some of that is the survey, I would agree, sampling bias, yeah, it was, it was 30 enterprise users, predominantly us, so that could contribute. It could also be no that should have shown up as rancher, because I don't think this was an open I'd have to look at the survey to see if that was open ended or not, because some people doing rancher might not think of it as Susan
bundled on the open source?
Yeah, it's an interesting question, because if somebody's picking, say, Talos, or, you know, some of these other more open distro open seeming distros, would they choose that as open source?
I would have imagined that the people going open source would have likely chosen kubeadm, or at least the ones responding open source with being the ones using cube ADM. Yeah.
Do you think and this is, this is strictly, you know, enterprise from that perspective, yeah, because there's, there's things that didn't show up in this at all, which are, like hybrid cloud options, and then tanzu, although I haven't seen much tan zoo in the wild, and I don't, I don't think anybody is considering it a serious distro anymore.
Would suffer from the broader VMware challenge, with the question being, which Kubernetes distribution are you focused on? Somebody might say, I'm no longer focused on tanzu, and I'm looking for other things, right?
But more generally, outside of this, y'all are y'all seeing tanzu anywhere? No, no, not even hearing about it.
Only when I when I use Valero, because that's still a tanzu sub or tend to adopt it, uh project
they, I mean, but I, my, my assumption, based on what I saw from layoffs and things like that, was that they were basically that team was, was completely out, you know, just gone. But,
yeah, yeah, it's, I mean, there probably isn't much development that needs to be done in Valero currently, more maintenance, and we'll see how how it gets treated by open source communities, since it is a CNCF graduated project, it might be that it ends up getting adopted by a different team and ownership transferred, but yeah, if it does, if it does get abandoned, that. That will leave a pretty big gap, and the open source capabilities for DR and look Coronavirus like that, there's only a handful of players. There's Valero, there's casting, which are the two big ones after the big enterprise he wants, and then, like everything else, is a very distant third and fourth.
I mean, the laro here, I'll share my screen. I'm looking at the get repo for 10s. Where's my Oh, I see what?
Okay, there's a new helper. No, I don't want to, okay. Trouble finding their screen because it was black. This is, this is the tanzu VMware tanzu repos, and so most of them, yeah, are, are active, right? Three hours ago, five hours ago. This is granted, and this is order of activity. I
I think it's got to be a critical commitment to their private cloud story. I mean, since it certainly that's been a key focus of doubling down, tripling down on that. I mean, certainly you could lean into VMs, but, I mean, I think if you're going to tell a complete story, there's definitely got to be a Kubernetes and containerization facet of that story. So I don't see it going anywhere anytime. So,
yeah, it's it just seems like a risky bet. If you're most, most, I won't even say most. I haven't met any company now, right now that's not talking about a VMware exit strategy. So banking on on your future, your future Kubernetes for that on Broadcom. Seems a stretch at the current attitude.
Valeria is an open source project, so the risk there is much lower. I mean, sure it could, I guess VMware. Could this one give it the like the HashiCorp or read this treatment? But at that point, you'll look at a fork right away,
right now, and this, this one looks this. I didn't, I wasn't aware of Valera before, so this was hepki oarc. It's, it's a backup and restore Kubernetes clusters. That's nice, okay,
it is the de facto standard for for implementing the our strategies, including that, okay,
yeah, the Heptio team came out with a ton of of useful utilities. That right? They have a retro, retrospectively, a very good track record, wow, yeah, a lot of very active repo.
I'm trying to look at the contributors data on on, on the Valero repository, and it just keeps spinning for me. So I don't know if it's a an issue with that browser blocking the request, or just to pick up so much contribution that GitHub is failing on
sometimes the GitHub stats, especially, I find very, very slow could be. There are times when I find it to be, yeah, as to go repos and calculate them, takes a while sometimes, yeah,
probably un indexed as well.
Although, if they've calculated them, they'll they come up nice and quick. So they're definitely caching them. Yeah, there's a ton of there's a yeah, this is an active project. Very good sign of healthy. Healthy project. Nice. Good to know.
I think the other part becomes when you think about the utility that it provides. I don't know that. And VMware necessarily has a desire to enter in that business in terms of data protection, whereas, honestly, the other player in the space, one could argue, would be more of the concern in terms of cost and
custom, is a solid product, but it's definitely pricing itself at the enterprise level with no entry level option there he I've used it In the past, back when they started out. And their quality is good, it shows that it's not as it's not it hasn't had the open source backing that better asset, right? Yeah.
This is one of the things we were talking to some Gartner analysts, and one of the things that they've been indicating as signs that Kubernetes is moving into the mainstream, is the appearance of these, these products, right? Backup, recovery, including in the virtualization space, where I'm retracting very heavily,
security as well.
I'm speaking of security, was announced last night, the csbm vendor wiz will be acquired by Google for 32 billion
Holy Cow
last year, Google bid for 23 billion, and they refused it back then.
So what 10% up or 50% up was the sweet
Well, that and back then, I think there was some antitrust concern. I guess that's not an issue anymore, but, yeah, it's, it's a big change for them.
That's a huge do they can they just, do they have the revenue to justify their valuation or the potential revenue?
Um, likely, yes. So as far as cloud native CS, PMS, go with is, is doing really well, so that they have a very polished product, but they also have very strong integration with other components, for ingesting additional data, for for generating reports. So it is essentially a part of a new generation of cspms compared to things like CrowdStrike or or the other more standard ones. It does get priced. There's
an AI story in the middle of this too, right? Okay,
machine learning, yes, so like standard AI and not LLM, okay.
Well, that's incredible. I
think the challenge becomes, how do you how do you recoup that kind of money, if you're Google, where are you actually leveraging it to drive that sort of value would be, my question. Excellent question.
Subscription fees.
So still positioning as a standalone solution,
not in Google that they're likely integrated very tightly into their cloud security center.
I mean, some of it is, if you have a product that has enough reach the data that you're going to get. It from, you know, even if you're not, I'm assuming they're not reselling the data, but the analytics information that you get out of a product like this is in itself valuable, but I'm not sure
32 billion or the other aspect of it is, if wiz has a very large customer base, I mean, for all intents and purposes, you're also buying customers, and particularly in theory, looking to expand into those accounts.
That same time, I'm doing the math, assuming, say, a 10x valuation there, that would be a 3 billion run rate company, which seems high.
The number I'm seeing from October of last year is 500 million in ARR where they hit.
Oh, my God, so that's a 30 billion. That's a 3030, times multiple in revenue, say, 25 to be Yeah, they probably grew a living.
They Yeah. I mean, they have been growing like that. They're they've also been very aggressive with their with their sales. The other thing that I suspect also comes as part of the package of the price is the patent portfolio that they might have. I
I, yeah, it's interesting. It's it can't decide if it's comforting to see more tech acquisitions starting back up, or if it's, you know, these types of valuations, it felt like things were slowing down a little bit. But I over the last year,
yeah, personally, I I am not happy about this acquisition. I mean, I can see why Google want, wanted to acquire Wiz, but I was hoping that they would stay independent, like this would be like Google acquiring Splunk or elastic, right?
It's it's a weird with with the three dominant clouds bouncing around, yeah, any you know, companies getting to this size, and with a multi cloud strategy, it creates those interesting dynamic and market from that perspective, what's going to happen to independents? How can you build multi cloud if or is getting too big make you harder to acquire? If this is if it doesn't, then that's a good, potentially a good thing. But would this make Amazon less likely to collaborate with Wiz? I would, I would assume so. But maybe, maybe they've reached the the uneasy truce between the cloud vendors and they all recognize they're going to be at each other's trade shows and list each other's products. It'd be a fascinating milestone. I think
the security side lends itself, I think easier to a multi cloud conversation and the idea of working with others, particularly in the fact that there's nothing that, in my opinion, necessarily, inherently suggest or provides a capability by which to be able to move workloads from one cloud to
another. That is not what wiz does, and when it comes to moving workloads or extending Google's tendrils into other clouds. Google already has anthos or, yeah, no, I'm saying rebranding.
They do this in the sense that wiz isn't any of those things. It being focused on providing security. There's nothing that, my opinion, that AWS or Microsoft would have to fear about a customer leveraging wiz or wanting to collaborate with Wiz from a security perspective,
yeah, I agree with you on that. I think that the biggest fear would be on the customer side itself. You. Like with having been producing an independent company and now being under Google's umbrella? Well, any customer that had chosen wiz specifically because they were not Google is then back on square one? Yeah.
Unfortunately, I think that's a bit of the nature of the beast with the tech industry. Now it's like, I'm using this because I don't like insert mega corporation of choice. And three months later, mega corporation buys the thing you were using to try and get away from mega corporation.
It's that's that, yeah, no, that they have deep pockets, and if you're producing a way for them to, you know, create neutrality, then, then it's, can be hard to maintain that neutrality,
yeah, unless you own the infrastructure, which is why I, I believe there has been renewed drive to return to on prem recently,
there's definitely, we're we're watching the cloud providers push into more and more places and compete with more and more people. So very true. I room, I don't see that trend line stopping anytime soon.
So that so I'll circle us back to the report from that perspective, right? Is, is that mean that you know repatriation is going to continue. People are going to be looking back to say, hey, I need to be able to run these things myself. How much of the cloud that does somebody need to replicate to be successfully on premises? Or on premises is a weird word. Now, self managed. I I
think it comes down to almost a when you started in it. In my opinion, certainly, there's the faction of folks that have touched and felt servers and networking and storage and have sort of that existing knowledge of what that could look like, as well as given the new technology capabilities that exist in the space, how much better I could make that than 1015, years ago. But I think there's also the facet, and I just hate trying to make myself seem like an old person, because I'm not. There's the new people.
No way. It's not true. Yes, I've
never known the physical infrastructure the space that I think are also having the advantage of bringing fresh look to this space, but I think they've always been sort of told not to do on prem, because back in my days, somebody said how hard it was and all these sorts of things. But I think to your point that you mentioned of not necessarily on premises, but could be self hosted in the CoLo. There's a number of options to provide a sort of a best of both worlds without necessarily delving all the way back into the we're gonna build our own data centers and manage our own data centers.
Interesting conversation where somebody was asking me about repatriation, and I talked to a managed service provider, so not a hyperscaler cloud, but one of the more service focused clouds, and they were, they were considering what they did repatriation, and that their customers were considering it repatriation, so if they're leaving the cloud and Moving to a dedicated VMware cluster hosted by somebody manage that. VMware cluster is managed by somebody, and they're paid. They're paying for it. It's a lot. It can be a lot cheaper, dedicated gear. There's no multi tenancy in it. They have their right. They own the whole stack in the in that case, the customer is still considering that repatriation, which was a little mind blowing to me, but I think that anything that exits the Big Three is now up for grabs as a repatriation. I still feel a little weird saying that. But is that fair is that, are we? Are we that loosely defined in repatriation,
I would say yes, in that, I think that's literally where people's heads go to was having actually a similar conversation of the inverse in that lift and shift. In my opinion. Is always been connotated with a move to a hyper scaler. But in theory, I could lift and shift from VMware to Red Hat, open shift in my own environment, or to insert my various options. So I think there's a lot of words that like that, that are built out by us for a specific purpose. And certainly they are vendors that latch on to certain terms and words for their own self interest. And I think that's why we start to get these loaded terms that don't necessarily describe what it should describe, but describe what something something of value to someone. I
How do they, how do they figure out the relative cost? Then what is, what is relative value?
Challenge is going to be okay, and I would argue for most is that very few organizations do good TCO in terms of what's the actual cost, and unfortunately, you're gonna hit with dollars to dollars. It's the same argument I have for people that are like, I wanna be able to move workloads from AWS to Azure based upon the cost difference. Like, is that really what you want to do to try and save a couple of pennies? But you'd be surprised how many times there's questions about that.
It's a cost savings can be really this is we? I mean, I get into this all the time with people about, you know whether or not you're going to save save costs, and there's very little trust that promised cost savings are going to materialize, although cloud did a good job telling people they were going to save a lot of money for you. On the other hand, there's a materialize either. So go ahead. There's
also, like, a whole business model of cloud brokers whose entire purpose it is. Like, you go to them and say, I want this amount of resources. Find me the biggest saving. And as long as you don't care which cloud it's on, they'll come back to you and say, like, Okay, this cloud provider gives you all of these resources for this much. This other one gives you cost this much, and you basically get infrastructure that, that you require, right at, at the cost that the that the broker, yeah, it's like the cloud equivalent of all of a mortgage broker, essentially,
I but that, I mean, so when I first, you know, when we were first talking about cloud brokers, you know, those were supposed to be intermediaries for all of your requests, right? The way it was originally defined was, you make your requests, I am, you know, a, w, z, and I am replicating. And this didn't work. So maybe what you're saying, where it's, you're providing the introduction, and then the really, you know, then they, there's a finder's fee, and then you're, they're out of the relationship. The original idea that I for cloud brokers was that you would talk to the broker and it would intermediate all of your other interactions. And the technical challenge of doing that was, was and remains impractical. But there were, there were companies that that 10 years ago, got huge funding rounds on that premise.
Yeah, I don't think any of that handout, yeah, understandably again, like the the cloud providers found out that they that they could bypass those kind of brokers by just changing the app APIs often enough to Make them impractical,
right, or at least to not make that work. I mean, this is, you know, I would, you know, I wouldn't want to put Martez on the spot too much, but Right, Morpheus, this is part of the business model, isn't it? Or not. Did it not work out that way? So
it, it doesn't work out that way. And those are the conversations I would often have. Would be, Hey, can I see a cost comparison while I'm deploying workloads between us and Azure and GCP? And I was like, technically, there are some things that the platform could. Show you. But the thing really always comes down to that's generally not how any of this works. In real life, you don't just pick a cloud on a whim for the vast majority of workloads that you're going to deploy. Oftentimes, there are adjacent dependencies and obviously security implications and requirements that have been specified and outlined, and you pick where you're going to deploy something based upon what makes the most sense in aggregate, not what is the cost of an EC two instance versus an Azure instance at this given moment in time, it's like, well, what about network cost and storage? And
that's why I was chuckling to myself, because the idea of your algorithm being like, Hey, I'm going to save you a penny an hour on by moving this, this instance over to Google, and then all of a sudden, your egress costs on getting the data to that instance, like, you know, astronomical and Break your cloud bill,
or the latency between between instances themselves.
Oh, my god, yeah, yeah. Just sheer amount of time to move the data, if you're talking, let's say a terabyte of data. Are you really going to hit the provision button and then wait maybe three hours? All the
broker stuff just fell apart, on, on, not even very hard things to think through. The one that would surprise me is when we did, because I built some cost, minimal cost modeling pieces into Digital Rebar, and I went and was like, Oh, I'm going to go pull cost data out of the clouds. And there is no API in any cloud to pull cost data, especially pre consumption, cost data, out of their systems. It is very hard to anticipate what something is going to cost well,
and most people don't realize it until they actually think about it and go through the exercise that most services don't show you that up front. No, gotta provision something in Asher AWS, and you provision the things you're gonna figure out how much it cost after the fact
that was, that was what I ended up finding, was that I could, once something was provisioned with still a lot of work, I could go in, talk to the APIs and pull back what something was costing me, assuming I was running, you know, there was some aggregate. There's on AWS, there's an aggregating service that produces that data for you, not even particularly free.
I mean that in my experience that the clouds do provide you APIs and or at least are the very least, an interface to estimate that the cost of what you would produce, or what your what Your infrastructure would would cost, and you can include networking, storage and infrastructure and whatnot. But the challenge is that they don't remind you that of the ancillary costs. So for example, if you, if you do a naive costing and say, Okay, I need instances and storage. How much will it cost me? And you forget the network? Well, you don't know that. In addition, if you don't have the metrics are ready or what, what your system consumes, even if it's on prem, you're still going to get an imperfect page care, and even if you do have the on prem metrics. Well, the the the actual consumption on Cloud might be different because of either different different NTU size impacting your network costs, or, let's say you're scaling to petabytes on prem and on Cloud, you're going to need to split it either into separate volumes, because they can only get to hundreds of terabytes, or you need to consider a third party solution, like, I know, like just trying to think here, like any of the sand vendors that have a cloud Offering pure net to the others? Exactly. Yeah, so, so you cannot do a one to one comparison on I mean, I, the conspiracy theorist in me, would say that that they the obscurity is on purpose, just because. It. It makes it easier to for them to focus on just a few metrics and say, like, Oh, see, these numbers are lower, and then you get nickel and dime on everything else.
I think even if you gave them the benefit of the doubt and that they wanted to be transparent, I think the complexity of the problem is really high. Yeah, also. But I mean, at some point they are sending you a bill, so they're figuring something out. But
I think it also aligns with that. Now we think this is conspiracy or not. I was just thinking about it aligns with the idea of an OPEX model more than I'm going to show you all of your cost up front. Try and identify that it, it's a bit of a stretch, but as I think more about it, it sort of aligns with that paradigm of, you know what? Just pay as you go. And I look at it for after a day, and I see so much posters.
Hope is not usually a business strategy, but I think if, if, I guess, if all the individual costs are small, I guess if you wanted predictability, you can go to reserved instances, and that'll give you predictability, right?
Yeah, the biggest lie of the cloud was that they told you that you could just turn your instances off when when the cost was getting too high.
Yeah, that was, that was a good, good misdirection. Yeah, I
mean, it started off as, what the dream of cloud bursting, and it was one of the, the major ones, I think, that never necessarily panned out for most folks, they gotta get to keep updating the story.
And I have to admit, though the cloud infrastructure has been very convenient for for on demand capabilities, okay, I need a new server. Boom. Two minutes and it's done. But that that only materializes itself as a benefit when you're starting out and after that, like if you're if you already, if you already have a mature product on prem, at least on the on the pure cost side in is cheaper, even if you have to hire people to maintain your your data center,
yes, through the cost of actually maintaining a data center, because it's now a free, you know, well provided service is, is much, you know, it's not the expertise it used to have to be, if you were trying to build a data center and maintain it on your campus and all that, right, there's you can rent that as specialized space. That's much, right? And even pre, even rack, RackN stack is now pre configured and built in. So, you know, a lot of the mechanical parts of that work is, you know, for our our customers, is completely invisible. There's still, don't get me wrong, there's still a lot of ops work to do,
and I kind of feel like cloud providers are have have recognized that that's the case and that there's a demand for leaving cloud infrastructure, and that the biggest hurdle there has been that once you bought in into the Cloud Control Plane, that is the hardest thing to Get rid of. So things like Amazon outposts and google anthos, whatever they call it, for bringing the Cloud Control Plane to your on prem data center. It hasn't seen a very quick adoption, and I wouldn't expect it to to have it, but they're still fairly well established, and I don't think they'll go away anytime soon.
I although I said in, did we talk about this. I sat in on a couple of outposts sessions when I was at reinvent, which was one of my objectives when I was there. And the it's a very expensive solution, and the complexity to get any redundancy in it was incredibly high in. And then the infrastructure itself does not allow over provisioning, so you you would, you have to buy a lot of it. So if you want even sort of and they're doing a little better by not forcing you to fully populate racks and things like that, but the control, right? Like the I sat through several sessions where they were describing needing, like, three outposts, and, you know, triple redundant links and a whole, like, there was some, it was a very expensive solution. And the use cases they were putting up the poster the poster cases, use cases were, I don't know, I'm not willing to say poster child. The poster child on all these pieces was a shop that was doing IDEs hosted IDEs for their employees, and so they were paying all this money to get a cloud hosted IDE which is like a virtual desktop. So that's a really expensive lift to get the benefit of the control plane in order to have a virtual desktop,
I can see the value of something like that In in heavily controlled environments where compliance is the prime guiding principle, like government contracts and so on, but, but yes, it is. It is a very expensive use case for what's essentially glorified Citrix. Yeah,
yeah, no, this is but I think one of the challenges in this is you, you come back to now a lack of institutional knowledge, right? We're back to, you know that that concern that you can't rebuild the knowledge or the capabilities, and you can off offload the management. That's, I mean, one of the things going full circle back to the article we posted the beginning, right? There's still this concern of Kubernetes being too complex.
Absolutely. Particularly for people migrating away from something else to COVID, is like, it's again, like, if you're, if you're going for from VMware to COVID News, your your expertise has been on servers and on storage, but likely not so much on networking or on even policy management. So, so there's a knowledge gap there, and that's a perceived as complexity, because on your on prem your network has been pretty stable until then you set up your switches, you set up your VLANs, and then you don't touch it unless it's broken. Well, that,
to me, is as much reference architectures as anything else. VMware is not simpler, and I know this very intimately because of the work we do on this. It's not simpler, but the reference architectures and the number of variables that enterprises have chosen to implement around VMware have converged to or the software itself is incredibly complex and requires a very careful setup, if you have any variation from, you know, the that that script and and you know, even patching it a week after It's been installed is beyond most, most people's capability,
yeah, it's, yeah, it's the perceived difference, or perceived complexity. My complexity, like it. We've had a similar discussion like this, like a year or so ago, I believe. And back then, my argument was that Coronavirus is not inherently more complex compared to a stack that provides the same capabilities. It's just that outside of Coronavirus, you can learn one bit at a time and specialize in it with COVID News You Need to Know. It like the whole breadth of things, to be able to use it effectively.
Yeah, it's it definitely had, you know, hits a middle ground of being flexible enough that you can add in all these pieces which is useful, opinionated enough that there is a right way and a wrong way to do things which is helpful, you know, but, but that is, that's still a more complex solution than, you know, a Docker Swarm would be, or a nomad,
absolutely. And, and I and, and I've, I've mentored a lot of people who who started looking into containerization and on on the they wanted to start directly with coordinates. And I've personally always told them, like, start with Docker first. Until you outgrow Docker like you, you will know when you need COVID is when when you're ready on until you know you need it. So until you have encountered those growing pains with Docker, just stick with Docker, because you start, you will learn the basics there first and not be thrown in the deep end,
right?
They're two different skills.
I see Docker more of a subset of the skills that need. They're needed for COVID, but, but, yes, they're different scales.
It's interesting. But I what I'm hoping to see more of on this, and I'm watching the clock when we're just about out of time, is, you know, and actually, if you remember my any my history, I was trying to do cluster ops and operations work. You know, 10 years ago in early community meetings, Jay singer de mayors actually was my co chair. And we had, we spent, like, two years trying to encourage ops conversations around Kubernetes, and it just, there wasn't a lot of I uh, there wasn't a lot of public discussion, because not very many people were running their own or and then fewer wanted to talk about what they did to run it. And then a lot of people are just using cloud, you know, still using Cloud, hosted where somebody else is managing the operational complexity for you. But that, to me, is sad, because it means that there isn't, you know, we haven't spent a lot of time doing what happened in VMware and I was on the ground at the time. Took 15 years, still, um, 1510, years. Um, but you know that refining and building the reference architectures and the these are the easy paths I you know, we haven't yet had with Kubernetes because it's so widely hosted.
I mean, I think there's, there's still a lot of activity happening on COVID is on the on the enthusiast and on server side. Like, for example, like this came across my timeline this morning, so someone decided to turn a one plus 60, which is a phone, into a coon is note, and I still see A lot of people doing their small home setups, typically either with a bunch of Raspberry Pis or equivalent small board computers or even just like bunch of decommissioned desktop like computers like Business PCs, yeah,
literally just talking to Alex Ellis about, almost exactly the guy who does cats up, catch up, about about this type of the line. The challenge is, yeah, a lot of these don't, don't this experience doesn't translate into enterprise. And that might be a topic for next week. Actually, I would love to do this as next next week's topic. Actually, I'm not in town next week, so next week isn't, isn't, is an off week as a note for everybody week after that, if it's all right, we'll talk about this lab versus enterprise. Divide, because I think that's really fascinating, um, and I'll rally the RackN team to come in talk about that.
It is likely that the divide between what's above the control plane and what's below the control plane, say,
that is also where, where it tends to polarize the users, and again, the non enterprise users, because with Docker you, you just directly manage the workloads, like, what's about, what essentially is would be above the control plane in Coronavirus. And like, other than running the Docker daemon on, maybe setting up the Docker network the first time right after that you you typically don't make many changes, unless you're perhaps like trying to run a VPN or something like that, with with coordinates. It tends to be the other way around. The people adopting it are first interested in just running a coordinates cluster. They don't have a particular workload that they want, want to run on it, and those who do want to run workers on Kubernetes end up bit end up feeling dissatisfied because they spent that much time Managing the what's below the control plane versus the previous experience with with Docker.
I'm looking let's I'm looking forward to exploring it more. I think it's a good it's an interesting area, and I know we're at time, so it's good to see some, some old names come, come back in and hope you all come back in two weeks and be part of that conversation.
Have a good one, talk to you later.
Wow, the cloud infrastructure, so continually evolves. You know, it's a moving target, the pricing, how you do things, what is hard, what isn't hard, what things get packaged into solutions, is a constantly evolving spectrum. And so we are always innovating and changing. We're always making things easier that used to be hard. That is the very essence of what we do. And it's fun to as a group, sit down and talk about a little bit and think about where things are going and where we value it, innovation. If this is you, join us. We want to hear you in the conversation. We want to be part. We want you to be part of that dialog. We talk about really interesting, fascinating things, and the more perspectives people bring, the more interesting the conversation. Thanks. Thank you for listening to the cloud 2030 podcast. It is sponsored by RackN, where we are really working to build a community of people who are using and thinking about infrastructure differently, because that's what RackN does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly, or just keep enjoying the podcast and coming to the discussions and laying out your thoughts and how you see the future unfolding. It's all part of building a better infrastructure operations community. Thank you.
