The more kubernetes you use, the more frequently you release software

Episode 253 · Thu, 09 Feb 2023 14:20:00 +0100 · 41:06 · SRT · archive.org · all Tanzu Talk

So I was down in Ghent, as us English-speaking people would say, yesterday for a configuration management camp. I think this is the third time that I've been there. It's always a fun, it's enjoyable. It's right after FOSDEM. And so there's a lot of people who go there from FOSDEM. And it is, true to its name, it's somewhat of a niche topic, but in our world, it's a huge thing. It is about configuration and release management, essentially. And then the, you know, the kind of things around that. So of course, there's lots of Kubernetes talk and stuff like that. But the, yesterday, the keynote was from Adam Jacob, you know, of Chef fame. And he was finally giving a public view into like what his new company is called a system initiative or something. And basically, I'll have to dig into this more. So this is just from seeing his talk. So who knows if it's accurate. But of course, you know, as people who get interested and obsessed with a certain area, it's another configuration management, release management thing. And he went through the problems with infrastructure as code. One of the things that he, he and his buddies in that area pioneered, of course, and not buddies, there was quite a lot of animosity. I don't know if you remember between the puppet and chef people that was in retrospect, you know, what are you going to do? But essentially, his, I think the main thing, the way that I as a, as an application developer, a Java developer who stopped coding in 2005, he was like, what if configuration management, but object oriented, right? And, and what that means is he would call them models. But he was basically like, and there's, there's a, there's a fun twist to this at the end. But what if we had models, which I would call objects, and the model was like, you know, your web server. And the thing with that is there's a, there's an API or whatever, and you tell the web server to configure itself and install itself and set it up. And it's in charge of doing that. Instead of the way that we all, we do this now is you tell it the exact

settings to do. This is kind of like a Cloud Foundry way of thinking about stuff, right? In, in the same way that you would go to Cloud Foundry and be like, I don't know, run this application. I got to go eat something, right? And, and like Cloud Foundry, because it has strong opinions runs it in the way that it runs it in the same way you would have a database or a load balancer or presumably some router. And it has a model or an object and it's in charge of figuring out how to configure and do itself. And then the fun part or the fun part is that part of what, what they're thinking of is then you would, you would just basically, you can do bi-directional syncing of this model of this object back to staging and development. So like in staging and development, you build up this model that you want a simulation, if you will. And then essentially what you say, it's kind of like a reconciliation thing in Kubernetes. You say like now make production look like this model, right? And it kind of just synchronizes up that way. But the, the, the, the fun follow on from that is like, and then what you could also do is like, you could actually have a better single source of truth, which as he pointed out is always a lie. So it could be less of a lie that you, you have a good idea of what's in production because production, these models will sync back to your, your, your development and staging thing. Or as we would say, you remember this phrase from the internet of things era, digital twins. You would basically have digital twins that are bi-directionally syncing, which like, I'm a twin. Yeah. And I'm in digital ish. Therefore I am a digital twin. So is that, is that a viable model? Is it resilient for enterprises? Can you just swap those twins out? Does, does it work? No, sadly, we're not identical. I wish we were. Cause you know, I could, you know, fudge all my exams, get him, he's, he's in IT as well. So he could take half them. I could take the other half. We combine our CVs. It'd be great, but no, yeah, sadly not. Whenever you wants to take some time off, you can just send the other one and be like, uh, yes. Uh, last week I sent that out. Yeah. I'd suddenly have a whole new skillset I could

call on. I'd be far more interesting on these podcasts if every week I came on with a different set of knowledge and you never knew whether it was me or my brother. That would be fun. That'd be a fun game we could play at the end. Which, which, which one is it? Ed one or Ed two? But sadly, we're not identical. So it'd be very obvious. I'm sure he's quicker and he's smarter than me. Anyway, I have to say on that conference thing, I don't get that. I'm sure it's just the way they'd explain or something, but you know, the whole, so I, I'm like, so if it's just sort of almost object oriented, isn't that really what Plumi is trying to do right in a code of your choice or, you know, language of your choice, make it more structured and everything and the whole thinking things, well, again, shouldn't that be what infrastructure's code lets us do anyway? It feels like one of those, I'm sure there is something clever in there and somebody explain it in more length and go in this scenario, this would work. Oh, totally. But on the surface, I'm like, I, I feel like we should do that with what we've got. Right, right, right. And, and, and, you know, to that point, like, I think, uh, also, I mean, I mean, it all seemed cool to me, right? Like that, that seemed like a great approach. And then I'll kind of, to your point, it all comes down to the actual implementation, right? Like, like as, and, and then also, I don't know what they call this nowadays, but like, so the word drivers is what I would use for the following. It's like, whether you're using like puppet or chef or like Kubernetes or whatever, I vaguely know what Pulumi is or the system initiative thing, eventually there's some code that like connects to a Cisco router and configures it. Right. And, and you're kind of like that never gets better, right? Like, like that only gets better. And, and, and Adam started off by looking at how you, uh, configure send mail, right? And there's two ways that used to configure send mail. And one of them looks horrendous. And the other one is less horrendous, right? It's just some nonsense from the Unix era. Right. And it's like, you know, if you were to manually type this stuff in, it's, it's almost as bad as like the command line for like running the JVM. It's just like, I don't know what's going on here. Right. Capital X,

just give up. Uh, and like, so like all, all, all of, yeah, all, all of this, this fancy configuration stuff as Adam also covered is just sort of like, you know, a nice UI and model on top of like some horrendous stuff underneath. So, but my point being that like, well, maybe it's better to hide the end user. This is a lot of what Kubernetes wants to do. Like, there's no reason for everyone to have to know this horrendous configuration. We should just let the experts do it, let alone going to the drivers thing, the actual manufacturers of the hardware and the software. Right. So the, uh, the Cisco people should make the drivers for how to configure stuff, which might conflict with their desire to sell you stuff, to do it easily for you, which is whatever that's, that's, that's on the business side. But I think, I think this stuff always comes down to like, uh, it has to be a good idea, which is why you spend the most time going over the idea. And then over multiple years, you have to build up a community or an ecosystem to un-open source it of people who have all these drivers and, and it just works, which is cool. They should do that. It'd be great. It, it'd be, uh, be fun. And, and then also, uh, this is, this is, uh, what always I think happens to me at configuration management camp. Uh, it's, it's at a, it's like at a, uh, a university and they have like a university cafeteria with university quality food, which is great. Uh, and, uh, so I was sitting there and I ran into our old friend, Colin Humphries, who used to work here and at cloud credo. And then we spent like, uh, me, me and his homies spent like three hours talking instead of attending the conference. So that it was, it was fun to talk with him. He's best to do things. Yeah. He's a delightful person. Well, yeah. And I, your lecture on here and there are uni or something cause you're just chatting and actually it's more useful than the lectures. Yeah. Yeah. It was nice to catch up on stuff and, and, uh, understand what his company is up to. I actually need to see what his, uh, what his, his new startup, I need to see a demo of it before I fully connect

the dots. Cause it made sense, but I need to see what, uh, what's, what's the proof in the pudding as, as they say. And, uh, what I, what I found out is that, uh, fun fact about Colin, I think he is a, a diehard, uh, uh, Cartesian. I think he kind of laid that out there at the end and he's really into Descartes and the Cartesian system of existence. But then we were told that they were closing the cafeteria and we had to leave. And as someone joked, as we were walking out the door, oh, the staff heard, uh, someone talking about Descartes and they were like, all right, it's over. You got to leave now. And Hey, I remember very recently, Colin was on the hunt for podcasts to listen to. Did you manage to secure his listenership so he can move up to? No, no. However, I did talk to several other people who, uh, I, I talked about all the various, the podcasts, the, the Coté podcast universe too. So maybe we'll have some, some new listeners that would be good. I'll have, I'll have to tell him that because I wanted to follow up on, uh, you know, the opposite of, of Descartes in, uh, in that era of philosophy is this guy, Barkley, who, uh, he had an extensive proof that we are all just an idea in, uh, the Western God's mind. Uh, there's actually, it's very, it's hard to know if there's actual physical reality, but we can know that we are, uh, a free willed independently operating at least idea. So he, he was like right there going towards like, uh, Buddhism and Hinduism. And then he's like, Nope, I'm going to take the left turn, just sort of veered off there back, back to Europe. Uh, but I'll have to send some Barkley to him. See what he, see what he makes of that. That'll be fun. Well, speaking of, see what you make of that. The, uh, the CNCF, uh, they released, uh, their most recent survey about the Kubernetes world. And it's always fun. You know, we do a yearly survey. I, I was looking over the questions for our 2023 state of Kubernetes survey, which we'll probably publish. I'm guessing if it's like last year, sometime in December. I don't

know. It depends on what we do, but, uh, that's always fun to look at, but the, uh, the CNCF survey, it had some interesting findings in it. Now, I, I think I, it's fair to say that the three of us, we didn't go to GitHub and download the raw data to do extensive analysis of it. We should load that up into chat GP, GPT maybe, and ask it to do it. But in just reading a survey, oh, well, I actually signed up for the plus thing and I would love to pay for it just to get new features. I'll send you my requests. That's right. But, uh, yeah, there's a few interesting things in there. Uh, I'll, I'll, I'll start with one, uh, which, which I think is, is, is, uh, is, I don't know. The thing that I care the most about is basically my whole, my whole theory of how you improve during doing software, you know, with the big, the big double dagger footnote of like, you know, this applies 90% of the time and there's exceptions, blah, blah, blah. Uh, like, is that basically the way you improve software is to, uh, give developers to make their releases, uh, base is weekly. Maybe daily is fine, but like, that seems a little too much, but if you could do weekly releases, what that means as a software developer is that you can, uh, basically, uh, put a feedback loop in place to learn if the features, the changes you're making to the software are making things better or worse. And then every week you can course correct as opposed to every month, every three months, every six months, every 12 months or whatever. Right. And that's the way that you can rapidly, uh, improve your software and then even find out what problems you're solving and verify that, uh, in the first place. So I'm always interested in how quickly something like a Kubernetes allows people to release software. And it looks like to greatly summarize it because the wording for this stuff, they do it a little weird in the CNCF survey, but people who use, who have more, uh, applications in production on Kubernetes, they are, they are able to get even closer to doing daily releases and

weekly releases. And in fact, uh, this is the weird wording that they use instead of just a direct percentage. They use these categories of, uh, if nearly all of your applications run on Kubernetes in production, you see basically like an almost 10% rise in the number of people who can release multiple times a day, which is like releasing multiple times a day is a little nutty. Uh, but whatever. Uh, but you know, it means that you can release more frequently now, maybe in the detailed stuff, hopefully they did define what nearly all means and maybe in the details, there's more precision there, but that's a, that's a positive finding that, uh, it, it actually helps people out. How about the, uh, was there anything interesting in your, your skimming of this summary that the, the two of you liked, how about, how about you, Ben? Ben: Yeah, I did. I saw something around challenges. So they'd asked people responding to the survey. What are the biggest challenges that you report in, uh, both using and deploying containers and getting the most out of that new ecosystem around cloud native. And it seems that the most significant barrier that folks were reporting back was the ability to get the right training and have the right skills was number one. And number two is security and having confidence that the code that they're releasing, that they're, that they're running on the platform is secure and hasn't exposed them to some bad actor in some, in some way. So I thought that was very interesting because there are two areas that we have in the terms of application platform that I work on that, that we really care about is the idea of enabling folks to, uh, be able to, you know, understand what it is they're doing with the platform, uh, in the form of, uh, learning centers that you can, that you can write and you can use to, uh, basically take hands on labs and, and, and, uh, learn more about the platform that you're using on a daily basis. And of course, security, which is something that the, uh, secure software supply chains is really

important, uh, in allowing you to deliver a more sort of secure footing for all the containers that you run, making sure that they've all got an S bomb that you know, when they were last checked and you know what dependencies they have and what vulnerabilities are in there. Just knowing is part of the answer. You know, it's not just, um, correcting any issues that you have, but just knowing that you have issues across what might be hundreds or thousands of containers is a, is a big deal. So it was really interesting to see those two things picked out as the clear top challenges that folks are reporting back because it echoes with what we hear from customers all the time. Yeah. It's always good to validate your, uh, your business, which, which no, and I think, you know, we see, we see that in our own surveys, right? Like those are the top two things every year and they trade places every now and then, but I think, I think that is, uh, that is consistent. And like, you know, you're saying we have a cube academy, cube.academy you can go to, and I think you can even do some courses without even registering. And then after that you register, I think they're, they're basically all free if I remember, or maybe not basically, maybe specifically, I forget. That's how good of an employee I am. And, but well, and to flip that on his head a little bit, is it also, um, a signal that actually it's, it's, it's too top. It's too complex. Like, like this, this ecosystem works, but it's very complex. Yeah. Yeah. That might be resulting in folks feeling like they can't find people who've got the right skillsets. They don't have the right skillsets themselves. They, they struggle to keep up maybe with a pace because we all know that the pace is absolutely crazy around the CNCF and all the different projects and the maturity levels and the, um, you know, the speed that they iterate. So, um, maybe it's also a signal that there's an, you know, there's an underlying, uh, issue around just the, the sheer complexity of the whole thing. And, and if you try and, um, you know, if your approach to

that complexity is to try and master it, maybe that is quite difficult actually. And, and maybe that's worth reconsidering whether or not you really need to be a master of all of it or whether you can, um, you know, use some extra tools maybe to, uh, to give you some, uh, higher level abstractions. Yeah, no, I, I think, I think that's, uh, that's exactly right. Like you're, you're, you're making me think that like analogously like Kubernetes is in the era of, uh, when Linux was basically like you had to make your own distro as an end user. Like I don't, I, I wasn't a Linux person back then, but I imagine there was a point before, before, you know, I don't know, there were like five or six distros in the late nineties. And like, you know, you could choose one of those distros or you could assemble your own and you'd have to make the choices to integrate it. And like, I bet there were similar surveys where they're like, Whoa, these things are confusing, probably sponsored by the incumbent operating system vendors. But you know, it was, it was no doubt an equally like a confusing thing at that point until it all consolidated. And, uh, as, as our old friend, uh, uh, Kubernetes Joe used to like to say, it became boring. Uh, and, and it was, uh, there were, there were skills in there. You're also reminding me, I don't know if, if, uh, when y'all were growing up in your neck of the woods, you, you had the GI Joe cartoons, but they had these little educational moments every now and then in the motto of the educational moment was, uh, knowing is half the battle, which, which I, I think you want knowledge is, uh, is power. I don't know what you, what the other half is maybe got maybe guile or something, but, uh, knowing the other half is the other half. Yeah. I've heard the phrase and I never knew where it came from or whether they've in turn pinched it from somebody else. So one of the things I saw, actually, in fact, I say I saw like I prepped, I didn't, I'm looking at it right now. Um, but it's an interesting one again in this sermon, but it says, so I haven't seen quite how they define it, but the CNCF end users are more advanced in their adoption and use of Kubernetes and are more likely to maintain a larger number of clusters essentially, which I find fascinating in that that discussion we

just had. So we're saying, you know, there is undoubtedly a ton of complexity in there. Um, but a bit of me would think, so the, the non end users, I assume are sort of vendors and consultancies and that kind of thing. Um, you would like to think that they were leading this charge in lots of ways. And in terms of expertise, if they're saying this is really complex, we can help you, they would be the more advanced set. But this seems to be implying it's the opposite that the end users, the people on the coalface are the guys who know all this better and are using it more in production and so on. And everyone else is catching up. Um, which, you know, I'm sure is not the case for us, but it's, it's a fascinating, I'm curious how they, what that data is and you know, what that means. I guess it just feels like a anti-intuitive to me. I remember covering OpenStack and it felt often like that was sort of vendor led. Everyone was out there saying, we've got all this stuff, we've got it working. You need us to get it going. So it's complex. And everyone else was sort of going, oh, let's do that. But this seems to be the other way around. That's, you know, in the OpenStack world, which, which I remember well, it's probably because most of the people involved in that were looking to build their own public cloud. They were, they were as, as people like to say, drinking their own champagne or eating their own dog food. And so there were practitioners there. Whereas I wonder if you looked at all of the vendors in the Kubernetes space, if they're striving to like run their own Kubernetes stuff. I don't know that that would be. And then, and then I guess the other way you would run that is to say, are there significant contributions from the three major public clouds where, where Kubernetes runs? I would assume there is. They're probably nice about open source stuff. But it does remind me of another extensive conversation I had about like with, with actually one of our coworkers at configuration management camp where like, I was trying to get down to like, what's the experience of like installing Kubernetes? Because like a lot of the discussion

around Kubernetes stuff always assume, assumes Kubernetes has been installed already. Or that like, you know, your, your IaaS has been laid down and is easy or, or is up and running. But it seems like, you know, you get in this area where like, uh, I need a Kubernetes to install a Kubernetes. And then like, you got to install that first one, but it seemed like there were good solutions, but it was, uh, it was the old thing that my old friend, Andrew Schaefer used to say, who, who, and who installs the cloud? Uh, you know, who installs the installer, uh, as it were, which, which is a little tedious to think about. It can be indeed, which, you know, that raises the, the last thing that I was going to highlight from it. And that is that, uh, there was an interesting, uh, convert conversation in the survey of what they called auxiliary workloads, which is sort of exactly what I was getting to is that if you were to separate out Kubernetes usage into applications. So the actual software that people are using, that are just running on Kubernetes, and then the stuff you run in Kubernetes that helps you build those applications. Like for example, if you are running a, an internal developer platform, like backstage, which runs on Kubernetes as, as I recall, or you're using like your, your S bomb generation thing, which also runs on Kubernetes. Like there's all these things that people run on Kubernetes as, as the, uh, the survey was trying to metaphorize as an operating system, you know, counting that up, it looked like 63% of the workloads that people run on Kubernetes were the auxiliary ones. These ones that they used to support building and governing and, and maybe even managing the actual applications. Whereas 37% of them were the actual applications. And, and again, in the summary, they didn't distinguish between production versus in staging and development, but whatever, it doesn't matter for this point, but it, it got me, one, that's an interesting observation, right? Cause it is like, that's something I've been curious about is like, uh, running, running your support stuff in your target deployment environment. Like, I guess,

I guess you, you would probably remember this been like, if I mean, you run your Java build tools, usually in Java, but you don't necessarily run all of your development process in an app server, or you could, I guess, but it's just usually like a separate environment. Your runtime environment is sometimes separate in, in the Java world or, or it used to be or not. I don't know. There's almost like, it's hard to wrap my head around, like the same thing that I deployed a production is the thing that I run all my development stack on, but that appears to be the case in the Kubernetes world, I guess. Pause for commentary. Yeah. Uh, I don't know. It's, I can't, I I've got to be honest. I can't, I don't, not sure I follow exactly. Um, the, the, the trainer thought that, but yeah, I did, I, you know, yes, I do remember, um, working quite a lot on things like, uh, web sphere and web logic and those sorts of application servers back in the day. And yes, everything build wise, you know, was all taken care of far away from production until you had this golden jar exactly on for, for months and months and months, you know, and here it is boiled down into the golden jar. And then someone in the middle of the night had to tentatively apply that to a production. There you go. Exactly. Exactly. Yeah. But it was, it was alone, you know, it was this jar on its own. It didn't contain within it all the tests and all the other stuff that had gone on before that golden jar was produced. It was just the binary, just the one thing. Totally. No, no, that's exactly it. You, you, uh, you can de-confuse my monologue there. You figured it out. The golden jar, we should, we should, yeah. Yes. The golden jar is no longer popular. You, you don't want a golden jar in your cupboard anymore. And, and so this got me thinking

about like, you know, I, uh, I have since retired from doing strategy, business strategy at companies I work at, I just talk about things, but I was thinking if this is the case, then one way you could, uh, distinguish between like, uh, you know, you could try to differentiate as a Kubernetes vendor or service, you know, someone providing, someone selling Kubernetes basically is you could do your pricing based on production versus development. Cause I would assume, I don't know if this is the case, but like there is a scenario that like, as someone who's selling, running Kubernetes, you just charge for whatever it's used for. You don't care what type of workload is on it. You just meter that it's running and you charge for that versus you could say like, oh, we're only going to charge you for production workloads. Like for development, it's all free. Do whatever you want. Right. And then effectively, because there is, you know, using this survey, let's round up the numbers around. We'll make them rounded, you know, 40% of your workloads run in production. And then let's say 60% run, uh, in development, then you're only paying for 40% of your Kubernetes usage, which would be a big discount. But, uh, I don't know. I don't know what the public clouds do, but it seems like if you're a pure software vendor, it's just like, that's money you could have made, but you're not actually losing money because you don't have to pay for anything. Right. Hence the great nature and margins on software. Whereas if you're actually someone running the Kubernetes, that's money that you are losing because you actually have to pay to run that stuff that you then are not recouping. But I don't know, maybe everyone already does that, but that's, uh, we'll, we'll kick that over to the, uh, the strategy groups who are thinking about these things. Well, look, as you said, I'm a long time Java enterprise, uh, user from back in the day and, uh, any discussion about pricing brings all those folks out in hives to rely on Oracle. Yes, exactly. Which usually means pain, uh, at some point or, you know, cash pain, should we say, but, uh, yeah, they know how to monetize for real.

Yeah. Yeah. I was just looking interesting. I found a data point that agrees. So it's purely by chance, but that issue around sort of, you know, auxiliary applications or whatever they termed it as, as I was like, I remember seeing something similar to that recently and being either a bit surprised and also kind of not, I, a bit of me thinks, you know, 30% of your workloads are the actual stuff you care about. And 63% are auxiliary. You know, that's your sort of backend system stuff that you need to do to get that third running. Um, and it was actually, who was this one's a 451 research had one. I couldn't tell you when a month or two ago. Um, and they came up with a very, very similar figure. So they had 65.2% in this year. They've got predictions so precise internal operations. Well, exactly. I'm sure they counted every single one everywhere. Um, but you know, it ends up being a very similar figure of internal stuff versus customer facing in their case, functions or data processing. Yeah. Huh? Well, you'll have to send that to me. I'll have to put it in my newsletter available at newsletter.Coté.io. I imagine it's a gated asset, but you never know. It might not be, it might be out there. Um, but interesting that that, that higher proportion, it reminds me actually, I'll, I'll pimp your newsletter here, Coté saying, you know, the whole Kubernetes experiment over seven years, all this effort, all this engineering, all this complexity, and then a third of the stuff running on is actually what you want. It's still undeniable a good idea, I'd say, but it's a, it's definitely food for thought, isn't it? How much engineering you have to put in just to run those 30% of apps you want? Yeah. Yeah. To get, to get the, uh, you know, the new infrastructure takes many years and, uh, sorting out, but yes. Yeah. That, you know, if people are interested, they should go there. This was an issue. I had an issue. I call them episodes. That's what I call them. But this was, this was a, a writeup I had last week where I was just, uh, I think I, what, what happened? I read a Stephen O'Grady thing from 2016, where he was speculating about which way Paz is going to go. And it was, uh, you know, I was thinking like, oh yeah, well, the way it went was nowhere because we spent the last seven years on Kubernetes and now we're

ready to join the path back up. So there was my extended moping about that. But if you, uh, if you go check out my newsletter, you can, you can read that. So thanks for bringing that up. That was great. That was a good segue, wasn't it? There you go. I'm getting better. Doesn't it, doesn't it make a lot of sense though? Because a lot of what we've been trying to do for years and years is reuse, you know, the idea of reuse, let's reuse something because it's cheaper to reuse it and to keep reinventing the wheel. Right. If we're running development workloads and auxiliary workloads on Kubernetes, we're just reusing Kubernetes, right? So where's the big deal? No, no, I, no, I think, I think I agree with you. It does make sense. It goes back to the, uh, the champagne dogging fooding, uh, that we were talking about earlier that like, if, uh, if you, if you're, if you're champagne flavored dog food, like is, if you're using it yourself in development, you're probably more likely to, uh, kind of understand production and make it work well there. So that's probably a good move. That has a very different meaning in the UK, but we'll leave that there. Uh, instead let's turn our minds to a little bit later on in this survey if I can, uh, where it talks about, um, the, the combination of data center and cloud architecture by organization size, right? So how big is your organization size? And then how have you sort of architected things? And no surprise here that in the smallest group where the organization has maybe one, 200 employees, um, there's a small amount of hybrid cloud use, and there's a large amount of public cloud and, uh, public cloud only. So, so that's like the biggest group, if you like, I'm on public cloud and I only use public cloud is kind of like a big group. Whereas if you get to the thousand to 10,000 range, hybrid cloud is now 63%. So almost everybody has hybrid cloud in the 1000 to more, right? Anyone more than a thousand. I find that interesting because I, I think back to a

retailer example from UK recently, this retailer came out and said, oh, we're going to put all of our workloads on one particular public cloud. And I was left thinking like, why, why would you do that these days? That's crazy because you've basically made a huge public statement that you're locked into one particular vendor. They know they've got you because you know, you're not going to go back on your public statements very easily. And you've lost out on, you know, the ability to enter some competition into the pricing to be able to move your workloads around to where they've got the better services. You know, maybe you want chat GPT because it's on Microsoft and maybe you want, you know, uh, databases are on Google or whatever. The inability to be able to move around seems absolutely crazy to me. And then within a month or so CTO is gone. So it's like, this is not, if you're not in the hybrid space over a certain size, you should be asking yourself, why not? I think it doesn't make a lot of business sense to be exclusive to one particular public cloud vendor over a certain size. There's always going to be acquisitions. You're always going to be merging with other companies. You're never going to be able to control that the way that you think you can. And, um, it reduces your choice. So why would you do that? Yeah. Yeah. No, that's a good case for, uh, realizing that you always have heterogeneous IT or at least should be open to that. You know, if only because of like, you're saying the acquisition thing, right? Like that's, there's, there's different, I was, I was in a, uh, like at one of these dinners, uh, I go to every now and then recently. And there were, there was, there were the two sides of that where there was someone at a, at a really big, uh, company, mostly, mostly European, uh, company. And they were saying they had moved all of their stuff to Google cloud, except desktop

management, which sort of like, well, that makes sense, right? Like, you know, you gotta have your, I forget what Microsoft's desktop management thing is called nowadays, but you know that you just do that. And, uh, and then there was someone else who said, oh, they, they, they, they were kind of like a conglomerate company. They acquired a lot of companies and they said, yeah, every time we acquire a company, we basically just figure out if we leave them alone or if we move them to our, you know, our thing, depending on how they're doing. And, um, I don't know, some, somewhere, it seems like the larger the company, the more likely, uh, you sort of do both of those or not, who knows? Like on the other hand, I, I was, uh, while waiting for the long line of the delicious university Flemish food. Uh, like I was talking with some, uh, some, some Dutch people about how, uh, why don't these, why do these companies keep doing things 60 different ways and not just consolidate to best practices. But I, I, I think Ben, you would advocate for, you know, five at most different ways, not, not 60 different ways of doing it, but it, you know, or whatever. Yeah. Yeah. Yeah. Yeah. But whatever, whatever you aim for is probably not what you end up with. So yeah, exactly. Well, I, I have, uh, uh, I have my next meeting is starting up here as you can hear. I'm getting, I'm getting kicked out of the room as, as I used to say in the, in the physical world. Uh, but I think, you know, I think as I, I always enjoy a survey and the last thing that I'll go over, this, this is where, when it comes to technologies use, I should really go dig into the, uh, the extended data, but it looks like, it looks like Simon Wardley's dreams, uh, from seven or eight years ago that, that next year is going to be the year of serverless. It looks like it's increasing. Cause I think, I think when you look at the technologies people use, uh, in 2020, 30% of people reported using, you know, uh, serverless slash FAS function as a service. And now it's up to 53%. So that is a huge growth amount, uh, for people using serverless stuff. So finally, uh, you know,

the, uh, those, which way does it go? I think a Wardley map, the good stuff is on the right side. If, if I remember, I forget which, I mean, here's, here's a tip, right? Yeah. Yeah. Here's a tip, at least in the Western world, the good stuff is always on the right in a chart. If you find yourself making a chart the other way, you're doing it wrong. You're going to confuse people, but you know, maybe, maybe the right side of the Wardley charts, uh, will finally be cool. Although I guess that would be in the middle and, and the, the, the left. Cause his point would be, these are commodity things that you should not worry about specializing. And that's serverless is kind of the bridge between serverless is kind of like his value line. Anyways, I should probably not speculate, uh, too much. Cause I haven't read his stuff in a long time, but serverless has gained in popularity in the, uh, the Kubernetes world. It looks like, well, yeah. And, uh, our listener anchor, uh, also, uh, prompts us to, uh, mention as well that, uh, wasm is mentioned in this survey too, isn't it? There's a, there's a definite, uh, sort of eye on the horizon at what technologies might come next. Um, not only in the sort of serverless space, but generally in the sort of container space. And, um, and wasm is, is mentioned in this survey and seems to be, uh, maturing as a technology that could offer, um, some new benefits, uh, after containers or, you know, post in a post container world, I guess. Now, now in true, I figured out this is, this is, uh, as they say, our, our primary bit here in the Tanzu talk news podcast. Does it, does any of us actually know what that is? The, the, the wasm stuff. I am getting increasingly intrigued by it. And I think I'll, I'll go off and do a little bit more digging on that, but yeah, I, I, I understand that, you know, how, uh, the sort of container view of the world is that you share a kernel and you share certain things from the sort of, uh, Linux, uh, underpinnings, but then each container runs in its own, um, secured sort of

sandbox, if you like, where the, where the actual code is, uh, it's kind of like the, the next level up from that, where actually you don't need it. I don't think you need a kernel anymore. So you can start to get much slimmer, much, uh, faster startup times and other sorts of, uh, benefits from that. But I'm speaking from a point of huge ignorance. I need to go and have a, have a, a deeper look at that, but it is very intriguing that it's coming up time and time again in, in more and more surveys as, uh, the technology to watch. Ah, it sounds like, it sounds like, uh, unikernels except comprehensible, uh, which maybe, maybe that would be interesting. Yeah. I'm like Ben, I've read a few articles on it and it just has not sunk in what the difference is. In my head, I still think it's another redo of Java in a way, as in Java was that, you know, right once run anywhere. And that was the JVM and everything. And I read about wasm and it sounds the same because I'm not a developer. Um, and it just sounds like, well, we'll do, you know, you can do away with Kubernetes. You won't need it. You'll run everything in wasm. Uh, someone put out a good tweet, probably Kelsey, who knows, um, along those lines saying, you know, it felt again, like that matrix thing of once you use it, you won't need to dodge bullets philosophy. Um, but I'm amazed by those numbers actually, you know, that they're showing here of sort of 37% of organizations, I think, end user organizations saying they've already deployed an application using WebAssembly, whereas it feels just like, uh, a lot of chatter, but not much on the ground. And maybe that's not the case. Well, they do say that, you know, many are still testing the water. So of that 37%, it might be one-offs, you know, where, where someone's sort of trying something out and trying to get more familiar with the technology. And that makes a lot of sense. I think it is still very early days. How do you deploy it? Anyone know? It's for a, you know, a Docker desktop of WASM style thing that you say, I download it, I run it. Docker desktop does now do WASM. Yeah, it was added in the last couple of months to Docker desktop. So it is a possibility. You can do it

that way. I can join the 37% fairly quickly then. And I think I can hear someone who's just deployed a WASM and it's not gone quite according to plan. That's right. That's right. Yeah. Yeah. Very true. Well, did I, did I go over my standard Debbie Downer thing about the demographics for, for the CNCF survey? I forget. No, do your Debbie Downer. Well, to your, to your point, Ed, like I, I always like, you know, the, the, it looks like, uh, in, in the, the methodology, if you read through it, they've actually got, tried to get a wider representation of just people who would gleefully, you know, respond to the newsletters and the Twitter account, which is, you know, the primary way they recruit the people who answer these questions, but they also went out and scanned. They partnered up with Dynatrace and Datadog to, uh, as they, as they, uh, say, get the anonymized data about what's running, uh, uh, out there. And I think we covered the Dynatrace stuff, uh, last week. Uh, and so you do have that, you know, you're kind of expanding beyond like the self-identifying CNCF community people. And it looks like they also used a third agency to recruit some people outside of, uh, outside of their own thing. However, like it's, it's always good to keep in mind that like, even though Kubernetes has like, definitely like mindshare and people are interested in it, like, you know, to use, um, a recent Gartner estimate, only, only 5% of terrestrial workloads run on Kubernetes. Right. So there's still like of the people, you know, all of the applications out there, there's still a very small amount running in Kubernetes. So to say that like 37% of applicate, you know, of people using Kubernetes use any technology is still a very small thing, which is not to say it's bad. It's just like, add some context to it. But as been mentioned, I think we need to go debug a few deploys. Uh, we haven't figured that out yet. The, the alarms are going off there and, uh, we've got to handle that stuff. So as always, this has been TanzuTalk. If you want to get the, the, the, the show notes for this episode, see how to subscribe, all of that. You can go to, uh, TanzuTalk.com and, uh, we'll have some

links to things we mentioned and other stuff. And with that, we'll see everyone next time. Bye-bye. Bye-bye. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.