1 00:00:00,000 --> 00:00:02,660 All right. I'm going to start with your first guest, and then we'll get to Richard. 2 00:00:03,040 --> 00:00:07,860 This is Friday. For me, it's like 4.39 PM. I always want to say, well, first of all, 3 00:00:07,880 --> 00:00:11,900 let me parentheticalize. If I said central time, you would think US central time, right? 4 00:00:12,020 --> 00:00:16,200 So I got to be like central European time. I haven't figured out if the Europeans are like 5 00:00:16,200 --> 00:00:21,340 central European time. I don't think they're extremely time zone aware because they basically 6 00:00:21,340 --> 00:00:27,780 have one time zone. So I don't think that comes up. They're basically like, there's the one time 7 00:00:27,780 --> 00:00:35,220 zone and the English, and that's pretty. But anyways, as you're towards the end of the week 8 00:00:35,220 --> 00:00:40,340 here, you're wrapping up. What's the, whether planned or not, the kind of ritual you go through 9 00:00:40,340 --> 00:00:45,800 to sort of end out the week? What do you find yourself doing at the end of each week? 10 00:00:46,020 --> 00:00:53,140 A lot of times I'll do TGIK, which is the YouTube live stream where I play with stuff. And so that 11 00:00:53,140 --> 00:00:59,820 ends up being Friday afternoon here in Seattle. And it's like the worst time for the rest of the world 12 00:00:59,820 --> 00:01:05,640 for us to do a live broadcast. And so, you know, when I first set it up, it's like, you know, 13 00:01:05,700 --> 00:01:10,100 hey, that was a bad idea. And so, but we just stuck with it. So we have folks that are like, you know, 14 00:01:10,180 --> 00:01:11,580 tuning in the middle of the night. 15 00:01:11,580 --> 00:01:15,560 That is funny. Yeah. Yeah. It could only be worse if you were like in Hawaii or something. 16 00:01:15,820 --> 00:01:18,960 And then it would even be bad for the Californians. I mean, the West coasters. 17 00:01:20,020 --> 00:01:25,340 So, so that you have that to mark your week, basically doing a, a live, a live event, a live 18 00:01:25,340 --> 00:01:31,800 podcast. And is that a, is that good? Like, does that leave you here? And specifically on this, 19 00:01:32,260 --> 00:01:36,920 I've been thinking a lot recently, like every time I do a podcast, I get a little like charged up. 20 00:01:37,240 --> 00:01:43,280 And so there's one that I have to do at, well, I should say, sorry, I get to do at basically like 21 00:01:43,280 --> 00:01:48,260 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 22 00:01:48,260 --> 00:01:54,540 another four hours, but really like I should go to sleep. So like, like, no, it's super energizing 23 00:01:54,540 --> 00:01:59,780 to do these things. And, and so I haven't been able to do it for a while just because like I have 24 00:01:59,780 --> 00:02:05,940 a gazillion other things going on. And so there's a set of other folks that help out. Duffy has been 25 00:02:05,940 --> 00:02:10,480 taking, uh, one of our, uh, uh, field engineering folks, uh, has been taking on a lot of these 26 00:02:10,480 --> 00:02:16,220 stuff. He's great, huge, deep well of knowledge there. Um, but yeah, I'll like, like the worst 27 00:02:16,220 --> 00:02:21,520 is like when I would do that and then I would have an interview to, you know, hire somebody 28 00:02:21,520 --> 00:02:26,100 afterwards. And it'd be like, I am not in the right mindset to have sort of a thoughtful 29 00:02:26,100 --> 00:02:29,460 interview with people. Cause you are really charged up after doing those things. 30 00:02:29,840 --> 00:02:33,080 Yeah. Yeah. How about, okay. How about yourself, Richard, at the end of the week, 31 00:02:33,080 --> 00:02:37,100 what do you do to like, uh, is that when you read those 50 books that you read every 32 00:02:37,100 --> 00:02:40,400 week? What do you, uh, how do you, how do you kind of like shift out? 33 00:02:41,020 --> 00:02:45,660 Yeah. Uh, I find myself cleaning my desk and getting back to inbox zero. Like when I want 34 00:02:45,660 --> 00:02:50,400 to go into the, you are so virtuous, Richard. I don't know how I just, I need to have a clear 35 00:02:50,400 --> 00:02:54,020 mind. If I just walk out of here and then I'm, I'll be thinking about all through dinner 36 00:02:54,020 --> 00:02:57,400 or the weekends. I gotta, I gotta start the weekend with a clean slate. 37 00:02:57,660 --> 00:03:01,400 Okay. All right. That's a good, I, I could, I could take some advice from that. I, I think, 38 00:03:01,440 --> 00:03:07,120 you know, I've, we recently had to enter our, uh, some MBOs into our corporate thing and I've been 39 00:03:07,120 --> 00:03:10,800 thinking I need to go adjust some. And I've been thinking one of them needs to be learn from Richard, 40 00:03:11,100 --> 00:03:15,920 learn how to be more productive, clean your desk. So that's good. I'm going to put that on there. 41 00:03:16,160 --> 00:03:22,280 Uh, clean desk at least 45 times this year. And I think, uh, that's, that doesn't it. What are the 42 00:03:22,280 --> 00:03:27,440 things you're supposed to do? Make them smile, like a accountable, trackable, knowable and doable. 43 00:03:27,740 --> 00:03:31,920 There you go. Smart, not smile. That's close. It's very, it's more positive. Yeah. 44 00:03:33,080 --> 00:03:39,340 So my favorite like thing is when people share either screenshots or their desktop to present, 45 00:03:39,340 --> 00:03:43,760 like I was on one of these and the person, and I won't, I don't even remember who, 46 00:03:43,760 --> 00:03:49,200 but I won't out them. They literally had 3000, 30,000 unread messages on outlook. I'm like, 47 00:03:49,200 --> 00:03:54,620 I didn't know that could go that high. Or like when people share their like phone, uh, 48 00:03:54,620 --> 00:03:59,200 screenshots and their battery percentages down to like 5%. I'm like, how can you live like that? 49 00:03:59,540 --> 00:04:03,160 Yeah, I know. I screen grabbed those. There was somebody with like 90,000 last year and I had 50 00:04:03,160 --> 00:04:06,980 to shame them on Twitter afterwards. Cause that's just untenable. I don't, I don't know what you're 51 00:04:06,980 --> 00:04:10,760 doing with that. I think, I think, you know, in the future, I think, uh, psychologists and 52 00:04:10,760 --> 00:04:14,820 psychiatrists will study the people nowadays. And they realize that there's a, there's a part of 53 00:04:14,820 --> 00:04:18,960 your brain that at some point, if you stare at those big red 30,000 emails long enough, 54 00:04:18,980 --> 00:04:23,320 you just never see it. You just, it just is blocked out of your vision and you can't, uh, 55 00:04:23,320 --> 00:04:27,160 you can't encounter it. Well, that's good to know. I'm going to, I'm going to try to take some tips 56 00:04:27,160 --> 00:04:30,020 from that when we wrap up here, but why don't you introduce yourself guests? 57 00:04:31,020 --> 00:04:38,060 Well, uh, my name is Joe Bita. I'm a principal engineer at VMware, uh, joined VMware with the 58 00:04:38,060 --> 00:04:43,860 acquisition of Heptio a little over a year ago. Uh, Heptio was a company, uh, that I co-founded 59 00:04:43,860 --> 00:04:49,940 with Craig McLuckie to sort of bring Kubernetes to enterprises. And, uh, we bridge the gap between 60 00:04:49,940 --> 00:04:56,320 sort of the brave new world of cloud native and the reality of, uh, how most enterprise, uh, 61 00:04:56,320 --> 00:05:02,280 developers and it departments, uh, find themselves in. Uh, and then previous to that, uh, spent about 62 00:05:02,280 --> 00:05:08,380 10 plus years at Google, helped start the Kubernetes project, uh, started Google compute engine and, 63 00:05:08,560 --> 00:05:14,700 uh, yeah. And so I've been doing sort of developer platformy type stuff my entire career pretty much. 64 00:05:15,000 --> 00:05:21,640 So I, I, I remember, uh, there's some, well, first of all, I was just realizing you did a podcast 65 00:05:21,640 --> 00:05:26,300 with like, uh, I mean, I guess he's my best friend, Charles Lowell at the front side a while ago. 66 00:05:26,440 --> 00:05:30,940 And I was, I was looking through stuff and I was like, Oh look, there they are. That, you know, 67 00:05:30,940 --> 00:05:35,260 just, uh, I remember listening to that way back when. So that was, that was fun. But you know, 68 00:05:35,320 --> 00:05:39,500 you, you, you said a few phrases there that I think are interesting and worth, like given your focus, 69 00:05:39,600 --> 00:05:44,620 getting your, your perspective on, but like, what does that mean for the enterprise? Like how does, 70 00:05:45,200 --> 00:05:52,680 like when you use that phrase, like to, to, to, to maybe give some buckets here, like one, 71 00:05:52,680 --> 00:05:57,020 what problems are being solved there, but then too, the thing I've gotten more interested in 72 00:05:57,020 --> 00:06:03,560 recently is like what unique benefits or opportunities exist, uh, as well in the context 73 00:06:03,560 --> 00:06:10,060 of all of this. Yeah. I think, you know, the way that I, from a sort of platform cloud developer 74 00:06:10,060 --> 00:06:18,560 point of view, the way I would define enterprise is, uh, by and large folks dealing with, uh, legacy and 75 00:06:18,560 --> 00:06:23,500 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 76 00:06:23,500 --> 00:06:29,820 of processes, technology and existing systems, uh, and then folks dealing with a different risk 77 00:06:29,820 --> 00:06:37,300 profile, um, whether it be regulatory, whether it be, uh, uh, you know, uh, working worldwide 78 00:06:37,300 --> 00:06:43,320 introduces new problems. And so these are the types of things that I think are unique to more 79 00:06:43,320 --> 00:06:48,560 established, larger businesses and combined with the fact that traditionally they haven't viewed 80 00:06:48,560 --> 00:06:53,660 themselves as technology companies. And so they haven't actually built the focus and the culture 81 00:06:53,660 --> 00:07:00,180 and the, the, um, the thinking around using technology, using software as an accelerator. 82 00:07:00,580 --> 00:07:05,320 They've, you know, in a lot of cases, and I mean, it's over general generalizing, but in a lot of 83 00:07:05,320 --> 00:07:10,480 cases, they've, uh, viewed these things as cost centers and sort of costs of doing business versus 84 00:07:10,480 --> 00:07:14,840 things that it can actually accelerate the business. And I would contrast that with, I would say 85 00:07:14,840 --> 00:07:18,960 sort of tech forward businesses. Um, I don't want to say Valley businesses cause it's bigger 86 00:07:18,960 --> 00:07:24,140 than the Valley, but these are generally businesses that are younger, don't have a lot of that history 87 00:07:24,140 --> 00:07:30,360 to, to hold them back and fundamentally understand at a core level how technology is an accelerator 88 00:07:30,360 --> 00:07:37,920 for them. Not a, uh, uh, uh, not a sort of adjunct type of thing. Um, and when I say legacy, I'm super 89 00:07:37,920 --> 00:07:46,880 respectful of legacy. I think when a company has legacy systems, they're there because they're bringing 90 00:07:46,880 --> 00:07:52,220 in money. Those are the things that are running the business. If those things weren't valuable, if those 91 00:07:52,220 --> 00:07:56,260 things weren't critical to the business, they would have thrown these things away a long time ago. 92 00:07:56,260 --> 00:08:01,920 And so I think it's really about, you know, understanding that, you know, legacy equals 93 00:08:01,920 --> 00:08:07,740 critical business functions that have been proven over time. Yeah. And so figuring out how to bring 94 00:08:07,740 --> 00:08:13,660 that into the future without, uh, uh, without throwing away all the value that's been built over 95 00:08:13,660 --> 00:08:18,080 time. Um, and then I think there's also legacy from a process point of view. I think there's a lot 96 00:08:18,080 --> 00:08:24,120 of folks and I think this is, um, you know, coming to VMware, understanding a lot of the VMware 97 00:08:24,120 --> 00:08:30,920 customers, the VI admin, you know, you look at the processes and you can trace the lineage of these 98 00:08:30,920 --> 00:08:37,280 things back to when, you know, people bought machines from Dell or from whomever and rack and 99 00:08:37,280 --> 00:08:41,120 stack them, right? You file a ticket and three months later you get a machine. Well, virtualization 100 00:08:41,120 --> 00:08:45,600 means you file a ticket and two weeks later you get a machine. And I think one of the opportunities 101 00:08:45,600 --> 00:08:52,180 here is to just like CICD, which we can talk about is as you start to get these feedback loops 102 00:08:52,180 --> 00:08:57,560 quicker, more immediate, then it fundamentally changes the way that you build software and the 103 00:08:57,560 --> 00:09:02,780 way that you approach doing things. And so I think the jump to cloud is really about how does 104 00:09:02,780 --> 00:09:10,080 provisioning go from two weeks with tickets to API driven self-service elastic that you get 105 00:09:10,080 --> 00:09:15,500 with a cloud-like platform. Uh, and, and what are the implications for the business, for the 106 00:09:15,500 --> 00:09:19,180 development teams? And I think that's the huge opportunity there is there's, there really is 107 00:09:19,180 --> 00:09:24,820 sort of a tipping point or some sort of singularity as you get over that hump and you have infrastructure 108 00:09:24,820 --> 00:09:30,660 that can really, uh, keep up with, uh, application teams. Is there a process or part of the stack more 109 00:09:30,660 --> 00:09:34,960 specifically that you think that the, that existing company that impacts these buying cycles that maybe 110 00:09:34,960 --> 00:09:38,860 cloud broke or some of these new things are kind of breaking? Like, is there a specific thing that 111 00:09:38,860 --> 00:09:43,540 even a forward thinking hundred year old company deals with? Like what's that? Is it procurement? 112 00:09:43,780 --> 00:09:47,660 Is it like, what are those things that you come in and see? Like, yeah, even if I want to be forward 113 00:09:47,660 --> 00:09:49,420 thinking, it's hard because of X. 114 00:09:50,020 --> 00:09:54,860 I think a lot of it is just establishing a culture of trust across the organization. 115 00:09:55,360 --> 00:10:00,400 A lot of, when you look at sort of continuous deployment, it's, it's fundamentally a trust but 116 00:10:00,400 --> 00:10:05,540 verified type of thing. It's like, we have testing, we have processes, we can roll back. 117 00:10:05,900 --> 00:10:12,340 Those all enable you to be able to move fast and actually deal with breakage, deal with the eventualities. 118 00:10:12,700 --> 00:10:18,840 I think what we find with larger organizations is that over time, something bad happens, you introduce 119 00:10:18,840 --> 00:10:24,500 more process and that becomes a scar. And those scars build up over time. And I think everybody's 120 00:10:24,500 --> 00:10:29,640 operating in good faith, but it fundamentally changes the way that they view things to be risk adverse. 121 00:10:30,460 --> 00:10:34,800 And hey, you know, we need to protect ourselves from our, our, our engineers. And so I think 122 00:10:34,800 --> 00:10:40,840 the biggest thing holding back, you know, these companies is, um, essentially resetting that 123 00:10:40,840 --> 00:10:46,900 relationship between the IT platform teams and the developers. And I think the thing that's forcing 124 00:10:46,900 --> 00:10:54,240 the issue here is essentially, you know, uh, the fact that those application teams within organizations 125 00:10:54,240 --> 00:11:01,160 have choices now that they never had before with, you know, shadow IT. And, you know, if I'm a developer 126 00:11:01,160 --> 00:11:07,320 and, you know, it's going to take me, you know, two, four, six weeks to actually allocate stuff for an 127 00:11:07,320 --> 00:11:13,020 application, I need to get stuff done. I could go through and actually, you know, provision stuff on 128 00:11:13,020 --> 00:11:20,140 Amazon or Microsoft or wherever, get that done in a day, what would take me six weeks. And then, you know, 129 00:11:20,160 --> 00:11:24,880 it's easier to ask forgiveness and permission, right? Put that on my corporate credit card, ship the app, 130 00:11:24,900 --> 00:11:29,560 and then dare them to deny the expense and shut it down. And so I think what we find is that these 131 00:11:29,560 --> 00:11:35,220 centralized IT teams are having to compete for their own users in a way that they never have before. 132 00:11:35,620 --> 00:11:39,120 And I think that's the opportunity. I think what we're looking at with Tanzu, what we're looking at with 133 00:11:39,120 --> 00:11:45,240 Heptio, what I think, you know, Pivotal has traditionally done is how do we arm those IT teams so that they can 134 00:11:45,240 --> 00:11:50,760 be competitive for their own users when their own users, you know, can go to cloud directly 135 00:11:50,760 --> 00:11:56,480 and actually find the sweet spot between, you know, development teams being able to move fast, 136 00:11:56,600 --> 00:12:01,880 but still having the, you know, the mechanisms in place to control risk, to control spend, 137 00:12:01,880 --> 00:12:04,840 to understand the shape of how people are using IT. 138 00:12:05,720 --> 00:12:10,420 Do you think that internal developer, that enterprise developer has to choose things that 139 00:12:10,420 --> 00:12:15,740 feel more familiar to IT than that, let's say, forward-thinking or younger tech companies can say, 140 00:12:15,980 --> 00:12:20,380 screw it, we're going all Mongo, what the hell? Do you think, is there, do you see that or do you, 141 00:12:20,440 --> 00:12:24,180 are you seeing more freedom to say, forget it, we're bringing in Knative, hey, forget it, 142 00:12:24,200 --> 00:12:27,660 we're going to bring in Cassandra, we're going to bring in this completely new database that has 143 00:12:27,660 --> 00:12:31,700 four companies in their startup. Is that still a challenge or do I have to pick something that feels 144 00:12:31,700 --> 00:12:36,100 more familiar in the enterprise? The perspective that I take there is that, you know, every organization 145 00:12:36,100 --> 00:12:40,720 is different. I think sometimes it's, you know, when you talk to companies, they're a little bit 146 00:12:40,720 --> 00:12:44,880 like they're, you know, each is their own little Glockos Island where they've evolved certain ways, 147 00:12:44,980 --> 00:12:51,660 different processes, different ways of actually connecting things. And so I think some organizations, 148 00:12:51,920 --> 00:12:57,760 some businesses can take on some groups, application groups within that, that, that business can be 149 00:12:57,760 --> 00:13:01,620 a little bit more sort of forward-thinking in terms of adopting new technology. 150 00:13:02,300 --> 00:13:07,840 Others need to lock things down. Sometimes this is because, you know, the problem space that 151 00:13:07,840 --> 00:13:12,460 they're solving is pinned to some of these legacy systems. Like, hey, you know, mainframe sales are 152 00:13:12,460 --> 00:13:16,900 still on an upswing, right? This is not something that's going to go away anytime soon. Whereas I 153 00:13:16,900 --> 00:13:21,780 think other times it's more of a disconnected new motion where folks actually have the freedom to be 154 00:13:21,780 --> 00:13:27,220 able to, to adopt some of the latest and greatest. And so I think that, you know, across all of these 155 00:13:27,220 --> 00:13:33,140 things, we're seeing a, uh, uh, uh, you know, just adding to the challenges of actually maintaining 156 00:13:33,140 --> 00:13:38,040 IT within an organization because there is no one size fits all solution to, to any of these 157 00:13:38,040 --> 00:13:43,820 application problems. So yeah. And, and, uh, you know, thus far, I think, I think we've gone over 158 00:13:43,820 --> 00:13:50,000 many, uh, roles of, of people involved. I think, I think, you know, just to be clear, you were saying 159 00:13:50,000 --> 00:13:53,900 this as a, this is not a good thing to say, but I think it's very true. Like, you know, we have to 160 00:13:53,900 --> 00:14:00,540 protect ourselves from our engineers, which I think is, uh, a, uh, uh, strong mentality, uh, in the 161 00:14:00,540 --> 00:14:06,160 enterprise space. So, so we've got engineers there and then we have the, uh, I don't know, 162 00:14:06,220 --> 00:14:12,680 operations people. Um, and I think, I think there's a few other roles scurrying about, but like when in 163 00:14:12,680 --> 00:14:17,500 the, in this realm that we're talking about, as far as large organizations or enterprises kind of 164 00:14:17,500 --> 00:14:23,080 supporting their own stack of stuff to run software, what are the kind of roles that you see out 165 00:14:23,080 --> 00:14:28,840 there nowadays? Who are the, the people working on this? Well, I think the, um, 166 00:14:29,240 --> 00:14:36,620 so, you know, I'll, I'll often, you know, think about this as, as, uh, essentially a matrix with 167 00:14:36,620 --> 00:14:41,140 sort of four spots. I think there's platform and there's application and there's operations and 168 00:14:41,140 --> 00:14:48,200 developers. And most of the time we think about, uh, uh, platform operators and application developers. 169 00:14:48,760 --> 00:14:52,880 Uh, but I actually think that there's two other squares there that are super meaningful. 170 00:14:52,880 --> 00:14:58,500 Uh, specifically, I think that we see that there is a role for application operations, 171 00:14:58,500 --> 00:15:05,460 even in highly managed environments, there's a role for making sure that the application is up. It's 172 00:15:05,460 --> 00:15:11,620 reliable dealing with, you know, unexpected situations, capacity, build out all that stuff. 173 00:15:11,680 --> 00:15:16,660 I think in some teams, these things get sort of merged in a DevOps type of thing. I think in the 174 00:15:16,660 --> 00:15:22,780 organization, a lot of times DevOps ends up meaning, uh, at the application layer. Uh, so, 175 00:15:22,780 --> 00:15:27,620 you know, uh, I think there's a question of how far down the stack does a DevOps team go? 176 00:15:27,620 --> 00:15:33,600 I think in mature organizations, we want to see some split between platform applications. And so that 177 00:15:33,600 --> 00:15:38,980 the, the dev and the ops at that, uh, application layer, uh, are much more aligned towards actually 178 00:15:38,980 --> 00:15:44,300 delivering an experience for the application. And then the other interesting thing there is, uh, 179 00:15:44,300 --> 00:15:52,980 platform developers. And so platform developers end up being, you know, folks that, uh, uh, help to build 180 00:15:52,980 --> 00:15:59,460 tools, policies, extensions for the platform that actually really sort of fit it to that Galapagos 181 00:15:59,460 --> 00:16:05,040 Island. That is that organization that really helped to make sure that, uh, whatever platform that you're 182 00:16:05,040 --> 00:16:11,840 using is well adapted to the quirks and, uh, and, you know, unique situations of the org. And so I think 183 00:16:11,840 --> 00:16:17,280 that, you know, we've been neglecting some of the sort of the platform, uh, developers and the 184 00:16:17,280 --> 00:16:21,820 application operators to some degree, uh, when we talk about these things, but I think it's important 185 00:16:21,820 --> 00:16:25,880 for us to think about all those different roles and how they interact with each other. And then there's 186 00:16:25,880 --> 00:16:30,360 probably other things like you'll have your data team and, you know, you'll have, you know, that, 187 00:16:30,440 --> 00:16:33,700 that actually I think ended up being adjunct to these things. Cause I think these things end up 188 00:16:33,700 --> 00:16:38,240 being fractal, you don't have one platform team. You may actually have your data platform versus your 189 00:16:38,240 --> 00:16:42,720 compute platform versus your machine learning platform versus or whatever platform. Yeah. 190 00:16:43,040 --> 00:16:46,320 I'm, I'm always forgetting the data people. That's, that's unfortunate of me. I should, 191 00:16:46,380 --> 00:16:51,420 I should be more polite, but I think, you know, there's a couple of things that, that, that you're 192 00:16:51,420 --> 00:16:55,780 saying there that I, I, I think a lot about. And one of them is, uh, well, you know, in my more 193 00:16:55,780 --> 00:17:00,500 exciting moments to think about these kinds of topics, but it is like you mentioned this briefly, 194 00:17:00,500 --> 00:17:08,340 but I have been wondering like what DevOps means nowadays, like, like it's very, like, 195 00:17:09,240 --> 00:17:13,520 and I, I, I go back and forth between this. Like, I don't, I don't, I mean, I know this kind of 196 00:17:13,520 --> 00:17:17,940 connection is a little like fraught with whatever, but like, I always kind of think that like when 197 00:17:17,940 --> 00:17:23,840 people kind of understood or, or became knowledgeable of SRE stuff, it was kind of like, 198 00:17:23,840 --> 00:17:28,940 well, is this, what does this suck all the DevOps people down into this or, or not? Right. Or, 199 00:17:29,380 --> 00:17:33,920 or, you know, is it more of a yes and situation or, you know, like what, what's going on with this? 200 00:17:34,000 --> 00:17:40,120 But then the other, the other view that comes up that I don't hear a tremendous amount about is, 201 00:17:40,200 --> 00:17:45,260 is what you were just saying is that to some extent DevOps is more about like, and I'm putting 202 00:17:45,260 --> 00:17:49,960 words into your mouth or describing the ones in mind here, but like DevOps is more about like 203 00:17:49,960 --> 00:17:56,140 application developers, like understanding networking and understanding like how to write applications 204 00:17:56,140 --> 00:18:03,440 that are not only observable, but like that run well. And, and, and that like actually are architected 205 00:18:03,440 --> 00:18:11,040 like purposefully to like run in an environment well. And it is like, I don't, I think, I think overall 206 00:18:11,040 --> 00:18:18,020 to, to personify it, like the DevOps idea has like some thinking to do as far as like, like what, 207 00:18:18,020 --> 00:18:23,540 what identity does it want at this point? Because it really, it could be all over the map. Like it's, 208 00:18:23,660 --> 00:18:28,640 I mean, as I just demonstrated, it's hard to know exactly what, what a, what a DevOps is to put it 209 00:18:28,640 --> 00:18:35,160 in a jokey way. Well, I think, you know, uh, uh, I was having drinks with Kelsey Hightower at one 210 00:18:35,160 --> 00:18:41,980 point. Uh, uh, and, uh, and he, he described DevOps as sort of group therapy for large organizations. 211 00:18:42,980 --> 00:18:50,160 Yeah, yeah, yeah, exactly. Um, I do think though that there is, um, you know, I love these industry 212 00:18:50,160 --> 00:18:54,620 terms that are underdefined that people just argue on Twitter about what the hell they mean. And there's 213 00:18:54,620 --> 00:19:01,240 like no right answer to it. Um, from my point of view, the main learning from DevOps in general is 214 00:19:01,240 --> 00:19:07,980 that application people have to care about how their stuff runs in production. Yeah. Uh, and, uh, 215 00:19:07,980 --> 00:19:16,000 and operators have to be thinking about, uh, uh, completing that feedback loop such that systems 216 00:19:16,000 --> 00:19:21,600 become more operable over time. Uh, I think, you know, one of the, one of the questions in my mind 217 00:19:21,600 --> 00:19:25,860 is again, how far down the stack does DevOps go? I think in small organizations and startups, 218 00:19:25,860 --> 00:19:29,800 you end up everybody doing anything, everything. So you end up with that whole full stack, 219 00:19:30,000 --> 00:19:36,640 you know, uh, uh, idea. I think as we move to more mature organizations, I think we, what we get 220 00:19:36,640 --> 00:19:42,100 into is sort of ops specialization where you don't have somebody dealing with the entire stack. You have 221 00:19:42,100 --> 00:19:47,440 them actually dealing with parts of the stack in more specialized way. Um, and I think, you know, 222 00:19:47,500 --> 00:19:53,020 figuring out how that coexists with sort of the DevOps mentality, uh, is, uh, is I think something 223 00:19:53,020 --> 00:19:57,880 that's worthwhile, but I think, I think for the future of building reliable systems that are scalable, 224 00:19:57,880 --> 00:20:04,660 that are, you know, uh, modern, uh, you know, you can't be ignorant of, of how your application 225 00:20:04,660 --> 00:20:09,560 code runs in production. It's just not acceptable these days. Uh, I think that's, that's the root of, 226 00:20:09,560 --> 00:20:14,720 of DevOps for me. Yeah. And I think, I think it's a sufficiently interesting riddle for most 227 00:20:14,720 --> 00:20:20,240 application developers to be fascinated by nowadays. Right. Like I think, I think, I don't know, 228 00:20:20,260 --> 00:20:24,000 we've all been developers or are, or whatever. Like, I think you throw a riddle in front of a 229 00:20:24,000 --> 00:20:29,520 developer, your job is done, right? Like you can, you can sway them to be interested and do the right 230 00:20:29,520 --> 00:20:35,920 thing. If you phrase the riddle correctly, uh, which, which is, uh, nice. So, I mean, so, so given 231 00:20:35,920 --> 00:20:41,700 that Joe, should application developers deeply understand Kubernetes or are there just some primitives 232 00:20:41,700 --> 00:20:46,320 they should grok and the rest of it should be left to an abstraction served up by that platform 233 00:20:46,320 --> 00:20:50,700 dev team? Like how, how deep do I need to go as a dev? It depends on what you're working on. 234 00:20:50,960 --> 00:20:57,100 I think, you know, uh, you know, probably, and I'm pulling numbers out of nowhere here, 235 00:20:57,100 --> 00:21:03,580 but like, you know, I'm guessing 80, 90% of enterprise applications are crud apps with a 236 00:21:03,580 --> 00:21:08,900 little bit of business logic that don't have huge scalability requirements. Um, you know, 237 00:21:08,900 --> 00:21:15,160 for that type of thing, you know, uh, understanding the underlying platform that you're running on is 238 00:21:15,160 --> 00:21:21,940 probably not necessary. Uh, now if you're say building a video, video encoding, you know, 239 00:21:22,000 --> 00:21:27,960 pipeline, or you're doing machine learning, or you're dealing with extreme scale, or if you have 240 00:21:27,960 --> 00:21:34,500 problems that involve, you know, things that are replicated and, uh, available across the globe, 241 00:21:34,500 --> 00:21:40,420 that'll start introducing some unique problems where, you know, as an engineer, you have to be 242 00:21:40,420 --> 00:21:46,340 able to go deep and understand the, the trade-offs that you're, you know, that you're working on. I 243 00:21:46,340 --> 00:21:50,140 think, you know, we love to use car analogies here. Like how many people need to understand how 244 00:21:50,140 --> 00:21:55,380 an internal combustion engine works, right? Like most people don't, but if you're a race car driver, 245 00:21:55,480 --> 00:21:59,780 yeah, of course you do. Right. If you're a long haul trucker, you probably understand a lot more 246 00:21:59,780 --> 00:22:04,980 about how your vehicle works than if you're just going to the grocery store. And so the, uh, you 247 00:22:04,980 --> 00:22:09,320 know, I think that there's different, different problem domains that require different types of, 248 00:22:09,320 --> 00:22:16,080 uh, uh, uh, uh, understanding of the underlying platform. Now that being said, I think that there's 249 00:22:16,080 --> 00:22:20,740 different types of developers in terms of how they think and how they, uh, approach these things. Uh, 250 00:22:20,740 --> 00:22:25,260 you know, one way that I like to think about it is, you know, you'll have depth first versus 251 00:22:25,260 --> 00:22:29,680 breadth first sort of developers. I think there's folks who are like, Hey, how do I get something 252 00:22:29,680 --> 00:22:34,560 done? You know, I ran this, it seems to work fine. Ship it. I'm done. Right. And I think that, 253 00:22:34,560 --> 00:22:40,300 you know, they're very much focused on the result and what is my quickest time to result. And, uh, 254 00:22:40,880 --> 00:22:45,560 and you know, I'm a systems person. I've done development stuff. I'm very much the depth first 255 00:22:45,560 --> 00:22:51,320 type of person. I want to understand like when I run this thing, where's the main, what is the event 256 00:22:51,320 --> 00:22:55,980 loop look like? How does this interface to the network? Well, you know, like I want to understand 257 00:22:55,980 --> 00:23:02,160 this stack all the way down to the hardware. And, uh, it means that sometimes I operate a lot slower, 258 00:23:02,160 --> 00:23:07,240 but it also means that, you know, I can maybe foresee problems that, uh, you're not going to 259 00:23:07,240 --> 00:23:11,120 foresee if you're just sort of focused on that. Hey, it seems to work, ship it type of mentality. 260 00:23:11,120 --> 00:23:13,860 And I think there's, there's pros and cons to both approaches there. 261 00:23:14,100 --> 00:23:19,380 Yeah. So quick one more follow-up to that though. So I can't twist this into the car analogy, 262 00:23:19,380 --> 00:23:25,460 do enough people who might be using Kubernetes as their destination, do they need to know things 263 00:23:25,460 --> 00:23:30,420 like config maps or secrets? They need to might, maybe they'll write a CRD or run a cron. So can 264 00:23:30,420 --> 00:23:34,400 you just be like, I'm just getting in my car and driving to the grocery store or for a lot of devs, 265 00:23:34,440 --> 00:23:38,020 do you see them wanting to use some of those primitives in their actual app architecture? 266 00:23:38,820 --> 00:23:44,000 I think that, uh, it's an evolving story. I think that there are ways to use Kubernetes, 267 00:23:44,220 --> 00:23:48,480 especially if you have a platform team that's, that's supporting you where you just throw code 268 00:23:48,480 --> 00:23:54,240 at it. I think we still got a ways to go to actually make it work that way. Uh, I also think 269 00:23:54,240 --> 00:24:01,620 that the way that Kubernetes works as a distributed system has lessons that can apply to the application 270 00:24:01,620 --> 00:24:06,060 domain also. Right. And I think, you know, when I go deep into this about like level triggered versus 271 00:24:06,060 --> 00:24:12,320 edge triggered things, how contrast this to sort of like, you know, uh, event streaming systems using 272 00:24:12,320 --> 00:24:18,160 Kafka as sort of one way versus the way that Kubernetes works, where you have controllers 273 00:24:18,160 --> 00:24:22,940 that do state reconciliation. I think there's useful patterns to be able to extract out of Kubernetes 274 00:24:22,940 --> 00:24:28,180 that you can apply to your application level if you need to. And I think we're still figuring some 275 00:24:28,180 --> 00:24:37,680 of that stuff out. Um, I, I also think that, you know, there is, you know, a, uh, uh, a maturity curve 276 00:24:37,680 --> 00:24:43,040 for any technology. And I think there's a lot of folks that, uh, get deep into Kubernetes where maybe 277 00:24:43,040 --> 00:24:47,860 they don't have to. I don't think that's necessarily a bad thing. I think, you know, they're, they're going 278 00:24:47,860 --> 00:24:53,260 to be, uh, essentially seed crystals and sort of fonts of knowledge within their organization to be able 279 00:24:53,260 --> 00:24:57,760 to deal with some of the, the more, you know, problems that do start involving the, uh, the 280 00:24:57,760 --> 00:25:03,280 underlying platform. You know, I, I have a huge amount of respect for folks that, you know, uh, 281 00:25:03,860 --> 00:25:08,720 don't let themselves be constrained by boundaries, right? When they see a problem, they want to chase 282 00:25:08,720 --> 00:25:14,100 it down. They want to understand, you know, uh, uh, and, and, you know, Hey, you know, maybe that's a 283 00:25:14,100 --> 00:25:17,700 kernel problem. Okay. I'll start reading the kernel code. Right. Like, I think that is a skill 284 00:25:17,700 --> 00:25:21,620 set that certain developers have that I think is worthwhile. So yeah, I think there's pros and 285 00:25:21,620 --> 00:25:27,840 cons to this. I think sometimes people overdo it and we definitely have, you know, a distance to go 286 00:25:27,840 --> 00:25:32,620 in terms of making Kubernetes more turnkey. And I think that's a big part of what we're working on 287 00:25:32,620 --> 00:25:38,640 at VMware, uh, especially as we bring in a lot of the experience from pivotal. Um, now you mentioned 288 00:25:38,640 --> 00:25:43,320 config maps directly here. And I think one of the things that I think is worth looking at is the 289 00:25:43,320 --> 00:25:49,660 config system that comes with spring. How does that actually interact with the underlying platform? 290 00:25:49,660 --> 00:25:54,980 And are there ways for us to bring those things closer together and take some of the, the knowledge 291 00:25:54,980 --> 00:25:59,320 and the experience from spring and make that be more integrated, more applicable in a polyglot type 292 00:25:59,320 --> 00:26:05,240 of way? I think that, you know, understanding how config works in spring is a similar type of level of 293 00:26:05,240 --> 00:26:08,320 depth to understanding how config maps work in Kubernetes. 294 00:26:08,460 --> 00:26:14,920 Where is that line where, uh, it's sort of like, this is spring stuff and this is like Kubernetes stuff. 295 00:26:14,920 --> 00:26:21,680 And, and like, especially with like service mesh stuff running around, like it gets a little blurry 296 00:26:21,680 --> 00:26:27,740 there. Like, which is as far as I remember, it's sort of like, it's official, it's blurry by design, but, 297 00:26:27,860 --> 00:26:32,840 but like, what, what, what do you think? Like, where is the layer where it's like, not the, not the 298 00:26:32,840 --> 00:26:39,540 platform developers deal, like to, to think about solving and it gets pushed up, pushed up. I'm 299 00:26:39,540 --> 00:26:44,240 trying to be nonjudgmental my phrasing. It is a, uh, it's a delightful riddle for the application 300 00:26:44,240 --> 00:26:46,180 developers to, uh, to solve. 301 00:26:47,480 --> 00:26:53,280 I think, um, yeah, that is a blurry line and we're still figuring it out. I mean, if we look at the, 302 00:26:53,280 --> 00:26:58,680 the history of service meshes, it started with the finagle stuff coming out of Twitter, 303 00:26:58,680 --> 00:27:04,320 which was essentially a Java library, the buoyant folks broke that out as a sidecar 304 00:27:04,320 --> 00:27:15,020 with link or D and that predated Istio. And so we have this, uh, uh, this dichotomy between 305 00:27:15,020 --> 00:27:22,200 what functionality are we going to implement as libraries that sit in your, uh, uh, in your 306 00:27:22,200 --> 00:27:27,900 application and what functionality is actually going to be, you know, quasi system where it actually is 307 00:27:27,900 --> 00:27:32,860 applied and managed from the outside. And I think that there's, there's even further sort of lines 308 00:27:32,860 --> 00:27:36,340 between that. I think, you know, one of the interesting things is that we look at service 309 00:27:36,340 --> 00:27:41,040 mesh and we think, Oh, this is something that operates at the networking level with some IP tables, 310 00:27:41,100 --> 00:27:47,420 magic to redirect traffic to an envoy or link or D or whatever. Right. But I think we also can look 311 00:27:47,420 --> 00:27:52,960 at other systems that are starting to use sidecars for other types of value ads. Um, I'm thinking 312 00:27:52,960 --> 00:27:57,460 something like cloud state from the ACA folks, right? This is about essentially doing 313 00:27:57,460 --> 00:28:02,660 distributed state management as implemented in a sidecar. So taking a bunch of the stuff that was 314 00:28:02,660 --> 00:28:10,440 built out there and extracting that into essentially a system service that any, uh, workload can use. 315 00:28:10,540 --> 00:28:16,100 That's an interesting evolution as we see this stuff happen. Uh, another, uh, place where we see this 316 00:28:16,100 --> 00:28:23,240 is dapper from Microsoft where essentially it's a service mesh type of thing, but much more, uh, uh, 317 00:28:23,240 --> 00:28:28,240 integrated with the application in terms of like, if I want to talk to another service, I talk to a local 318 00:28:28,240 --> 00:28:33,520 host endpoint and the routing to which service I want to talk to is built into the path of the HTTP 319 00:28:33,520 --> 00:28:40,920 endpoint that I'm talking to. Right. So it still has a lot of the sort of, uh, um, uh, qualities of a service 320 00:28:40,920 --> 00:28:46,880 mesh, but it's much more application aware. And so I think we're seeing sort of this dichotomy and transition 321 00:28:46,880 --> 00:28:53,180 between sidecars and fat clients, you know, fat libraries that is going to be evolving over time. And I think 322 00:28:53,180 --> 00:28:57,100 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 323 00:28:57,100 --> 00:29:02,600 looking to, to, you know, uh, learn from and talk to and collaborate with the spring folks around 324 00:29:02,600 --> 00:29:08,380 is, you know, how can we actually, you know, bring some of the lessons and the experience and the 325 00:29:08,380 --> 00:29:14,300 technology and spring into a wider world and create more interoperability there so that, you know, 326 00:29:14,300 --> 00:29:20,480 so that we can break down silos and create, uh, a network effect that goes beyond a single framework. 327 00:29:21,480 --> 00:29:25,720 Yeah. Yeah. I was just, you know, you're drawing up an image of like, remember those old black and 328 00:29:25,720 --> 00:29:32,440 white Disney cartoons where there's like a gigantic, like fat dog and a tiny model T Ford, except like 329 00:29:32,440 --> 00:29:38,040 jammed into a sidecar that they sit, they sit down on the other end of the motorcycle picks up and then 330 00:29:38,040 --> 00:29:43,420 they, uh, they bounce along as they're driving, probably hitting someone on the head. And, and, 331 00:29:43,420 --> 00:29:50,740 and it's been fascinating because this whole sidecar thing, um, uh, uh, you know, there was a, 332 00:29:50,840 --> 00:29:54,620 there was an evolution going on in Google around the same thing. So traditionally Google had three 333 00:29:54,620 --> 00:30:01,380 languages that people developed in, this was, uh, uh, C plus plus Java and go, I would not go and, uh, 334 00:30:01,380 --> 00:30:08,740 Python and, uh, um, and for Java and Python, they were able to use Swig to be able to actually, 335 00:30:08,740 --> 00:30:13,760 you know, thunk down to the C plus plus libraries. And so they would write a lot of functionality in the 336 00:30:13,760 --> 00:30:21,120 monorepo, and then you could access it from any of the platforms. And, um, and one of the, one of the sort of 337 00:30:21,120 --> 00:30:26,120 implications of this is that you would find a bug in one of those core libraries and then you would 338 00:30:26,120 --> 00:30:30,400 tell everybody, okay, every team now has to rebuild, right? It was like, you'd come in on a Monday 339 00:30:30,400 --> 00:30:33,840 morning and you'd get this email going like, well, this week is going to suck because I have to 340 00:30:33,840 --> 00:30:39,080 actually, you know, rush a release out to deal with this critical issue. And so, you know, Google 341 00:30:39,080 --> 00:30:43,160 has, you know, internally, and it's, it, the, the, the form and the shape has taken a different, 342 00:30:43,160 --> 00:30:48,240 different sort of way, but Google internally has actually started figuring out how to take that 343 00:30:48,240 --> 00:30:53,880 stuff extracted into a sort of separate binary to deliver that functionality out of band of, 344 00:30:53,880 --> 00:30:58,500 of, uh, of, you know, libraries. Um, and so, yeah, it's going to be interesting to see how this 345 00:30:58,500 --> 00:31:02,740 actually starts to play out across, uh, other, other frameworks and other languages. 346 00:31:02,840 --> 00:31:07,480 Yeah. Interesting. Can you, uh, switching gears, can you tell us kind of what gets you 347 00:31:07,480 --> 00:31:12,560 interested, excited about some of the work that was called Pacific now vSphere Kubernetes? Like that 348 00:31:12,560 --> 00:31:16,460 seems like that was a good heck of an engineering effort. I'm sure it was well underway by the time 349 00:31:16,460 --> 00:31:21,160 Heptio came in, but you still had some fingerprints on it. Like that's not just a, just, just kind of 350 00:31:21,160 --> 00:31:25,280 bolted on. It's not something that, I don't know, to me coming in, that feels like that's kind of a 351 00:31:25,280 --> 00:31:29,380 big deal. But as you look at that, am I right? And why do you think that is? 352 00:31:30,140 --> 00:31:34,340 Yeah. So I think, you know, when we talk about Pacific, there's really sort of three parts of 353 00:31:34,340 --> 00:31:38,640 Pacific that are worth digging into. And I think each of these things are exciting in their own way. 354 00:31:39,100 --> 00:31:45,960 So the first thing to recognize is that vSphere for all the talk of private cloud and all that 355 00:31:45,960 --> 00:31:50,300 was really viewing cloud from the point of view of the infrastructure providers. How do I use 356 00:31:50,300 --> 00:31:55,960 virtualization? How do I create automation for allocation? How do I, you know, create, you know, 357 00:31:56,000 --> 00:32:03,760 more, uh, efficiencies for the VI admin? And I think, you know, it, it, it did a great job around that 358 00:32:03,760 --> 00:32:09,020 traditionally. But, you know, as developers, we recognize that there's a whole nother side of 359 00:32:09,020 --> 00:32:15,520 cloud and that's the API driven self-service and elastic aspects of it. And traditionally, you know, 360 00:32:15,820 --> 00:32:21,760 you know, being able to write a program that launches a VM or allocates networking resources 361 00:32:21,760 --> 00:32:27,740 has been a difficult thing on top of vSphere. And so the first thing that vSphere is doing as part of 362 00:32:27,740 --> 00:32:35,480 specific Pacific is, um, reusing Kubernetes as the control plane in the API surface area for exposing, 363 00:32:35,480 --> 00:32:40,400 uh, IaaS concepts in vSphere. And so this is useful, even if you don't give a crap about 364 00:32:40,400 --> 00:32:47,580 Kubernetes, because what it means is that there's now a ecosystem and tools and API sort of gestalt 365 00:32:47,580 --> 00:32:54,800 or way of doing things that, you know, starts to allow developers to interact with vSphere as if 366 00:32:54,800 --> 00:33:01,320 vSphere were a cloud. And so really about, you know, taking, you know, the experience that you get 367 00:33:01,320 --> 00:33:07,500 on public cloud as a application team and bringing that to vSphere. And that's based on top of 368 00:33:07,500 --> 00:33:11,780 Kubernetes API concept. And so I think there's a whole talk thread I can do around Kubernetes being 369 00:33:11,780 --> 00:33:16,580 a platform for platforms and universal control planes and stuff like that. So I think that's super, 370 00:33:16,700 --> 00:33:21,760 super exciting. The next thing is, you know, but that's at sort of the API control plane level. 371 00:33:21,920 --> 00:33:26,700 The next thing is like at the fundamental virtualization level, there is an effort to 372 00:33:26,700 --> 00:33:33,220 build Kubernetes support deep into vSphere, into ESX. So being able to blur the lines between VMs and 373 00:33:33,220 --> 00:33:38,420 pods and containers. Uh, this is essentially, you know, in some ways an evolution of some of the, 374 00:33:38,420 --> 00:33:45,600 the, uh, uh, containerization work that has been done before, but there's a much larger ecosystem of 375 00:33:45,600 --> 00:33:52,020 folks building on top of Kubernetes that now becomes, uh, uh, you know, essentially supercharged 376 00:33:52,020 --> 00:33:57,520 with the capabilities that you get on top of vSphere. And so in some ways, when we look at sort of, 377 00:33:57,560 --> 00:34:02,240 you know, Amazon building Fargate as a way to accelerate and bring some special sauce to, 378 00:34:02,380 --> 00:34:08,100 to Kubernetes or, uh, as you're doing as your container instances as a way of doing this, 379 00:34:08,160 --> 00:34:12,720 we're, we have a similar thing. I think it ended up getting named the VMware container service, 380 00:34:12,720 --> 00:34:18,220 which ends up our VMware pod service, I believe is that, which ends up being a way to, uh, uh, 381 00:34:18,220 --> 00:34:24,580 essentially have, uh, you know, uh, a special capabilities that blur the lines between VMs and 382 00:34:24,580 --> 00:34:31,540 brings VMware's huge history around virtualization to the container world. And then the third sort of 383 00:34:31,540 --> 00:34:38,500 leg of Pacific is, uh, integrating, um, you know, what we're calling, uh, Tansu Kubernetes grid, 384 00:34:38,500 --> 00:34:43,480 which is a way to walk up and say, give me a cluster, delete a cluster, scale this cluster, 385 00:34:43,660 --> 00:34:48,960 upgrade the cluster, really bringing sort of a modern Kubernetes service, whether, you know, 386 00:34:48,960 --> 00:34:57,520 something comparable to GKE, TK, uh, TKG, uh, GKE, AKS, EKS, that type of mentality, bringing that 387 00:34:57,520 --> 00:35:03,520 and building that on top of, uh, that new API surface area that we have, uh, you know, building 388 00:35:03,520 --> 00:35:08,280 on top of a bunch of stuff that we're driving upstream in Kubernetes. And so it really gives 389 00:35:08,280 --> 00:35:14,320 sort of that scalable self-service clusters as cattle type of mentality to vSphere. And so I think 390 00:35:14,320 --> 00:35:19,660 all three of those things are super exciting, are bringing a ton of value to, uh, to, uh, vCF4, 391 00:35:19,780 --> 00:35:25,100 vSphere 7 customers. Yeah. It seems like some cool engineering there. Can you define the native pods 392 00:35:25,100 --> 00:35:28,360 for me? I mean, I've read about them a little bit. I think it's interesting. I, it seems like 393 00:35:28,360 --> 00:35:33,280 it's a convergence of a lot of different types of tech. So what is that in our world and why should 394 00:35:33,280 --> 00:35:38,340 a customer care about them? Well, I think, you know, when we look at this technology, it's really 395 00:35:38,340 --> 00:35:44,060 about how, you know, and, and when we were, when we were launching Kubernetes and GKE, we had this 396 00:35:44,060 --> 00:35:48,100 discussion of like how much of the virtual machine that you're running on should be visible in 397 00:35:48,100 --> 00:35:53,520 Kubernetes. And I think, you know, uh, because of where the industry was at, we made that idea of the 398 00:35:53,520 --> 00:36:00,940 node very visible. Um, and I think that that was a, uh, uh, uh, absolutely critical for adoption for 399 00:36:00,940 --> 00:36:05,540 folks to understand what's happening around the covers. I think we've moved into a new phase where 400 00:36:05,540 --> 00:36:10,840 I think we finally have hit a point where, uh, folks using Kubernetes can say, run this. I don't care 401 00:36:10,840 --> 00:36:15,600 where it runs. I just want the system to be able to do it. And so now the question is, is that how can 402 00:36:15,600 --> 00:36:22,580 we, uh, you know, blend the virtual machine runtime and the container runtime in ways to enhance security 403 00:36:22,580 --> 00:36:27,820 and performance and efficiency across these things, um, and isolation, right? And I think, um, 404 00:36:28,060 --> 00:36:34,580 as you start, so, so essentially what these things end up being is highly optimized special purpose VMs 405 00:36:34,580 --> 00:36:40,600 that are sort of instantiated on demand to wrap pots. Uh, and so the integration with, uh, uh, 406 00:36:40,600 --> 00:36:48,720 uh, uh, you know, uh, storage and, um, uh, and, uh, container image management and networking, 407 00:36:48,720 --> 00:36:53,080 those are a bunch of the hard problems that you have to start facing when you start doing these 408 00:36:53,080 --> 00:36:58,500 sort of, you know, you know, shrink wrap VMs around pots. Um, now one of the, the, the good 409 00:36:58,500 --> 00:37:03,380 benefits of this is that, you know, ESX in terms of dealing with scheduling and isolation, 410 00:37:03,380 --> 00:37:11,540 uh, is, you know, honestly has, uh, uh, a richer history and a better, you know, more functionality 411 00:37:11,540 --> 00:37:17,740 than, um, than container technology on top of, of raw Linux. And so we'll actually see things 412 00:37:17,740 --> 00:37:26,060 where, uh, even on, uh, compared to bare metal, uh, uh, you know, these, uh, native pods or these, 413 00:37:26,060 --> 00:37:30,260 these, uh, V pods, right? We're still coming up with the right name for them. The, the, 414 00:37:30,260 --> 00:37:36,860 the V sphere pod service can actually outperform bare metal because of things like being smart 415 00:37:36,860 --> 00:37:42,060 about Numa architectures and hyper threat assignments and memory layout and that type of 416 00:37:42,060 --> 00:37:46,480 stuff. And so that can actually give you a performance increase when running virtualized 417 00:37:46,480 --> 00:37:51,480 over actually bare metal Kubernetes. And so I think there's some really, really, uh, interesting 418 00:37:51,480 --> 00:37:57,500 and somewhat non-intuitive results of bringing the deep expertise around virtualization to the 419 00:37:57,500 --> 00:38:02,600 Kubernetes world. So as a, as a last question, I was asking, uh, uh, when I talk with Don Foster, 420 00:38:02,600 --> 00:38:07,780 I asked her this and, uh, so it'd be fun to compare answers, but like, so broadening out 421 00:38:07,780 --> 00:38:13,020 beyond the lowercase V world that, that we love so much, like what, what, what is the Kubernetes 422 00:38:13,020 --> 00:38:23,380 community want? Um, you know, that's a good question. Um, you know, as somebody who's, 423 00:38:23,380 --> 00:38:29,200 you know, I'm not part of the Kubernetes steering committee now, but I, but I was, uh, as you 424 00:38:29,200 --> 00:38:35,680 know, one of the founders of the project, I think our goal was to make Kubernetes boring, 425 00:38:35,680 --> 00:38:40,860 uh, get to the point where it's rock solid and people build confidence on building on top 426 00:38:40,860 --> 00:38:49,380 of it. And so a big part of that effort was to try and sort of freeze the core of what Kubernetes 427 00:38:49,380 --> 00:38:54,720 is and create extension points so that a larger ecosystem can form around it. 428 00:38:54,820 --> 00:38:55,820 To stabilize it. 429 00:38:56,620 --> 00:39:03,640 Yeah. And so, you know, and so I think that our goal, and I think, you know, and, and again, 430 00:39:03,660 --> 00:39:07,020 like what is the community? I don't know. I'm not sure. I mean, the community is very diverse, 431 00:39:07,020 --> 00:39:12,440 which is a good thing, but our goal is to actually not be gatekeepers to people doing interesting 432 00:39:12,440 --> 00:39:17,300 stuff in this, in this world. Um, and so when you go to a KubeCon, when you look at that 433 00:39:17,300 --> 00:39:24,420 crazy CNCF, you know, I chart, um, you know, it's kind of a beautiful chaos, right? I mean, 434 00:39:24,420 --> 00:39:29,060 that is a sign of innovation when people are trying so many different things, they're experimenting, 435 00:39:29,300 --> 00:39:35,420 they're innovating. I think that's made possible by Kubernetes, not trying to do too much and 436 00:39:35,420 --> 00:39:43,100 concentrating on extensibility and a solid core versus, uh, uh, versus on trying to solve every 437 00:39:43,100 --> 00:39:49,180 problem for every person. And so I think the, and I think this is an interesting comparison of 438 00:39:49,180 --> 00:39:55,020 Kubernetes to perhaps some other platform type of projects where we want to provide a kernel that 439 00:39:55,020 --> 00:40:00,940 can be used in a bunch of different places versus trying to actually identify and solve scenarios in a 440 00:40:00,940 --> 00:40:06,280 vertical way. Uh, and again, it's a much more bottoms up sort of systems type of, uh, you know, 441 00:40:06,360 --> 00:40:13,760 Unix philosophy type of thing, uh, versus a, you know, uh, uh, a much more curated, what is the 442 00:40:13,760 --> 00:40:18,940 story? Who's the user? Who's the persona? Let's solve for them type of story. Um, and I think, 443 00:40:18,980 --> 00:40:22,920 you know, there's pros and cons there again, beautiful chaos. It's beautiful and it's chaotic. 444 00:40:22,920 --> 00:40:29,080 It's intimidating. I think one of the jobs that we have as a vendor in this space is to bring 445 00:40:29,080 --> 00:40:34,720 opinion to actually bring best practices, help people navigate this world without cutting them 446 00:40:34,720 --> 00:40:40,460 off from it. So that way we can get them started. We can make sure that they see value, but then 447 00:40:40,460 --> 00:40:45,280 as they look to benefit from this, this larger ecosystem, they're able to do that. And that's, 448 00:40:45,380 --> 00:40:50,160 that's one of the things that I'm focused on is, is how do we build a blended approach that, uh, 449 00:40:50,160 --> 00:40:55,420 uh, delivers immediate value for those who don't want to be Kubernetes experts, but then also as they 450 00:40:55,420 --> 00:41:00,580 get more familiar as they have specialized needs, they're not, uh, uh, they're not in a situation 451 00:41:00,580 --> 00:41:05,940 where they have to reset things and go to raw VMs again. Yeah. Yeah. No, that's good. That, that, 452 00:41:05,940 --> 00:41:12,800 that actually, that, that kind of, uh, organizes a lot of, of, uh, what that chaos looks like in the, 453 00:41:12,800 --> 00:41:18,340 in the sense of like, in the sense of like, here's, here's kind of like the, the ground for a commons 454 00:41:18,340 --> 00:41:23,480 area. And then we want people to come on to the commons and do stuff. Right. Like, and, and, uh, 455 00:41:23,480 --> 00:41:28,160 you know, I don't know, just like I said, do things. We're not really sure what those things 456 00:41:28,160 --> 00:41:34,160 are, but it'd be cool if they were doing them, which is encouraging. The rise, Joe, I mean, 457 00:41:34,160 --> 00:41:37,960 when you look at this, I don't know, maybe you're super optimistic. This seems like Kubernetes still 458 00:41:37,960 --> 00:41:43,300 took off faster than almost anyone really predicted. Is it because of that kind of light opinions? It 459 00:41:43,300 --> 00:41:47,940 doesn't compete directly with public cloud. It's, uh, you know, approachable enough for platform 460 00:41:47,940 --> 00:41:51,760 bills. Like what was the perfect storm that, that made this take off? Is it those things you just 461 00:41:51,760 --> 00:41:56,980 pointed out? Yeah. I, and largely it's, it's, it's a, it's a community and it's, and it's, 462 00:41:56,980 --> 00:42:02,420 you know, I think, uh, going to the CNCF and, you know, I think, you know, like we can have 463 00:42:02,420 --> 00:42:07,840 a discussion over beers about, you know, pros and cons of foundations and stuff, but having 464 00:42:07,840 --> 00:42:14,360 that vendor neutral certainty around, around Kubernetes, I think was one of the key ingredients. 465 00:42:14,760 --> 00:42:22,980 Um, having, uh, uh, that Unix philosophy of how things build up was part of it. Having a community 466 00:42:22,980 --> 00:42:27,180 in the way that, you know, we brought people in where we welcomed them versus sort of, you 467 00:42:27,180 --> 00:42:33,660 know, the, you know, beloved benevolent dictator model, I think was a big part of it too. Um, 468 00:42:34,100 --> 00:42:38,940 you know, I, you know, it's, uh, you know, I, I don't think anybody who was involved with 469 00:42:38,940 --> 00:42:43,880 Kubernetes early on could have predicted where we're at. Um, and I think it's evolved over time, 470 00:42:43,880 --> 00:42:48,740 right? I think this idea of Kubernetes as a universal control plane, uh, you know, uh, 471 00:42:48,740 --> 00:42:52,940 wasn't part of the initial thinking, but evolved over time as we understood more of what we were 472 00:42:52,940 --> 00:43:00,060 building. Yeah. Yeah. Uh, that, no, that, that, that, that part universal accidental universal 473 00:43:00,060 --> 00:43:03,920 control plane, that's, that's, that, that'll be fun to think about for some time, you know, 474 00:43:04,060 --> 00:43:10,080 I don't know. There you go. Yeah, that's right. I try to convince my, my son that I have a very 475 00:43:10,080 --> 00:43:16,080 good control plane. He should just, you know, follow the configuration that is distributed to his 476 00:43:16,080 --> 00:43:21,740 nodes, but we'll, you know, you want to manage your kids like, uh, uh, like declarative systems, 477 00:43:21,740 --> 00:43:29,700 you know, I'll be done. I do not care how that's right. Uh, well, great. Well, this is, 478 00:43:29,720 --> 00:43:33,760 this has been, this has been fun. This has been great to, uh, to, to talk with you about this, 479 00:43:34,100 --> 00:43:38,640 this stuff and ask some questions. If, uh, if people wanted to turn into your, uh, you know, 480 00:43:38,900 --> 00:43:45,120 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 481 00:43:45,120 --> 00:43:51,660 will take you to the YouTube playlist. Um, and generally, uh, Fridays at 1 PM Pacific, 482 00:43:51,660 --> 00:43:58,180 again, the worst time ever, uh, is a good place to go, uh, is the time, um, you know, Duffy's been 483 00:43:58,180 --> 00:44:04,120 doing more of them lately just because I've been too busy. Uh, uh, so thank you, Duffy. And, uh, 484 00:44:04,120 --> 00:44:08,140 and then we also have this other thing that I think for folks might be interesting called, uh, 485 00:44:08,140 --> 00:44:14,800 the cube Academy. So cube dot Academy, uh, has a bunch of, uh, content around learning Kubernetes, 486 00:44:14,800 --> 00:44:20,560 getting involved, understanding some of the basics. Uh, and, uh, yeah. So, uh, check that out. 487 00:44:21,200 --> 00:44:25,600 I w I want to see some for Richard from Richard so he can get that little like, uh, anti-alias version 488 00:44:25,600 --> 00:44:30,840 of his head down at the lower corner talking. We should, we should get more of that. That would 489 00:44:30,840 --> 00:44:35,020 be good. All right. Well, great. Well, uh, thanks again. Uh, that was fun. And as always, 490 00:44:35,320 --> 00:44:41,140 well, as for the past one or so episode, this has been Tanzu talk previously, Pivotal Conversations, 491 00:44:41,140 --> 00:44:45,700 as you may recall. And, uh, if you want to check out the, uh, the back catalogs one day, 492 00:44:45,740 --> 00:44:49,880 very soon with my copious free time, cause I don't have to travel. I'm going to go fix this up, 493 00:44:49,880 --> 00:44:57,200 but, uh, you can either go to a soundcloud.com slash Pivotal Conversations or soundcloud.com 494 00:44:57,200 --> 00:45:03,740 slash Tanzu talk. I think soundcloud is sane and they redirect old stuff. Even we'll rename it. So 495 00:45:03,740 --> 00:45:09,920 people of the future, I hope it's going well. And, uh, you can write back and tell me if it, 496 00:45:09,920 --> 00:45:14,280 uh, if it works, it'll, it'll be quite enjoyable. And with that, we'll see everyone next time. 497 00:45:14,580 --> 00:45:16,780 Bye-bye. All right. Thanks for having me on. Absolutely.