All right. I'm going to start with your first guest, and then we'll get to Richard. This is Friday. For me, it's like 4.39 PM. I always want to say, well, first of all, let me parentheticalize. If I said central time, you would think US central time, right? So I got to be like central European time. I haven't figured out if the Europeans are like central European time. I don't think they're extremely time zone aware because they basically have one time zone. So I don't think that comes up. They're basically like, there's the one time zone and the English, and that's pretty. But anyways, as you're towards the end of the week here, you're wrapping up. What's the, whether planned or not, the kind of ritual you go through to sort of end out the week? What do you find yourself doing at the end of each week? A lot of times I'll do TGIK, which is the YouTube live stream where I play with stuff. And so that ends up being Friday afternoon here in Seattle. And it's like the worst time for the rest of the world for us to do a live broadcast. And so, you know, when I first set it up, it's like, you know, hey, that was a bad idea. And so, but we just stuck with it. So we have folks that are like, you know, tuning in the middle of the night. That is funny. Yeah. Yeah. It could only be worse if you were like in Hawaii or something. And then it would even be bad for the Californians. I mean, the West coasters. So, so that you have that to mark your week, basically doing a, a live, a live event, a live podcast. And is that a, is that good? Like, does that leave you here? And specifically on this, I've been thinking a lot recently, like every time I do a podcast, I get a little like charged up. And so there's one that I have to do at, well, I should say, sorry, I get to do at basically like every Thursday at 10 PM. And so it wraps up at 11. And after I do it, I'm like, oh, I'm good for another four hours, but really like I should go to sleep. So like, like, no, it's super energizing to do these things. And, and so I haven't been able to do it for a while just because like I have a gazillion other things going on. And so there's a set of other folks that help out. Duffy has been
2:05taking, uh, one of our, uh, uh, field engineering folks, uh, has been taking on a lot of these stuff. He's great, huge, deep well of knowledge there. Um, but yeah, I'll like, like the worst is like when I would do that and then I would have an interview to, you know, hire somebody afterwards. And it'd be like, I am not in the right mindset to have sort of a thoughtful interview with people. Cause you are really charged up after doing those things. Yeah. Yeah. How about, okay. How about yourself, Richard, at the end of the week, what do you do to like, uh, is that when you read those 50 books that you read every week? What do you, uh, how do you, how do you kind of like shift out? Yeah. Uh, I find myself cleaning my desk and getting back to inbox zero. Like when I want to go into the, you are so virtuous, Richard. I don't know how I just, I need to have a clear mind. If I just walk out of here and then I'm, I'll be thinking about all through dinner or the weekends. I gotta, I gotta start the weekend with a clean slate. Okay. All right. That's a good, I, I could, I could take some advice from that. I, I think, you know, I've, we recently had to enter our, uh, some MBOs into our corporate thing and I've been thinking I need to go adjust some. And I've been thinking one of them needs to be learn from Richard, learn how to be more productive, clean your desk. So that's good. I'm going to put that on there. Uh, clean desk at least 45 times this year. And I think, uh, that's, that doesn't it. What are the things you're supposed to do? Make them smile, like a accountable, trackable, knowable and doable. There you go. Smart, not smile. That's close. It's very, it's more positive. Yeah. So my favorite like thing is when people share either screenshots or their desktop to present, like I was on one of these and the person, and I won't, I don't even remember who, but I won't out them. They literally had 3000, 30,000 unread messages on outlook. I'm like, I didn't know that could go that high. Or like when people share their like phone, uh, screenshots and their battery percentages down to like 5%. I'm like, how can you live like that? Yeah, I know. I screen grabbed those. There was somebody with like 90,000 last year and I had to shame them on Twitter afterwards. Cause that's just untenable. I don't, I don't know what you're
4:06doing with that. I think, I think, you know, in the future, I think, uh, psychologists and psychiatrists will study the people nowadays. And they realize that there's a, there's a part of your brain that at some point, if you stare at those big red 30,000 emails long enough, you just never see it. You just, it just is blocked out of your vision and you can't, uh, you can't encounter it. Well, that's good to know. I'm going to, I'm going to try to take some tips from that when we wrap up here, but why don't you introduce yourself guests? Well, uh, my name is Joe Bita. I'm a principal engineer at VMware, uh, joined VMware with the acquisition of Heptio a little over a year ago. Uh, Heptio was a company, uh, that I co-founded with Craig McLuckie to sort of bring Kubernetes to enterprises. And, uh, we bridge the gap between sort of the brave new world of cloud native and the reality of, uh, how most enterprise, uh, developers and it departments, uh, find themselves in. Uh, and then previous to that, uh, spent about 10 plus years at Google, helped start the Kubernetes project, uh, started Google compute engine and, uh, yeah. And so I've been doing sort of developer platformy type stuff my entire career pretty much. So I, I, I remember, uh, there's some, well, first of all, I was just realizing you did a podcast with like, uh, I mean, I guess he's my best friend, Charles Lowell at the front side a while ago. And I was, I was looking through stuff and I was like, Oh look, there they are. That, you know, just, uh, I remember listening to that way back when. So that was, that was fun. But you know, you, you, you said a few phrases there that I think are interesting and worth, like given your focus, getting your, your perspective on, but like, what does that mean for the enterprise? Like how does, like when you use that phrase, like to, to, to, to maybe give some buckets here, like one, what problems are being solved there, but then too, the thing I've gotten more interested in recently is like what unique benefits or opportunities exist, uh, as well in the context of all of this. Yeah. I think, you know, the way that I, from a sort of platform cloud developer
6:10point of view, the way I would define enterprise is, uh, by and large folks dealing with, uh, legacy and I'll, and I'll, and I'll go into some more nuance in terms of what I mean by that, uh, both in terms of processes, technology and existing systems, uh, and then folks dealing with a different risk profile, um, whether it be regulatory, whether it be, uh, uh, you know, uh, working worldwide introduces new problems. And so these are the types of things that I think are unique to more established, larger businesses and combined with the fact that traditionally they haven't viewed themselves as technology companies. And so they haven't actually built the focus and the culture and the, the, um, the thinking around using technology, using software as an accelerator. They've, you know, in a lot of cases, and I mean, it's over general generalizing, but in a lot of cases, they've, uh, viewed these things as cost centers and sort of costs of doing business versus things that it can actually accelerate the business. And I would contrast that with, I would say sort of tech forward businesses. Um, I don't want to say Valley businesses cause it's bigger than the Valley, but these are generally businesses that are younger, don't have a lot of that history to, to hold them back and fundamentally understand at a core level how technology is an accelerator for them. Not a, uh, uh, uh, not a sort of adjunct type of thing. Um, and when I say legacy, I'm super respectful of legacy. I think when a company has legacy systems, they're there because they're bringing in money. Those are the things that are running the business. If those things weren't valuable, if those things weren't critical to the business, they would have thrown these things away a long time ago. And so I think it's really about, you know, understanding that, you know, legacy equals critical business functions that have been proven over time. Yeah. And so figuring out how to bring that into the future without, uh, uh, without throwing away all the value that's been built over
8:13time. Um, and then I think there's also legacy from a process point of view. I think there's a lot of folks and I think this is, um, you know, coming to VMware, understanding a lot of the VMware customers, the VI admin, you know, you look at the processes and you can trace the lineage of these things back to when, you know, people bought machines from Dell or from whomever and rack and stack them, right? You file a ticket and three months later you get a machine. Well, virtualization means you file a ticket and two weeks later you get a machine. And I think one of the opportunities here is to just like CICD, which we can talk about is as you start to get these feedback loops quicker, more immediate, then it fundamentally changes the way that you build software and the way that you approach doing things. And so I think the jump to cloud is really about how does provisioning go from two weeks with tickets to API driven self-service elastic that you get with a cloud-like platform. Uh, and, and what are the implications for the business, for the development teams? And I think that's the huge opportunity there is there's, there really is sort of a tipping point or some sort of singularity as you get over that hump and you have infrastructure that can really, uh, keep up with, uh, application teams. Is there a process or part of the stack more specifically that you think that the, that existing company that impacts these buying cycles that maybe cloud broke or some of these new things are kind of breaking? Like, is there a specific thing that even a forward thinking hundred year old company deals with? Like what's that? Is it procurement? Is it like, what are those things that you come in and see? Like, yeah, even if I want to be forward thinking, it's hard because of X. I think a lot of it is just establishing a culture of trust across the organization. A lot of, when you look at sort of continuous deployment, it's, it's fundamentally a trust but verified type of thing. It's like, we have testing, we have processes, we can roll back. Those all enable you to be able to move fast and actually deal with breakage, deal with the eventualities. I think what we find with larger organizations is that over time, something bad happens, you introduce
10:18more process and that becomes a scar. And those scars build up over time. And I think everybody's operating in good faith, but it fundamentally changes the way that they view things to be risk adverse. And hey, you know, we need to protect ourselves from our, our, our engineers. And so I think the biggest thing holding back, you know, these companies is, um, essentially resetting that relationship between the IT platform teams and the developers. And I think the thing that's forcing the issue here is essentially, you know, uh, the fact that those application teams within organizations have choices now that they never had before with, you know, shadow IT. And, you know, if I'm a developer and, you know, it's going to take me, you know, two, four, six weeks to actually allocate stuff for an application, I need to get stuff done. I could go through and actually, you know, provision stuff on Amazon or Microsoft or wherever, get that done in a day, what would take me six weeks. And then, you know, it's easier to ask forgiveness and permission, right? Put that on my corporate credit card, ship the app, and then dare them to deny the expense and shut it down. And so I think what we find is that these centralized IT teams are having to compete for their own users in a way that they never have before. And I think that's the opportunity. I think what we're looking at with Tanzu, what we're looking at with Heptio, what I think, you know, Pivotal has traditionally done is how do we arm those IT teams so that they can be competitive for their own users when their own users, you know, can go to cloud directly and actually find the sweet spot between, you know, development teams being able to move fast, but still having the, you know, the mechanisms in place to control risk, to control spend, to understand the shape of how people are using IT. Do you think that internal developer, that enterprise developer has to choose things that feel more familiar to IT than that, let's say, forward-thinking or younger tech companies can say, screw it, we're going all Mongo, what the hell? Do you think, is there, do you see that or do you,
12:20are you seeing more freedom to say, forget it, we're bringing in Knative, hey, forget it, we're going to bring in Cassandra, we're going to bring in this completely new database that has four companies in their startup. Is that still a challenge or do I have to pick something that feels more familiar in the enterprise? The perspective that I take there is that, you know, every organization is different. I think sometimes it's, you know, when you talk to companies, they're a little bit like they're, you know, each is their own little Glockos Island where they've evolved certain ways, different processes, different ways of actually connecting things. And so I think some organizations, some businesses can take on some groups, application groups within that, that, that business can be a little bit more sort of forward-thinking in terms of adopting new technology. Others need to lock things down. Sometimes this is because, you know, the problem space that they're solving is pinned to some of these legacy systems. Like, hey, you know, mainframe sales are still on an upswing, right? This is not something that's going to go away anytime soon. Whereas I think other times it's more of a disconnected new motion where folks actually have the freedom to be able to, to adopt some of the latest and greatest. And so I think that, you know, across all of these things, we're seeing a, uh, uh, uh, you know, just adding to the challenges of actually maintaining IT within an organization because there is no one size fits all solution to, to any of these application problems. So yeah. And, and, uh, you know, thus far, I think, I think we've gone over many, uh, roles of, of people involved. I think, I think, you know, just to be clear, you were saying this as a, this is not a good thing to say, but I think it's very true. Like, you know, we have to protect ourselves from our engineers, which I think is, uh, a, uh, uh, strong mentality, uh, in the enterprise space. So, so we've got engineers there and then we have the, uh, I don't know, operations people. Um, and I think, I think there's a few other roles scurrying about, but like when in the, in this realm that we're talking about, as far as large organizations or enterprises kind of supporting their own stack of stuff to run software, what are the kind of roles that you see out
14:23there nowadays? Who are the, the people working on this? Well, I think the, um, so, you know, I'll, I'll often, you know, think about this as, as, uh, essentially a matrix with sort of four spots. I think there's platform and there's application and there's operations and developers. And most of the time we think about, uh, uh, platform operators and application developers. Uh, but I actually think that there's two other squares there that are super meaningful. Uh, specifically, I think that we see that there is a role for application operations, even in highly managed environments, there's a role for making sure that the application is up. It's reliable dealing with, you know, unexpected situations, capacity, build out all that stuff. I think in some teams, these things get sort of merged in a DevOps type of thing. I think in the organization, a lot of times DevOps ends up meaning, uh, at the application layer. Uh, so, you know, uh, I think there's a question of how far down the stack does a DevOps team go? I think in mature organizations, we want to see some split between platform applications. And so that the, the dev and the ops at that, uh, application layer, uh, are much more aligned towards actually delivering an experience for the application. And then the other interesting thing there is, uh, platform developers. And so platform developers end up being, you know, folks that, uh, uh, help to build tools, policies, extensions for the platform that actually really sort of fit it to that Galapagos Island. That is that organization that really helped to make sure that, uh, whatever platform that you're using is well adapted to the quirks and, uh, and, you know, unique situations of the org. And so I think that, you know, we've been neglecting some of the sort of the platform, uh, developers and the application operators to some degree, uh, when we talk about these things, but I think it's important for us to think about all those different roles and how they interact with each other. And then there's
16:25probably other things like you'll have your data team and, you know, you'll have, you know, that, that actually I think ended up being adjunct to these things. Cause I think these things end up being fractal, you don't have one platform team. You may actually have your data platform versus your compute platform versus your machine learning platform versus or whatever platform. Yeah. I'm, I'm always forgetting the data people. That's, that's unfortunate of me. I should, I should be more polite, but I think, you know, there's a couple of things that, that, that you're saying there that I, I, I think a lot about. And one of them is, uh, well, you know, in my more exciting moments to think about these kinds of topics, but it is like you mentioned this briefly, but I have been wondering like what DevOps means nowadays, like, like it's very, like, and I, I, I go back and forth between this. Like, I don't, I don't, I mean, I know this kind of connection is a little like fraught with whatever, but like, I always kind of think that like when people kind of understood or, or became knowledgeable of SRE stuff, it was kind of like, well, is this, what does this suck all the DevOps people down into this or, or not? Right. Or, or, you know, is it more of a yes and situation or, you know, like what, what's going on with this? But then the other, the other view that comes up that I don't hear a tremendous amount about is, is what you were just saying is that to some extent DevOps is more about like, and I'm putting words into your mouth or describing the ones in mind here, but like DevOps is more about like application developers, like understanding networking and understanding like how to write applications that are not only observable, but like that run well. And, and, and that like actually are architected like purposefully to like run in an environment well. And it is like, I don't, I think, I think overall to, to personify it, like the DevOps idea has like some thinking to do as far as like, like what, what identity does it want at this point? Because it really, it could be all over the map. Like it's, I mean, as I just demonstrated, it's hard to know exactly what, what a, what a DevOps is to put it
18:28in a jokey way. Well, I think, you know, uh, uh, I was having drinks with Kelsey Hightower at one point. Uh, uh, and, uh, and he, he described DevOps as sort of group therapy for large organizations. Yeah, yeah, yeah, exactly. Um, I do think though that there is, um, you know, I love these industry terms that are underdefined that people just argue on Twitter about what the hell they mean. And there's like no right answer to it. Um, from my point of view, the main learning from DevOps in general is that application people have to care about how their stuff runs in production. Yeah. Uh, and, uh, and operators have to be thinking about, uh, uh, completing that feedback loop such that systems become more operable over time. Uh, I think, you know, one of the, one of the questions in my mind is again, how far down the stack does DevOps go? I think in small organizations and startups, you end up everybody doing anything, everything. So you end up with that whole full stack, you know, uh, uh, idea. I think as we move to more mature organizations, I think we, what we get into is sort of ops specialization where you don't have somebody dealing with the entire stack. You have them actually dealing with parts of the stack in more specialized way. Um, and I think, you know, figuring out how that coexists with sort of the DevOps mentality, uh, is, uh, is I think something that's worthwhile, but I think, I think for the future of building reliable systems that are scalable, that are, you know, uh, modern, uh, you know, you can't be ignorant of, of how your application code runs in production. It's just not acceptable these days. Uh, I think that's, that's the root of, of DevOps for me. Yeah. And I think, I think it's a sufficiently interesting riddle for most application developers to be fascinated by nowadays. Right. Like I think, I think, I don't know, we've all been developers or are, or whatever. Like, I think you throw a riddle in front of a developer, your job is done, right? Like you can, you can sway them to be interested and do the right
20:29thing. If you phrase the riddle correctly, uh, which, which is, uh, nice. So, I mean, so, so given that Joe, should application developers deeply understand Kubernetes or are there just some primitives they should grok and the rest of it should be left to an abstraction served up by that platform dev team? Like how, how deep do I need to go as a dev? It depends on what you're working on. I think, you know, uh, you know, probably, and I'm pulling numbers out of nowhere here, but like, you know, I'm guessing 80, 90% of enterprise applications are crud apps with a little bit of business logic that don't have huge scalability requirements. Um, you know, for that type of thing, you know, uh, understanding the underlying platform that you're running on is probably not necessary. Uh, now if you're say building a video, video encoding, you know, pipeline, or you're doing machine learning, or you're dealing with extreme scale, or if you have problems that involve, you know, things that are replicated and, uh, available across the globe, that'll start introducing some unique problems where, you know, as an engineer, you have to be able to go deep and understand the, the trade-offs that you're, you know, that you're working on. I think, you know, we love to use car analogies here. Like how many people need to understand how an internal combustion engine works, right? Like most people don't, but if you're a race car driver, yeah, of course you do. Right. If you're a long haul trucker, you probably understand a lot more about how your vehicle works than if you're just going to the grocery store. And so the, uh, you know, I think that there's different, different problem domains that require different types of, uh, uh, uh, uh, understanding of the underlying platform. Now that being said, I think that there's different types of developers in terms of how they think and how they, uh, approach these things. Uh, you know, one way that I like to think about it is, you know, you'll have depth first versus breadth first sort of developers. I think there's folks who are like, Hey, how do I get something
22:29done? You know, I ran this, it seems to work fine. Ship it. I'm done. Right. And I think that, you know, they're very much focused on the result and what is my quickest time to result. And, uh, and you know, I'm a systems person. I've done development stuff. I'm very much the depth first type of person. I want to understand like when I run this thing, where's the main, what is the event loop look like? How does this interface to the network? Well, you know, like I want to understand this stack all the way down to the hardware. And, uh, it means that sometimes I operate a lot slower, but it also means that, you know, I can maybe foresee problems that, uh, you're not going to foresee if you're just sort of focused on that. Hey, it seems to work, ship it type of mentality. And I think there's, there's pros and cons to both approaches there. Yeah. So quick one more follow-up to that though. So I can't twist this into the car analogy, do enough people who might be using Kubernetes as their destination, do they need to know things like config maps or secrets? They need to might, maybe they'll write a CRD or run a cron. So can you just be like, I'm just getting in my car and driving to the grocery store or for a lot of devs, do you see them wanting to use some of those primitives in their actual app architecture? I think that, uh, it's an evolving story. I think that there are ways to use Kubernetes, especially if you have a platform team that's, that's supporting you where you just throw code at it. I think we still got a ways to go to actually make it work that way. Uh, I also think that the way that Kubernetes works as a distributed system has lessons that can apply to the application domain also. Right. And I think, you know, when I go deep into this about like level triggered versus edge triggered things, how contrast this to sort of like, you know, uh, event streaming systems using Kafka as sort of one way versus the way that Kubernetes works, where you have controllers that do state reconciliation. I think there's useful patterns to be able to extract out of Kubernetes that you can apply to your application level if you need to. And I think we're still figuring some of that stuff out. Um, I, I also think that, you know, there is, you know, a, uh, uh, a maturity curve
24:37for any technology. And I think there's a lot of folks that, uh, get deep into Kubernetes where maybe they don't have to. I don't think that's necessarily a bad thing. I think, you know, they're, they're going to be, uh, essentially seed crystals and sort of fonts of knowledge within their organization to be able to deal with some of the, the more, you know, problems that do start involving the, uh, the underlying platform. You know, I, I have a huge amount of respect for folks that, you know, uh, don't let themselves be constrained by boundaries, right? When they see a problem, they want to chase it down. They want to understand, you know, uh, uh, and, and, you know, Hey, you know, maybe that's a kernel problem. Okay. I'll start reading the kernel code. Right. Like, I think that is a skill set that certain developers have that I think is worthwhile. So yeah, I think there's pros and cons to this. I think sometimes people overdo it and we definitely have, you know, a distance to go in terms of making Kubernetes more turnkey. And I think that's a big part of what we're working on at VMware, uh, especially as we bring in a lot of the experience from pivotal. Um, now you mentioned config maps directly here. And I think one of the things that I think is worth looking at is the config system that comes with spring. How does that actually interact with the underlying platform? And are there ways for us to bring those things closer together and take some of the, the knowledge and the experience from spring and make that be more integrated, more applicable in a polyglot type of way? I think that, you know, understanding how config works in spring is a similar type of level of depth to understanding how config maps work in Kubernetes. Where is that line where, uh, it's sort of like, this is spring stuff and this is like Kubernetes stuff. And, and like, especially with like service mesh stuff running around, like it gets a little blurry there. Like, which is as far as I remember, it's sort of like, it's official, it's blurry by design, but, but like, what, what, what do you think? Like, where is the layer where it's like, not the, not the platform developers deal, like to, to think about solving and it gets pushed up, pushed up. I'm
26:39trying to be nonjudgmental my phrasing. It is a, uh, it's a delightful riddle for the application developers to, uh, to solve. I think, um, yeah, that is a blurry line and we're still figuring it out. I mean, if we look at the, the history of service meshes, it started with the finagle stuff coming out of Twitter, which was essentially a Java library, the buoyant folks broke that out as a sidecar with link or D and that predated Istio. And so we have this, uh, uh, this dichotomy between what functionality are we going to implement as libraries that sit in your, uh, uh, in your application and what functionality is actually going to be, you know, quasi system where it actually is applied and managed from the outside. And I think that there's, there's even further sort of lines between that. I think, you know, one of the interesting things is that we look at service mesh and we think, Oh, this is something that operates at the networking level with some IP tables, magic to redirect traffic to an envoy or link or D or whatever. Right. But I think we also can look at other systems that are starting to use sidecars for other types of value ads. Um, I'm thinking something like cloud state from the ACA folks, right? This is about essentially doing distributed state management as implemented in a sidecar. So taking a bunch of the stuff that was built out there and extracting that into essentially a system service that any, uh, workload can use. That's an interesting evolution as we see this stuff happen. Uh, another, uh, place where we see this is dapper from Microsoft where essentially it's a service mesh type of thing, but much more, uh, uh, integrated with the application in terms of like, if I want to talk to another service, I talk to a local host endpoint and the routing to which service I want to talk to is built into the path of the HTTP endpoint that I'm talking to. Right. So it still has a lot of the sort of, uh, um, uh, qualities of a service
28:40mesh, but it's much more application aware. And so I think we're seeing sort of this dichotomy and transition between sidecars and fat clients, you know, fat libraries that is going to be evolving over time. And I think we're still figuring out the right way to do that. And I think one of the interesting things that I'm going to be looking to, to, you know, uh, learn from and talk to and collaborate with the spring folks around is, you know, how can we actually, you know, bring some of the lessons and the experience and the technology and spring into a wider world and create more interoperability there so that, you know, so that we can break down silos and create, uh, a network effect that goes beyond a single framework. Yeah. Yeah. I was just, you know, you're drawing up an image of like, remember those old black and white Disney cartoons where there's like a gigantic, like fat dog and a tiny model T Ford, except like jammed into a sidecar that they sit, they sit down on the other end of the motorcycle picks up and then they, uh, they bounce along as they're driving, probably hitting someone on the head. And, and, and it's been fascinating because this whole sidecar thing, um, uh, uh, you know, there was a, there was an evolution going on in Google around the same thing. So traditionally Google had three languages that people developed in, this was, uh, uh, C plus plus Java and go, I would not go and, uh, Python and, uh, um, and for Java and Python, they were able to use Swig to be able to actually, you know, thunk down to the C plus plus libraries. And so they would write a lot of functionality in the monorepo, and then you could access it from any of the platforms. And, um, and one of the, one of the sort of implications of this is that you would find a bug in one of those core libraries and then you would tell everybody, okay, every team now has to rebuild, right? It was like, you'd come in on a Monday morning and you'd get this email going like, well, this week is going to suck because I have to actually, you know, rush a release out to deal with this critical issue. And so, you know, Google has, you know, internally, and it's, it, the, the, the form and the shape has taken a different,
30:43different sort of way, but Google internally has actually started figuring out how to take that stuff extracted into a sort of separate binary to deliver that functionality out of band of, of, uh, of, you know, libraries. Um, and so, yeah, it's going to be interesting to see how this actually starts to play out across, uh, other, other frameworks and other languages. Yeah. Interesting. Can you, uh, switching gears, can you tell us kind of what gets you interested, excited about some of the work that was called Pacific now vSphere Kubernetes? Like that seems like that was a good heck of an engineering effort. I'm sure it was well underway by the time Heptio came in, but you still had some fingerprints on it. Like that's not just a, just, just kind of bolted on. It's not something that, I don't know, to me coming in, that feels like that's kind of a big deal. But as you look at that, am I right? And why do you think that is? Yeah. So I think, you know, when we talk about Pacific, there's really sort of three parts of Pacific that are worth digging into. And I think each of these things are exciting in their own way. So the first thing to recognize is that vSphere for all the talk of private cloud and all that was really viewing cloud from the point of view of the infrastructure providers. How do I use virtualization? How do I create automation for allocation? How do I, you know, create, you know, more, uh, efficiencies for the VI admin? And I think, you know, it, it, it did a great job around that traditionally. But, you know, as developers, we recognize that there's a whole nother side of cloud and that's the API driven self-service and elastic aspects of it. And traditionally, you know, you know, being able to write a program that launches a VM or allocates networking resources has been a difficult thing on top of vSphere. And so the first thing that vSphere is doing as part of specific Pacific is, um, reusing Kubernetes as the control plane in the API surface area for exposing, uh, IaaS concepts in vSphere. And so this is useful, even if you don't give a crap about Kubernetes, because what it means is that there's now a ecosystem and tools and API sort of gestalt
32:47or way of doing things that, you know, starts to allow developers to interact with vSphere as if vSphere were a cloud. And so really about, you know, taking, you know, the experience that you get on public cloud as a application team and bringing that to vSphere. And that's based on top of Kubernetes API concept. And so I think there's a whole talk thread I can do around Kubernetes being a platform for platforms and universal control planes and stuff like that. So I think that's super, super exciting. The next thing is, you know, but that's at sort of the API control plane level. The next thing is like at the fundamental virtualization level, there is an effort to build Kubernetes support deep into vSphere, into ESX. So being able to blur the lines between VMs and pods and containers. Uh, this is essentially, you know, in some ways an evolution of some of the, the, uh, uh, containerization work that has been done before, but there's a much larger ecosystem of folks building on top of Kubernetes that now becomes, uh, uh, you know, essentially supercharged with the capabilities that you get on top of vSphere. And so in some ways, when we look at sort of, you know, Amazon building Fargate as a way to accelerate and bring some special sauce to, to Kubernetes or, uh, as you're doing as your container instances as a way of doing this, we're, we have a similar thing. I think it ended up getting named the VMware container service, which ends up our VMware pod service, I believe is that, which ends up being a way to, uh, uh, essentially have, uh, you know, uh, a special capabilities that blur the lines between VMs and brings VMware's huge history around virtualization to the container world. And then the third sort of leg of Pacific is, uh, integrating, um, you know, what we're calling, uh, Tansu Kubernetes grid, which is a way to walk up and say, give me a cluster, delete a cluster, scale this cluster, upgrade the cluster, really bringing sort of a modern Kubernetes service, whether, you know,
34:48something comparable to GKE, TK, uh, TKG, uh, GKE, AKS, EKS, that type of mentality, bringing that and building that on top of, uh, that new API surface area that we have, uh, you know, building on top of a bunch of stuff that we're driving upstream in Kubernetes. And so it really gives sort of that scalable self-service clusters as cattle type of mentality to vSphere. And so I think all three of those things are super exciting, are bringing a ton of value to, uh, to, uh, vCF4, vSphere 7 customers. Yeah. It seems like some cool engineering there. Can you define the native pods for me? I mean, I've read about them a little bit. I think it's interesting. I, it seems like it's a convergence of a lot of different types of tech. So what is that in our world and why should a customer care about them? Well, I think, you know, when we look at this technology, it's really about how, you know, and, and when we were, when we were launching Kubernetes and GKE, we had this discussion of like how much of the virtual machine that you're running on should be visible in Kubernetes. And I think, you know, uh, because of where the industry was at, we made that idea of the node very visible. Um, and I think that that was a, uh, uh, uh, absolutely critical for adoption for folks to understand what's happening around the covers. I think we've moved into a new phase where I think we finally have hit a point where, uh, folks using Kubernetes can say, run this. I don't care where it runs. I just want the system to be able to do it. And so now the question is, is that how can we, uh, you know, blend the virtual machine runtime and the container runtime in ways to enhance security and performance and efficiency across these things, um, and isolation, right? And I think, um, as you start, so, so essentially what these things end up being is highly optimized special purpose VMs that are sort of instantiated on demand to wrap pots. Uh, and so the integration with, uh, uh, uh, uh, you know, uh, storage and, um, uh, and, uh, container image management and networking,
36:48those are a bunch of the hard problems that you have to start facing when you start doing these sort of, you know, you know, shrink wrap VMs around pots. Um, now one of the, the, the good benefits of this is that, you know, ESX in terms of dealing with scheduling and isolation, uh, is, you know, honestly has, uh, uh, a richer history and a better, you know, more functionality than, um, than container technology on top of, of raw Linux. And so we'll actually see things where, uh, even on, uh, compared to bare metal, uh, uh, you know, these, uh, native pods or these, these, uh, V pods, right? We're still coming up with the right name for them. The, the, the V sphere pod service can actually outperform bare metal because of things like being smart about Numa architectures and hyper threat assignments and memory layout and that type of stuff. And so that can actually give you a performance increase when running virtualized over actually bare metal Kubernetes. And so I think there's some really, really, uh, interesting and somewhat non-intuitive results of bringing the deep expertise around virtualization to the Kubernetes world. So as a, as a last question, I was asking, uh, uh, when I talk with Don Foster, I asked her this and, uh, so it'd be fun to compare answers, but like, so broadening out beyond the lowercase V world that, that we love so much, like what, what, what is the Kubernetes community want? Um, you know, that's a good question. Um, you know, as somebody who's, you know, I'm not part of the Kubernetes steering committee now, but I, but I was, uh, as you know, one of the founders of the project, I think our goal was to make Kubernetes boring, uh, get to the point where it's rock solid and people build confidence on building on top of it. And so a big part of that effort was to try and sort of freeze the core of what Kubernetes
38:49is and create extension points so that a larger ecosystem can form around it. To stabilize it. Yeah. And so, you know, and so I think that our goal, and I think, you know, and, and again, like what is the community? I don't know. I'm not sure. I mean, the community is very diverse, which is a good thing, but our goal is to actually not be gatekeepers to people doing interesting stuff in this, in this world. Um, and so when you go to a KubeCon, when you look at that crazy CNCF, you know, I chart, um, you know, it's kind of a beautiful chaos, right? I mean, that is a sign of innovation when people are trying so many different things, they're experimenting, they're innovating. I think that's made possible by Kubernetes, not trying to do too much and concentrating on extensibility and a solid core versus, uh, uh, versus on trying to solve every problem for every person. And so I think the, and I think this is an interesting comparison of Kubernetes to perhaps some other platform type of projects where we want to provide a kernel that can be used in a bunch of different places versus trying to actually identify and solve scenarios in a vertical way. Uh, and again, it's a much more bottoms up sort of systems type of, uh, you know, Unix philosophy type of thing, uh, versus a, you know, uh, uh, a much more curated, what is the story? Who's the user? Who's the persona? Let's solve for them type of story. Um, and I think, you know, there's pros and cons there again, beautiful chaos. It's beautiful and it's chaotic. It's intimidating. I think one of the jobs that we have as a vendor in this space is to bring opinion to actually bring best practices, help people navigate this world without cutting them off from it. So that way we can get them started. We can make sure that they see value, but then as they look to benefit from this, this larger ecosystem, they're able to do that. And that's, that's one of the things that I'm focused on is, is how do we build a blended approach that, uh,
40:50uh, delivers immediate value for those who don't want to be Kubernetes experts, but then also as they get more familiar as they have specialized needs, they're not, uh, uh, they're not in a situation where they have to reset things and go to raw VMs again. Yeah. Yeah. No, that's good. That, that, that actually, that, that kind of, uh, organizes a lot of, of, uh, what that chaos looks like in the, in the sense of like, in the sense of like, here's, here's kind of like the, the ground for a commons area. And then we want people to come on to the commons and do stuff. Right. Like, and, and, uh, you know, I don't know, just like I said, do things. We're not really sure what those things are, but it'd be cool if they were doing them, which is encouraging. The rise, Joe, I mean, when you look at this, I don't know, maybe you're super optimistic. This seems like Kubernetes still took off faster than almost anyone really predicted. Is it because of that kind of light opinions? It doesn't compete directly with public cloud. It's, uh, you know, approachable enough for platform bills. Like what was the perfect storm that, that made this take off? Is it those things you just pointed out? Yeah. I, and largely it's, it's, it's a, it's a community and it's, and it's, you know, I think, uh, going to the CNCF and, you know, I think, you know, like we can have a discussion over beers about, you know, pros and cons of foundations and stuff, but having that vendor neutral certainty around, around Kubernetes, I think was one of the key ingredients. Um, having, uh, uh, that Unix philosophy of how things build up was part of it. Having a community in the way that, you know, we brought people in where we welcomed them versus sort of, you know, the, you know, beloved benevolent dictator model, I think was a big part of it too. Um, you know, I, you know, it's, uh, you know, I, I don't think anybody who was involved with Kubernetes early on could have predicted where we're at. Um, and I think it's evolved over time, right? I think this idea of Kubernetes as a universal control plane, uh, you know, uh, wasn't part of the initial thinking, but evolved over time as we understood more of what we were
42:52building. Yeah. Yeah. Uh, that, no, that, that, that, that part universal accidental universal control plane, that's, that's, that, that'll be fun to think about for some time, you know, I don't know. There you go. Yeah, that's right. I try to convince my, my son that I have a very good control plane. He should just, you know, follow the configuration that is distributed to his nodes, but we'll, you know, you want to manage your kids like, uh, uh, like declarative systems, you know, I'll be done. I do not care how that's right. Uh, well, great. Well, this is, this has been, this has been fun. This has been great to, uh, to, to talk with you about this, this stuff and ask some questions. If, uh, if people wanted to turn into your, uh, you know, your, your T T G I K or like, see what else you're up to. What would you point them to a T G I K dot I O will take you to the YouTube playlist. Um, and generally, uh, Fridays at 1 PM Pacific, again, the worst time ever, uh, is a good place to go, uh, is the time, um, you know, Duffy's been doing more of them lately just because I've been too busy. Uh, uh, so thank you, Duffy. And, uh, and then we also have this other thing that I think for folks might be interesting called, uh, the cube Academy. So cube dot Academy, uh, has a bunch of, uh, content around learning Kubernetes, getting involved, understanding some of the basics. Uh, and, uh, yeah. So, uh, check that out. I w I want to see some for Richard from Richard so he can get that little like, uh, anti-alias version of his head down at the lower corner talking. We should, we should get more of that. That would be good. All right. Well, great. Well, uh, thanks again. Uh, that was fun. And as always, well, as for the past one or so episode, this has been Tanzu talk previously, Pivotal Conversations, as you may recall. And, uh, if you want to check out the, uh, the back catalogs one day, very soon with my copious free time, cause I don't have to travel. I'm going to go fix this up, but, uh, you can either go to a soundcloud.com slash Pivotal Conversations or soundcloud.com
44:57slash Tanzu talk. I think soundcloud is sane and they redirect old stuff. Even we'll rename it. So people of the future, I hope it's going well. And, uh, you can write back and tell me if it, uh, if it works, it'll, it'll be quite enjoyable. And with that, we'll see everyone next time. Bye-bye. All right. Thanks for having me on. Absolutely.