PAS, PKS,and RabbitMQ on kubernetes

Episode 137 · 58:12 · SRT · archive.org · all Tanzu Talk

you know, it has been hot here. And I was thinking I'm probably now contributing to the problem because I have, get this, I don't know, I think in your neck of the woods and all of the neck of the woods called America, it's considered bad if you use charcoal basically for your grill. And I've done that like three or four times now, because we don't have a gas grill here. And we have a little Weber and you just, you get, you get, you get that little chimney thing and you put some charcoal in there and it's delightful. It's really, it's fun. The food tastes good. So that's probably why it was like in the, the, you know, low nineties last week. Cause I've been, yeah, we're putting a face on climate change. So you're the, you're the cause. Yeah, that's right. But boy, you put some, you put some salmon and burgers on there. Now you're talking, you put some, the earth may be dying at a fiery death, but that salmon's delicious. Put some bratwurst. Do you think, do you think with your family, you could get away with calling bratwurst hot dogs or would they, uh, would they sort of like instantly see through your, uh, your verbal nonsense? No, I have to probably be at least sausage. A hot dog would be a bridge too far. Cause I, I think, I think I have, I have successfully conditioned my kids to look at sausage and hot dogs as all the same thing. So I just say we're having hot dogs and boom, we can have bratwurst, regular hot dogs, what they call a real American hot dog around here, whatever you want, which opens up the options. Now, this is why I say when I be like you and I grow up, that's a, it's a good milestone. Well, maybe next episode. Uh, I was just, uh, at the grocery store, I got some pizzas that are entirely made of vegetables, including the crust. Now, one of them advertises itself, not only as hand stretch, but it's also purple. So I, uh, I don't know how I feel about that, but I'll, I'll have to give a further update. It's a purple, all plant-based pizza by, am I right? Yes. Yes. That's sounds like a Dr. Seuss sort of. That's what I was just thinking. Yeah. This doesn't sound like normal food, but congrats. That's right. And in this other room, I have purple plant pizzas and was it was, it was nuts. Yeah. Oh, it's great. Yeah. Walk it in my

socket. Well, uh, I think it's been a while since we've had a, a little episode here. We've got a little bit of new stuff to come through. And then I was, uh, I wanted to go over, I don't know why I need to clear my throat. I wanted to go over, uh, like we had a, a, a private alpha announcement of doing things more with a pivotal cloud foundering Kubernetes, which, which we'll get to. But first of all, I think, uh, I think it's, there's, it's sort of earning seasons for some people looks like the, uh, the public cloud business, the big three and the other ones looks like they're doing just fine. They have, uh, they have good growth rates, lots of usage. What's, what's your take on that? Yeah. As you say, I think it's all, uh, all solid. It was interesting. This was the first time since Amazon started, uh, reporting cloud earnings actually broken out that they were below 40% growth, which was at least at first, like, wow. Yeah. Like, Hey, these are big numbers. It's still like 30 something billion dollar run rate. So it's hard to keep growing that fast as you keep getting bigger, but it was at first kind of like, Hmm. And the stock took a dip as a result. Even Microsoft's earnings were down from the last quarter, I believe. And again, still, still really robust. Like these are still significant growth numbers, just not as crazy. Now, Google's reported their stuff up at a, I think it was an $8 billion run rate. And they like Microsoft, they, they throw a bunch of stuff in that cloud number. So it's not pure cloud stuff. It's also their office productivity stuff. So it's hard to figure out exactly what the cloud stuff is, but it is way up. And, uh, I don't know, to me, it was for Amazon and Microsoft specifically, it kind of reinforced why I seem to be seeing much more aggressive migration storylines coming from them. Cause I think maybe they've gobbled up a lot of the easier workloads and now they have to do more of this work to actually, you know, get these data-driven workloads, these things that are just sitting in, you know, on-premises systems. It's just harder to move them. So I'm just seeing more attention paid on workshops, on tools, on services to get people to migrate from those two. So maybe they're, maybe those are related points. It's that, uh, that platform of productivity. I think I saw some new phrase

for that, uh, recently, you know, the, the idea of, uh, when, when, when the mainstream people, the bulk of your, you know, hopefully multi-decade top line revenue, just start buying stuff from you. I forget what that phrase was though. Yeah. I saw another, uh, uh, and some, a financial analyst made some statement that, uh, Microsoft's cloud money or revenue is now equal to its on-premise revenue, which to your point that you were just making, that includes, uh, SAS and IAS, all, all the sort of cloud stuff. As I was joking on my other podcast, I'm not sure that includes Xbox live revenue, but, uh, you know, whatever, or being, but still it is, uh, uh, I was, I was, as I'm forever doing, working on this, uh, I don't know, either book or a long PDF I've been messing around with. And I found myself writing, uh, up an example of public cloud as a, uh, sort of the term disruptions always a problem, but as sort of like a strategic, uh, thing to look out for. And, and it is, uh, as, as I was writing through it, I was thinking like, I'm pretty sure of all companies, no one would have guessed back then that like Microsoft would figure it out. Like they were, uh, I even went and searched for a company, but they, I mean, for a company for a write-up of this, but most people at the time were like, Hmm, not looking good. I know they were writing the company off and, uh, yeah, I mean, they, they really, uh, like, like other companies succeeding in cloud. They really, uh, surprised people I think, and, uh, have, have more than figured it out. They've gotten very good at it. Right. Yeah, no doubt. And, and to that also, I think, uh, I forget the exact date, but the, uh, I forget what they call it, but the, uh, basically the Gartner public cloud magic quadrant was out with, uh, I believe it has just six people in it. And by people, I mean, companies, uh, it has, of course, I think if I remember, it basically goes Amazon, Microsoft, Google, and then there's like, uh, Alibaba is in there and I forget the

other two. I should probably remember. Oracle, Oracle and IBM. Yeah. Yes. Yes. But, but it's, it's a pretty, if, if, uh, it's, it's a more or less sort of like linear line, uh, of things going on there. But I think more importantly, uh, you know, the, the, my sort of thinking of it, one is like, there's only six vendors, which, which is kind of interesting. And, uh, and then two, I mean, it is thinking about of all the like cloud services that are out there. And then also the huge basket of things that each of those clouds does, especially the ones up in the, uh, the leader quadrant, the up and to the right, as they say, uh, it's interesting to kind of like just jam them down into like one data point. And granted, I'm sure there's other magic quadrants that go into like, you know, machine learning and hosted storage and stuff like that, but that must be quite the Herculean task to, uh, reduce down what, what must be rows and rows of spreadsheets into, uh, just a simple plot of six. Yeah. Yeah. I used to fill this out when I work for a, an IS provider who used to show up on the magic quadrant, alas, no longer, but you know, it was like 170 question questionnaire that would take forever to fill out. But there's a ton of research that goes in behind this. It's not some silly pay for play sort of deal where I know if you pay a lot, you show up in a magic quadrant. If you did some of the people in the niche section would be much higher. It was just based on who pays a lot. So I think it's interesting to see. Now I did look at the report. I have it up right now. Uh, nobody was dropped or added this last year. So it was this lonely last year too. I guess this used to be such a kind of a Superbowl moment in the IS space. Cause everyone would be like, Oh my gosh, let's see who it is. Everyone jockey for position. Now I actually missed it. Like I noticed that the next day that this came out. So it's just much less hoopla. I think because the markets kind of coalesced around three big providers and then three interesting, but kind of going to be tough to push up to the leader quadrant providers. And the report's really good. If you're a Gartner subscriber, you honestly should, you should dig

through it because they have some really good strengths and cautions for each of the providers, even for Amazon, even for Microsoft, even for Google. So they're really worth looking at, right? Cause it's hard to sift through all the noise. I thought they did an admirable job trying to do that in this year's report. Hmm. Sounds like a fun PDF. Good. It's a, just get a cup of coffee or it's really hot for you. So it'd be just like a lemonade and read through it. Yeah. Yeah. I was, uh, I was, uh, I've, I've been signing some books to send to people or, or as O'Reilly likes to call my hard effort reports, uh, as, as you well know, I believe. Uh, and, uh, I, I've started writing in them, uh, I, you know, I hope this is helpful if only as a sleep aid, which I think is, uh, you know, potential thing that, that reminds me and not, not that I, cause I, I share your sentiment about those writers, but I have been like, I like to print things out, uh, when I'm writing bigger works, just so I can kind of see everything and mix it together. It's just easier and distraction free. And I have come up with a, uh, uh, a thing to do with scrap paper. Now don't tell my kids, but every now and then they have a drawing and I just take a picture of it and use it for the falling as well. But you know, when you've got that charcoal chimney, you got to put some paper in there to like start it up. And so I've been saving all this scrap paper, uh, you know, to do that. So I feel like, you know, I'm killing the environment, maybe 2% less is, is what I'm going for right there. Adorable. Yeah. That's a good review. Well, meanwhile, uh, speaking of, uh, uh, uh, lots of, uh, different wingdings and stuff going on in, in the cloud. What's, what's the, uh, the event bridge thing that Amazon came out with? Yeah, they announced this a week or so ago at one of their, uh, summit events in New York. So this is their service. Well, they bid, bid it as a serverless event bus. And so you've already might say, well, they already have SQS. That was, I think the first Amazon service back in like 06 or 04 or something like that. That's their queuing service. So what

is this? So this is really meant to be kind of message routing for SAS services, for Amazon services, kind of a backing plane for event communication. So Microsoft has something kind of similar with Azure event, uh, event grid tech like that. But I think for me, this continues to, to reinforce this idea that you're seeing much, much more attention paid on the venture of an architecture kind of fast data processing. I have a blog up on the pivotal blog from last week or the week before on kind of speeding up your data processing. So it seems like the cloud providers are obviously trying to help encourage that pattern, not just, Hey, let's have a bunch of synchronous communication between things and batch processing. Let's actually do decoupled, but event based communication. So this seems like a pretty nice service. It's generally available now it's available in a bunch of regions. Uh, so I think it's going to be one that I want to play around with and see what it actually does, but it seems like another push forward for a venture of an architecture. Yeah. Yeah. You know, I, I, I, uh, despite having read it and even tweeted it, I forgot about that, that you wrote, uh, you wrote that post up there, which I thought was a great overview of, uh, what I mean, basically changing over your thinking and, and even a little bit of your coding to having an event driven architecture, which, which seems like, you know, I don't, I don't, uh, delve into the old, uh, programming books, uh, like I used to, like, I think you do probably, but, uh, I mean, that seems to be the dominant like way of thinking about architecture nowadays, right? Like, or, and by dominant, what I mean is like what everyone talks about, uh, which hopefully eventually translates into, uh, actually doing things, but it seems like the recommendation is, uh, you should do your stuff in an event, an event driven architecture, or, or am I, uh, am I reading the wrong, like buckets of excitement? No, I think those are the right buckets of excitement. I think, like you said, and I think I quoted in the piece that a lot of people are saying they want to do it. The number of people actually doing it is not nearly as big. And I think what's, what's tricky and we have to do

a good job in the tech space of this is like buying Kafka does not make you event driven using Amazon, you know, the AWS event bridge stuff does not make you event driven. Like you have to architect for it and you have to rethink how you process data and how you think about this stuff. So there's no shortcuts here. It's actually a kind of a big architectural change. So I just want to make sure vendors don't accidentally pitch magic bullets here as if you just plug this thing in, everything's just events and you're processing it. It's amazing. You can do some horrible things using things like rabbit and Kafka and things like that. So don't do that. So it is, I think a dominant talked about pattern. I'm not sure everyone knows exactly what it looks like yet. And we're all learning together. It's like to use our old friend, not that she's old, but has been for a while. Friend Bridget's like saying about Kubernetes, right? Like buying Kafka is not going to fix your bad culture, so to speak, your bad architecture. Or maybe it was some good point. Anyways, that seems like a deep well for people to start writing up like and not just like the theoretics of what it is, but actually like what are the practicalities of moving things to that way. And like, you know, if I wanted to book an airline ticket, what does that look like? Or book a rental car? Man, have you rented a rental car recently? There's high variance in the quality of experience across companies. It's a, yeah, there's, there's a, there's a lot of opportunity there. Yeah. But to your point on a guidance and stuff, I know I've been tweeting a little more about this stuff lately. There've been some good articles lately, like things I've learned about, you know, my failed adventure of an architecture and things like that, because now people are doing it. And so they're starting to see like, Hey, this pattern I brought forward from enterprise service bus, that does not work in this pattern. Or, Hey, we were accidentally using our event broker as a database. Hey, don't do that. Or things that people are learning. So I think that's great, right? We're getting past the hype a little bit and now more into, Hey, I've tried this. This was not good, or this was great, which is hopefully the point where enterprises can start paying real attention.

Yeah. Well, also speaking of old friends who I think maybe are a little older than Bridget, I should go check the math. Uh, red monk also came out with its, uh, its language rankings. They do these like quarterly now, if I remember, right. Or, uh, it's not annual. I don't really remember anymore, but anyways, it looks like, uh, you know, the usual, the usual things, uh, came out languages that begin with J still very popular. You got your, uh, JavaScript, number one, Java, number two, Python, PHP, and then C plus plus and C sharp. Now, now would you say C sharp is synonymous sloppy as it is with that net at this point? Yes. I mean, I don't think a lot of people are doing VB.net or F sharp or some of the variants. So it's the dominant choice. I know I asked this every now and then, but do you, uh, do you MVP types? Do you get all upset when people just say.net programming instead of something more precise? I mean, maybe not you, you're pretty laid back, but like, is it, is it, do other people get all, you know, like antsy? I don't think it burns up the news groups or anything when people say that that's a really dated reference. Okay. No, no. Was it, was there a name in the, uh, the.net world for that, uh, that yellow blocky character with the, uh, the round head? Uh, the channel nine guy. Yeah. I think he's the channel nine guy. I don't think his name is like Phil or anything. That would be great. It's Phil. No, I love like, you know, as an aside, I love pets with human, like normal human names. Oh yeah. That's my favorite, like a cat named Matthew. Yeah. Or, or like, I think my favorite human name ever is Larry. That's my dad's name. So yeah. I mean, if I like Larry the hamster, that's brilliant. Yeah. Or, or, you know, to use a, I don't know if you listen to that, uh, my brother, my brother and me podcast, but they, they come up with some of the best common human names. And I think one they've been using a lot recently is Ron, uh, which I think is great. It's like their common stepdad name, Ron. You just have like a little Yorkshire terrier called Ron. Everybody's

going to love that dog. Uh, exactly. But you know, I, uh, you know, I, I didn't review the methodology, uh, but typically what they do is they do some analysis of like a GitHub and, and, uh, and stack overflow and a few other sources, but you know, it's, uh, I think it's a good proxy for what's going on. Excuse me. And more importantly, I, I've, I, you know, I've yet to see an animated chart of all their years of data. Maybe they have one for clients or whatever, but I think, I think more importantly, what's interesting is just kind of, uh, anecdotally keeping up with the, uh, the, the change year over year or whatever the time period is. Because for example, I remember, um, they were actually like quoted by Apple many years ago when they pointed out, as you say here, as you see here, that Swift, uh, uh, rose above objective C like very rapidly when Apple shifted over to that being, uh, an iOS language, which, you know, if you think about it is actually pretty remarkable that a brand new language in a, well, arguably gigantic niche, uh, in, in a, uh, a niche, uh, became popular and supplanted another one that quickly, or I don't know, maybe it's not because it was such a niche controlled by one vendor that it was easy to swap it out. Who knows? Uh, but as another example, it's sort of like, as I joked, languages that begin with Java tend to stay at the top, uh, over time. Pretty remarkable. I mean, there's some other things that, you know, again, language rankings aren't going to change a lot quarter to quarter or half year to half year, however long they publish this, but TypeScript, which is a super set of JavaScript that Microsoft created for type safety, that thing keeps climbing. So it's been going up from, I think number 26 last year, it's up to 12. So that's actually moved or, uh, it's moved up a lot. I don't think it's that high, but it's continuing to move up. It's actually number 10 now. Wow. So that's moving up a lot. Go has kind of stagnated just a little bit. It's down one. I think some people were thinking that go might be the next dominant language and it's just kind of hanging out there comfortably at like whatever, 16. But as you say, JavaScript and Java have just dominated the first two spots for years

on these rankings. I think for most of our listeners, what that takeaway is, is these are safe bets. You know, these other ones are also safe bets. People using Ruby, that's still number eight, right? C sharp still number five. Like these are mature, stable languages. You'll find skill sets in the market. If you're a developer, you should learn these things. So it's always good to me to look at these sort of lists and not fall into hype of, Oh, Kotlin's everywhere. It's cool. It's number 20. Everything's not being written in Kotlin. Some stuff is so relax. So continue to use the big languages and you'll be set. And your buddy, Phil has been working hard on PowerShell there at number 17. There you go. Climbing the ranks. You know, I, I've never seen all the people joking about like, don't use shell scripts. They should start referencing the, uh, the red monk thing where they're like, look, shell is number 14. Why is it on there? Like, you know, more popular than R and go, which, you know, someone should have like the crying emoji on a slide or something. Or I don't know, maybe shell is awesome. Who, who knows? We should ask Phil. He might have some ideas. Yeah. Larry's got some input. Larry, Phil and Ron. Now there's four, four horsemen to the apocalypse, right? This is, this is probably my annual atonement that I think the first year I was at pivotal, I wrote a, a piece about the three horsemen of the, uh, the digital, or I might've even said probably by that time I was saying horse people instead of gendering it, uh, horse entities. But, uh, you know, there's, there's three, not four. There's good. I should revisit that again. The, the three horsemen revisited horse. Yeah. We're going to finally add the fourth. That's right. Everyone's been waiting for you to do this. We'll add the fourth. It's Phil. Uh, it's very non-threatening. That's right. Uh, well, so, you know, speaking of news, I think it was, uh, was it last week if I recall or the week before anyways, you probably remember precisely because you, uh, you actually do real work around here, uh, involving this kind of thing. But we had, uh, we, we had an overview of, uh, uh, essentially, uh, that we have, uh, I guess

you could call it a private alpha. I guess that is what it's called of running, uh, the plat pivotal application service or paths on top of, uh, Kubernetes. And essentially what most people think of pivotal cloud foundry, having, uh, you know, the direction of trying out running all of that on Kubernetes. Uh, I guess arguably you don't really have Kubernetes running on Kubernetes, but crazier things have been known to happen. Uh, but anyhow, you want to give us a, uh, an overview of the gist of that, that announcement? Yeah, there's been a few things bubbling up here for a while. And again, to some extent you need the history lesson, because if we go back, I mean, any, any person who knows anything about this space kind of understands some of the origin story of PaaS, P-A-A-S, right? Platform as a service. It was Heroku and Google app engine, super powerful, very opinionated, only ran as public services. Okay. Cloud foundry comes out PCF ships in 2014. This is before Docker existed before Kubernetes was even an idea. And so the whole idea was, Hey, let's simplify what it means to build, run and wire up stuff, right? Build all your package, all your stuff, get it deployed, stage it, hook up all the observability stuff, wire it into backing services, do all that in 25 seconds. So a developer doesn't have to open up 14 tickets to push an app, game changing stuff, right? Since then, sure. Things like Docker come out. Cool. PaaS, pivotal application service, part of PCF supports Docker. Kubernetes comes out. All right. It's a little different ballgame there. People kind of putting platforms on top of that. IBM started some work on something called Irene. We joined that project earlier this year, been contributing a ton to it. So the work that we're shipping now in PaaS says, okay, that orchestrator that we had built into Cloud Foundry called Diego, we had already evolved once, right? This is the second orchestration change to Diego. This would be the third into Kubernetes. And that thing just runs all the app workloads, right? So Diego does that, does it for Windows, does it for Linux, supports all sorts of very sophisticated things that were part of making Cloud Foundry awesome. So now the key is, all right, that's a big commodity at this point.

The orchestrator is a commodity. How much should we invest in that? Kubernetes has matured to a great place. It's complicated, but we can, and we can make it easier to use. So that was kind of the decision to bring that into kind of the Cloud Foundry world and PaaS saying, let's swap out those orchestrators. Let's bring Kubernetes in. Let's tap into an amazing ecosystem, much more extensibility than what Diego had. And Kubernetes now is in a great place because it does support Windows as of the last release. And it is stabilizing some of the custom resource definitions and other APIs that have been evolving in the platform. So it's a good place to bring this in. 12 to 18 months ago, honestly, I think it would have degraded the experience of PaaS a bit because it didn't have some of these things our customers expected. Now they're there. Awesome. So as we bring this in, as you said, it's a private alpha. People can try this out. You can push apps. You can do HTTP routing, hookup logs, scale apps, all sorts of basic things. Over these coming months, we'll add more things around testing this thing at scale, supporting all the TCP routing, supporting more than vSphere as an IaaS. Because this opens up some cool opportunities, right? I could drop PaaS now on a public cloud Kubernetes, you know, in the future. I could do some different things where I could take advantage of Kubernetes being ubiquitous. And now PaaS becoming the better interface on top of it. Because as a developer, I really don't want to write a ton of YAML. I don't want to configure DNS. I just kind of want to push my code and have it packaged up for me and run successfully on a great layer. And that's what PaaS does. So I think this opens up some cool opportunities. As you said, private alpha, people can request and try this out right now. We've already got people deploying it. It's exciting stuff. It's another cool part of the evolution, which I think gives new life to what an application platform on Kubernetes is going to look like. Yeah. And I think as with a couple of other parts of the news, it opens up, well, for us, but also people who want to try this experiment of running things on top of Kubernetes, essentially. So for example, we have, I think this is the only one we have at the moment,

but we have a basically RabbitMQ for Kubernetes that you can install and run and have managed on top of, it's just PKS, right? Not just Kubernetes in general. Or is it Kubernetes in general? The point is it'd be Kubernetes in general for all of these. So we're going to make sure they run great on PKS, but they should run on all of them. Right, right. And so that seems like a desire that people would have. And certainly, I think, I don't know, as we and me and my other podcasts and other places discuss a lot, over the past couple of years, much of the discussion is about Kubernetes itself, as I guess it was historically when Linux was coming about, right? It seemed to be, there's a lot of Linux talk. And somewhere I lost my reference card about NetBSD and FreeBSD and Linux and all that, whatever. But increasingly, as some infrastructure technology becomes more widely used, you sort of move the discussion up the stack and you wonder about, as I used to joke about it, you want to be more than just a blinking cursor of infrastructure ready to use. So I think there's a good opportunity both with PAS or PAS, as we say, and also with RabbitMQ and we have a build service as well. But looking at those things and experimenting with, does it make sense? And what are the operating, what would you say, sort of procedures? And I don't know, how do you fit in the idea of installing stuff and running stuff on top of Kubernetes instead of on its own, if you will? Yeah, to your point, the blinking cursor is very uninteresting once you get it going, right? So if all I have is just a Kubernetes running or a Linux environment running or even EC2 running and Amazon, like, so what? So how do I get my code there? How do I run it? How do I do ops? How do I do continuous delivery? Like, that's the stuff, right? That's the stuff that goes to business value.

So in this case, when I have a great Kubernetes platform, cool. Now, how do I get code there? How do I run that stuff? How do I run the right types of data workloads or app workloads? How do I do day two updates to container images? Because gosh, if I struggle to update 10,000 VMs, what am I going to do with 50,000 containers? Like, that's going to get worse. So what is my day two story like? Are there new sort of workloads I can run? What's this public and private consideration? Can I actually have any consistency across all the public clouds and my private stuff? These are all fun architectural questions. It seems like people are asking. And if I can have some consistency across those, thanks to applying pivotal opinions to not just PAS, but now things like a build service that would just run on any Kubernetes and take your code and turn it into a container. And when there's a change to something in that layer, maybe there's a JVM bug. Maybe there's a OS Linux defect or vulnerability that build service can automatically patch those and have you with a fresh container. That's a cool value add that this doesn't come natively on those platforms. Same with things like pivotal function service and running actual app workloads that are short-lived and long lived, or as you mentioned, Rabbit. So I think now we're having these conversations about how do I make these almost infrastructure layers like K8s, which are kind of dissolving into just ubiquity. Okay. How do I turn that into something that makes it easier to add value? And that's, I think, what we're in right now. And it's this race to see who can make these platforms the most usable. Who can valueize the best, the most rapidly. So, yeah. And you went over this briefly, but let's zoom in or double click. Or what do the kids say nowadays? You're in a lot of meetings. What do they say when they want to double click on something? I don't know if I'm in meetings with kids. I mean, am I swiping to zoom? Like, I don't know what the reference would be besides double clicking. Yeah. Yeah. Let's, let's swipe. Or whatever. Pinch to zoom. Pinch to zoom. Okay. That's good. Let's pinch. Pinch to swipe. All right. Well, you should take a poll around the office over there in Seattle.

Do people say, what do they say when they want to, they want more detail? Probably that. They probably just don't say corporate speak. K8, can you tell me more? All that, all that, all that like business BS, uh, stuff back, back when we were kids, it's paying off, which I, I don't, I don't like, I liked all the BS. So poetic. That made us feel important. Yeah. Yeah. It's our secret language. You know, you can't, you can't tell the kid, the kids that, you know, you don't want your kid coming up to me and be like, dad, I think we need to double click on you calling this a hot dog. That's right. I'm going to double click on the salad choices. Yeah. I mean, I don't want to hear that from my 10 year old. Oh, this reminds me while, while we're on nonsense again, and then I'll, we'll emerge from it. What is your position on, let's say you take a zucchini or a cucumber and then, and then you core out the outside. So you just kind of have the edges. Are you for or against, or have some, uh, some over conditionalized strategy around that? What do you do with the edges? Well, you, you eat that part. I, although I, I like the, the, the unexpected way you were thinking is someone is going to eat the core. I'm just cutting out the middle of it. I'm just eating like donuts of zucchini. I, you know, cause I, I had, uh, uh, the Albert Heine here, I guess all grocery stores are like this, but you know, it's a big, big Dutch grocery store. They have tons of prepared food. And because we now, I now go to the grocery store every day or every other day, I often buy just prepared food. And they had one that was just like, I don't know, ginger chicken. It's, it's in Dutch. So I don't actually know what it is, but the zucchinis they had were these, these sort of like zucchini crescents where they dig out the middle. And I, and it made me, it reminded me, I see this every now and then. So I've been asking people, uh, what they think about it. And so far, you're the second person I've asked the first was my wife. And the answer is generally just a blank stare. Uh, yeah, I'm, I'm tilting my head like a cocker spaniel right now. So I'm trying to get my head around this. It's a regular Ron reaction. That's totally it. Yeah. All right. Well,

maybe, maybe next time if, if, uh, listeners have some opinion, I want to know about Crescent zucchinis and cucumbers, hollowed out cucumbers. Yeah. Yeah. Something we can, anyhow, back to, back to, to double clicking, zooming in and coring out, uh, tell us more about the build service. What's going on with that? Yeah. So this is neat stuff. This is, uh, using cloud native build packs, which are part of the cloud native computing foundation. So that's cool. So the idea here though, is, you know, if I have this Docker file world where people are potentially building up Docker files to describe what their container looks like, right? The Docker files made up, not of just a, you know, my app code, but there's layers that represent things like the app server and the OS and other pieces like that. So all of that comes together and gets munged together into a container that then gets deployed into an orchestrator like Cooper daddy's. So how do I build that? Am I having a developer who is saying, well, here's the base Ubuntu image. Here's the app server component. Here's the JVM version of the node JS app base image. Here's my code. Here's some other layer. Now you might be using a Jenkins or a concourse or other things too, to assemble things. And you're not hand crafting your Docker file. And that's totally fine. But build packs have been super successful with this, right? The whole CF push, just give me my code build packs, containerize it for you. So how do you deconstruct? How do you pull that out of being only a cloud foundry thing and say that a lot of people could find value in automatically packaging and then making it really easy to update an application container? So that's what the build services. This will run on Kubernetes itself. It's already available now again for people to try out. And so being able to take this thing and have these build packs, take source code, assemble it, turn it into a container. And again, because of some pretty cool technology we've put together and worked with others on, when there is a change, so if there's a change to the build pack, and to be clear, build packs are updated every seven to 10 days. I mean, go look at the Java build pack, go look at the node build pack, Ruby build pack. Updated all the time because there's vulnerabilities, new versions supported,

lots of cool stuff. So always iterating. So with the build service, when I update, let's say the Java build pack, we can automatically then rebuild those container images to use the latest build pack version, which brings in all the latest JVM fixes any, you know, patches anything. Developer doesn't have to go rebuild the container. Now you have this fresh artifact in your registry that can just go to production. So it handles this sort of day one building day two updating story, which is somewhat unique. Run this anywhere, run this in the public cloud, run this on your own Kubernetes cluster. Right. Just make it smarter and simpler to assemble code into containers and not have to manage all the day two stuff. You know, that, that's, that, that touches on another, uh, as, as, as I was reading through all this stuff and all sorts of other, you know, that there's always not always, there is frequently, uh, uh, a little bit of news from the, uh, we'll call it the pipeline world, the continuous integration, continuous development world, little investments here. And as you were just going over stuff that we and other people do. And, uh, I guess this kind of thing might be obvious to other people, but just as, uh, there is sort of a need to, to discuss the basics of like event-driven architectures. I feel like when it comes to IT management to show my, my old foginess, there isn't quite a thorough understanding of like managing container registries and like how, how vital that is to the entire process. Like, you know, back, back in the olden days, we used to obsess over, uh, configuration management databases and like why that was all important. Right. And, uh, I don't know. I haven't come across any like long, boring, uh, like sleep aids when it comes to a registry write-ups and how to manage them and what to do with them. Yeah, that's a good question. I'm just not sure. And again, you may have done this in your, your trails around enterprise IT, but I don't think a lot of people adopted the gold image VM story where they would actually bake a VM and then they would store it in some sort of repository and that's what they would push out. They would never, you know, patch VMs. They would just do gold images. That's more of a container model. So if you didn't come

from a gold images mindset where you were always kind of baking and updating these sort of base things and you were just thinking of like, I build a VM, I patch it occasionally, it lives out there. Like containers don't really work that way. I've got to kind of rebuild it and redeploy it. So it seems like if there was a, if you made that leap and you pass this sort of gold image story, there's probably things to learn here to make sure you don't accidentally end up with a bunch of just dusty old containers running because you have no upgrade story. Yeah. Yeah. Yeah. I mean, there's something, uh, maybe I should investigate this. I'll add it to my stack of things I'll print out and, uh, light, light, light fires with, and then cook supposed hot dogs on as I drafted out. But there is something to the idea of, I don't know, layered versus container things. And, uh, you know, I think, I think a fair amount of configuration for a long time has been more layered things with, uh, with automation tools, you know, from the chef and puppet school and things like that, that would basically layer out and then enforce drift from, uh, your desired configuration, which, you know, technically I guess happens in container management, but there's, there's something much different about it than a, uh, continuous, uh, as, as, as we say in another context, repaving of things. Uh, but anyhow. Yeah. I don't think, I don't think you have a choice in a container world and someone can correct me, one of our listeners, but if I have a container running, I can't patch that thing, right? I've got to update the image and redeploy it. Yeah. So it's a whole different mindset than that chef puppet Ansible salt sort of, as you say, prevent drift by just continuing to reinforce a current state. I don't think that that works. So it's interesting, right? As you say, I think there's registry best practices that maybe haven't made their way all the way out yet. And we're all learning on this together again. Exciting registries. Exciting. Well, did I, did I, uh, did I miss any items from, uh, specific items from the, the announcements? No, as you mentioned, also, uh, the RabbitMQ stuff's interesting. We, we highlighted the service mesh again, which covers multi-cluster ingress, which is important for Kubernetes as the, the idea we've been promoting

pivotal with PKS is, Hey, have many small clusters, right? And other folks have talked about that as well. You don't want the mega cluster that everyone's depending on. There's a, there's a risk there since so many things still require root access. It could potentially cause trouble. You have things, if they cause problems, it could take down a bunch of other users. So if I have a lot of clusters, okay, that's a good pattern. How do I upgrade them? Cause Kubernetes is updating all the time. And then how do I handle ingress? Cause it's cool if I can deploy my app, but if it takes another two weeks to get the network routing done, am I really continuously delivered? So with something like the service mesh, being able to have that multi-cluster ingress as an automation and more, you know, have that stuff just taken care of as part of a deployment process, that's pretty cool. So all of those were part of this. Again, many of these are about deconstructing some of these really value added things that were only in PAS and cloud foundry and saying this should be available to more platforms. The pivotal opinions around how you build code, around how you run applications, on how you do networking and automation that should be available to lots of places. Cause these opinions are valuable, especially as we're all trying to figure out this new world. Yeah. Well, you're reminding me there's, there's a, I don't know if you came across this, this fun post from, uh, Jesse Frizzell, but she has, she has an almost, uh, uh, very subtly absurd level of like, let me explain Kubernetes problems in business terms. And, uh, you know, it's basically just like your system doesn't work. And, uh, and then she goes down some security rat holes, but it is, uh, you know, it's, it's a, it's a good writeup of, as you were saying, like, there's all these things that seem, um, overly nerdy. I mean, I guess that's kind of comical to talk about when it comes to like container orchestration and management, but that seemed to be in overly specific, like worrying about cluster management, but she does a pretty good job of, uh, kind of summing up why it's good to be overly nerdy with these things. And then also it's always fun to see, uh, people kind of, uh, write in funny ways about, you know, executives like, and, and then,

and then your shareholders get upset. That's right. Yeah. Well, that's why I mean, I had a question here for you. I wanted to ask you Coté, cause I mean, I think on the, to that point though, and I'm reading a good book right now, project to product, which one of the points that the author is making is, yeah, it's really good. And this is this kind of disconnect between it priorities continually be and the other lines of business. And that we're, we're not talking about the same stuff. We're not talking about value the same way. So, I mean, and an honest question to you, have you seen a business oriented case for why to implement something like Kubernetes in the first place, or is this more about, Hey, it's it infrastructure optimization. It's fuzzier stuff on better management or delivery, or do you see that bubble up to, Hey, here are customer facing outcomes that will come from us deploying this. Do you see, is it just infrastructure or are you seeing actual business case coming for that? Well, I mean that I'll, I'll take business case to mean two things. One is like, uh, as it says a business case, I don't, I don't know what the case would be. I guess the case is an argument to do something, but as, as, as you were alluding to sort of saying, like we have this, uh, this, this business outcome, which is to say apart from it, nevermind if you're in the tech industry, that's a different, different thing. Uh, or I don't know, a frustratingly fractalian recursive thing. But, uh, yeah, like if, if you're just like, uh, I would like to hold on to revenue share in this car rental business. And so therefore I need to make the user experience better. Like it's not so much that like, you're going to say like, and therefore I must install Kubernetes or even, and therefore I need to use a containers or even the, you know, therefore I need to do container orchestration. I think. So, yeah, I mean, I don't know. I don't really come across like that baldly stated, uh, sort of thing. It's more of like down in the weeds of like, and therefore I need to have these abilities to do things quickly and like, blah, blah, blah. Right. Like you want the capabilities that something like that provides. And if as, as, uh, seems to be the

case, like that's, that's, uh, one of the, if not sort of the emerging standard for, uh, managing infrastructure, then it's sort of like, you know, saying, uh, I would like to, uh, write something down and then, you know, it's not like you just made a business case for a pen or a pencil. It's just sort of like, that's how you do it. And then, so very quickly you get into kind of the second business case, which is like, I need a pencil. Uh, and then you go out and you kind of like make a business case for which pencil you should need. Like I was, uh, I found out you can go here at the, the, I'm going to mispronounce it for all the Dutch people out there. So I apologize, but you can go to the, the, the Rijks museum and, uh, the big museum here and they have a library and just anyone can go in there and hang out in the library and get a library card. So I like to go there to do work. And so don't tell anyone, but I thought I could just go in there to hang out and do my work, even though I wasn't actually doing research. Um, but I took out my, uh, my, my notepad and my pen and the guy came over and he was very nice. And he's like, Oh, you can't use ballpoint pins in here. I guess presumably cause you might leave an indelible line on something. And so he gave me a pencil and he gave me a very nice pencil. One of those, you know, one of those pencils that doesn't have an eraser. That's like, you have to sharpen with like a knife or something. And, uh, I was using it and this is probably like an eight to $10 or Euro pencil. Cause it's for artists. Right. And like, if you were doing the business case, you just wanted to jot down some ideas why you're out buying a purple pizza. Uh, like, you know, it would be a bad business case to buy the $8 pencil when you could probably buy 50 pencils for $8 that were pre-sharpened and had erasers. So, you know, once you need a pencil, uh, you make a business case for sort of like, I guess you would, I mean, I don't know if that's price or performance or just like sanity, but the business case, I think evolves into more of, uh, let's not overspend, uh, for, for what we need. And, you know, I I've seen over the years, I've seen business cases like that.

It's, it's, um, you know, as a software vendor, those are not always fun business cases to play into. Cause you're basically just, uh, showing up to fill out a number in like, you know, cell EE nine, uh, of a spreadsheet. But yeah. So, I mean, that's a long answer. The short answer being like, no, like in, in the, the sense of like a big B business case, it's not like people are like, uh, Hey board, I'm going to need some money to install Kubernetes. Like it's more of a, a supporting thing that you have. That's fair. I mean, I, I, again, your experience in the analyst space too, I figured it might be similar to somebody making a net app decision or putting vSphere in for the first time. Like it's still valuable, but it's core infrastructure. It's probably not showing up in your annual report because it's just, it's an enabler for actually building better software. And I think you and I can find somebody using bare metal compute, who's doing an amazing job of digital transformation because it's not, it's not dependent on a specific tech. So I was just curious if you've seen people actually try to turn that into a higher level business case, or sometimes those accidentally get conflated. Yeah. And, and to your point, I mean, uh, looking forward as they say, uh, it could be the case that following vSphere, right? Like I, I don't know if I ever like witnessed or saw, but I think it was a very real thing that you would have a business case for installing vSphere because the, uh, is assurity a word? The, the assurity that you would have, that it would reduce your costs by a huge amount, uh, was so strong that if one of your strategies was we should not spend so much money, which is a, uh, boring, but very valid business strategy. Uh, like, yeah, I mean, I, I could absolutely see that like business cases would be in, in the sense of a capital B, be made around that, but I don't think, um, and similarly, like with SAS and, uh, some public cloud, like, you know,

there's, there could be a business cases for that, but I don't think, I don't think Kubernetes itself is sort of new enough that you're just like, you know, going to go in there like you would with, uh, virtualization in the, uh, the two thousands. Yeah, that's fair. I mean, I think we'll, we might just see more platform business cases coming up as people are assembling platforms as whether that's public cloud, whether that's private cloud. In all those cases, you're assembling platforms and you're probably not stopping at just the infrastructure. You're figuring out, again, do I need an application layer? Do I need a CICD story? What's my observability play? How am I doing day two and op? So hopefully all those things are part of that business case. It would be, it seems to me foolhardy to just kind of pin one component of that platform as the business story. All of it is around getting better value, better customer adoption, lowering cost. All those sorts of fun, fun outcomes we're after. Yeah, yeah, yeah, for sure. And I mean, you know, using my wackadoodle pencil thing again, right? Like, like the, the, the business goal is to write something down and even, and maybe the vision is I would like to not forget things. Right. Right. And, and then the strategy is like, write something down and then, you know, it trickles down to, you know, somewhere below the CIO, the VP of infrastructure probably is like, oh, pencils, we need a pencil. And so that presents itself as a pencil strategy eventually. And I think similarly, you know, analogously, you could look at, as you were mentioning platforms and improving your ability to do software development and all of these things that are, there's a word that I try to avoid, but nonetheless, I will use an enabler, which not in the addict sense of enabler, but whatever the positive version of that is, you know, you're addicted to success. That's right. That's good. I think as long as that job to be done, which you're kind of alluding to there is, is traceable from the top. Exactly. There's a job to be done at the C-suite that, that when I'm in IT ops and I'm choosing between which service mesh to use, or do I deploy Kubernetes or not, or the build service, can I tie it back to that job to be done? Or am I accidentally just causing friction and motion

and activity when I actually need outcomes? Yeah. Yeah. You know, speaking of my, uh, my, uh, my hot dog, uh, kindling, uh, I was recently writing up, uh, alluding to job to be done stuff. Is that, is that, uh, is that a thing? Do the kids talk about that? I don't know who the kids are. I just like saying that. Is that, uh, are you find that that's widely used and sort of like, uh, I don't know, business world. You come across that a lot. Occasionally. I don't know if that's kind of the secret handshake of people doing a lot of DevOps lean, whatever we want to call, you know, current modern technology stuff who say that to try to reorient the conversation from sometimes being in the technical guts. Yeah. Yeah. No. Cause I remember reading or I first heard about it from, uh, Horace Deju way back when he was, uh, right in the middle of like analyzing it, Apple's rise into the world. And, uh, I remember like back then there was no book written about it or anything. There was just some weird articles you could read, but man, it's, it's a good, uh, it's a very useful theory that seems highly applicable to, uh, I don't know, let that, that above the stack thinking that we have in the tech world. And I guess, I guess to be fair, uh, tell me if I've got this right, but the, the job to be done theory is that, um, to summarize it, the metaphor, and, and I guess sometimes it's literal, but the metaphoric way of thinking about it is that your customer, uh, essentially hires you and, or, you know, meaning your product or service to do a job. Uh, they don't really like hire you. They don't really like buy your product to have the product it's hired to do something. And I guess historically we had, there's it's, this is kind of alluded to with the old, uh, you know, hammer and screwdriver, like conversations we used to have. I'm kind of forgetting them now, except, you know, I guess it's like getting a, like getting a picture on the wall, right? Like I don't, I'm not buying a hammer. I'm buying something to get a hole. And that's not even that my job to be done is to hang the picture. I don't really care how it happens. And, and there, there's one way of interpreting this, which, uh, which is my, my favorite, uh, all too, all too clever analysis of

things is like, you know, a, uh, a pizza delivery company wants to become a software company, not a pizza company. And as I always joke, like, as long as they have a pizza and not a DVD in the box, they can call themselves whatever they want. So you don't want to like over interpret it. But I think, I think the canonical example is, uh, the, the, the, one of the people who came up with this, they call the milkshake man because essentially, well, one, he was a man. Uh, and two, he, he had been asked by some, someone's probably tracked down who it actually was, but by some, um, what do they call it? Casual convenience, some fast food store to, uh, figure out how to increase revenue. Uh, if I remember, and, uh, being, being that rare consultant who actually leaves the office and studies what customers are doing him and his, uh, team went out to a couple of the locations and just sat in them all day and studied what people were doing. And they found this, this oddity that was unexpected that in the morning, there were a couple of stores that would sell for breakfast, a lot of milkshakes, which you do not expect in the morning. I mean, maybe the typical, uh, European stereotype of Americans you would expect, but I assure you here are two Americans that tell you that we think it's weird to have a milkshake in the morning. Now call it a Frappuccino. That's an entirely different thing, but nevermind that. Uh, but they noticed these people were buying milkshakes and so they studied it more. And what they found out is that, uh, when they interviewed them is that lots of the, lots of commuters would drive up and they would buy a milkshake, uh, for breakfast. And the reason they would buy it is because one, it was cheap to convenient three. It was very filling, right? So it gave them, uh, this filling this for breakfast. And I, the fourth is my favorite, which is like, uh, it had the low potential for being messy, right? Like as opposed to like a breakfast sandwich, which, you know, or, or even worse, like a taco. Now I being a native Texan have mastered the art of eating tacos in a car, but it's still a very, very risky, nervous activity to do.

It is like eating soup in the car. Yeah. And I've noticed going back to hot dogs, uh, you know, I have to continually work with my kids about how to hold and eat a hot dog so that it doesn't like mess up. And my poor daughter, she still is, she's still learning how to handle the, the, uh, the, the sandwich sort of construction, like about 30% of the time, like the, the inside will fall out onto the ground and she gets very upset about it. But you know, it's a skill to learn not to spill stuff on your face, especially if you're driving like 60 miles an hour down the highway. So anyways, and that story, I love that story. I thought one of the other reasons too, people were choosing milkshakes is that it took a long time to eat them. So they were purposely killing time on their commute, which is why I think in that story, somebody else had also come up with milkshakes, but they were thinner and like people weren't buying. Yeah, no, that's great. The point was like, they're killing time, right? The job to be done is I'm bored. Let me take a really long time to take this stupid, giant, frosty milkshake. And that was the point. And that's, that's the job to be done. Exactly. And so, so the whole bringing it all around without telling you more about my family and their food eating problems, uh, I should say the mechanics of food eating. It's just, you know, you, you summarize all of that of like the milkshake is being hired for the job that, that we just listed, right? They're just being hired for the job to have breakfast in the morning. And, you know, again, you can go crazy and like, you know, to feel full, to be able to work, to fulfill life, to ultimately like whatever, but that's a little too far. And so that kind of analysis, kind of like the pencil and Kubernetes and everything, it's always good to have that idea of like, what is this thing being hired to do? And not only asking yourself that, but as, as the milkshake man and his team ended up doing, like actually going out and discovering what people are doing, what these jobs are, because I think that's the other angle of it is most of the time, or most of the time when people have a job, hire a product or a service to do a job, it's not like they know what they're doing. They've just sort of ended up doing that. And so, uh, being able to kind of like highlight that and

draw it out is, uh, is always useful. Hence sort of, you know, my interest in, uh, talking more about like registries and how they fit in and kind of thinking about, uh, actually being conscious about using an event-driven architecture. But, uh, no, exactly. Well said. I mean, I think for all this stuff, look, you and I love talking tech. I love playing with tech. Just remember the point. I think for most of this, the gist of this stuff, like, why are you doing an adventure of an architecture? Why are you putting in Kubernetes or PAS? Or why are you doing, just ask that question. Like, those are the best architects I've ever met are the ones who at least ask why at non-annoying sort of levels. I think that last part is very important. Right. And extremely difficult. It's a science. Well, at least anecdotally from my experience over the years, it's extremely difficult for people to do effectively, uh, which, which I, I, I base on the lack of finding it commonly. There you go. Uh, all right. Well, great. Well, uh, hopefully that gave y'all the listeners a, uh, a good idea of, uh, kind of the, the, uh, what's going on with, uh, figuring out how, how to fit Kubernetes in the whole, uh, pivotal world. I think it'll be fun over the, uh, the next year to see, to see how people end up using that and how it evolves. And of course, uh, this is a good time to have a reminder that we, uh, we'll probably, uh, be talking about this and other things that, uh, uh, SpringOne platform, which is, uh, what are the dates for that? It's, it's an October, October 7 through 10 in your old hometown. So there's a, there's a reason that most of the main stage talks are about outcomes because we always like to reorient around what matters the most and some great main stage, check out the website, a lot of the keynotes are already announced. So it really should be an awesome year this year. We'll have, we'll have to get someone to walk on stage with a milkshake just to, uh, be a, uh, not to say anything about it. Exactly. Have it. Exactly. And I'll, I'll make it, I'll make a personal offer. If, if you end up coming, uh, I will show you how to eat a taco successfully. There, there's a, that's a breakout. Like I would do a 30 minute breakout.

Not only eat a taco to avoid spilling it on yourself. We can also try it in a car and I will also show you, you know, key to this strategy is, is, uh, let's, let's come up with a phrase here is, is a multi-sided taco consumption management. You've really got to like figure out what's, you know, there's, you got to work both sides. It's a lot of thinking that goes in there. So you do that, you do both sides, you top down as well, or you always just left and right. Oh, now top down. That's a whole, that's a way of life right there. You got to figure that out. Yeah. My son does that. It looks like he's eating a sandwich. It really bothers me. Like eat it the sides, I think left and right. Right now. See when I eat my own tacos, I don't mind a top downer approach because I, I spend a lot of time thinking about like, so when you got the taco laid out, you're going to fold it up and you don't want to end up. Well, I shouldn't say you, I don't want to end up with basically layers where it's just lettuce on the top and cheese. Right. And then like, I want it mixed together. Cause I enjoy my, my idea of a taco is it's like a melange of things, right? Now a burger is a slightly different, a burger is done on a different, um, plane, I guess. Right. Cause you think about how you consume a burger or a sandwich, it's, it's, it's a perpendicular to a taco. So instead of spreading it out vertically, you spread it out horizontally. So in each bite, you have a high chance of getting all of the different items. But, uh, with a taco, you have to put a lot more thinking into how you achieve that in the, uh, the vertical mode. But, uh, I'm happy to discuss this even more in depth. Yeah. That's my biggest takeaway from this episode with actual demos. I might have to, uh, if, if I get a line of people, I might actually have to, uh, you get a wine spit bucket. So I don't eat the taco, which would be sad, but yeah, we'll just get one of those little placards and put it in the cafeteria area at the conference and just like come by and watch Coté eat tacos. That sounds good. That sounds good. Yeah. Well, uh, if you're interested in that, uh, also there'll be a pretty good conference going on. Uh, you can go to SpringOne platform.io and, uh, I think there's still a two or $300 discount, uh, going on. If not, you missed out,

uh, but you can check that out. And as always, uh, this has been Pivotal Conversations. Uh, when, when, uh, I, I remember to actually click publish instead of relying on the schedule publishing service, you can see the show notes for this and other episodes at pivotal.io slash podcast. And, uh, I think, uh, right before this episode, you must've heard a, uh, a great interview I had at pivotal Paris, uh, going over protosteller and, uh, with, with, uh, with Frank, the, uh, pivotal labs manager who worked on that. And there's going to be some other episodes from pivotal Paris, uh, that you can hear that are fun field interviews, but you can go there and see, uh, all of the episodes we have in the, the pivotal world. Also, you can just go directly to soundcloud.com slash Pivotal Conversations and, uh, check them out in more detail and, you know, subscribe wherever it is, just in case, like you're wondering, what is this? How did I end up listening to this? Now, you know how you can listen to more if you weren't shocked. So with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.