1 00:00:00,000 --> 00:00:02,620 Welcome, listeners, to the Cloud and Culture Podcast. 2 00:00:03,200 --> 00:00:07,420 If you're tuning in for the first time, we're only in the third episode after all, here's a quick background. 3 00:00:08,080 --> 00:00:09,420 I'm Derek Harris from VMware. 4 00:00:10,160 --> 00:00:12,040 And I'm Danielle Burrow from VMware. 5 00:00:12,420 --> 00:00:19,040 And this podcast is focused on VMware Pivotal Labs and the work done by our team of experts to help organizations, 6 00:00:19,560 --> 00:00:24,120 ranging from startups to Fortune 500s, shift their software development into high gear. 7 00:00:24,120 --> 00:00:30,180 As the title suggests, that entails modernizing and sometimes just kickstarting software development and tooling, 8 00:00:30,420 --> 00:00:37,800 as well as helping clients create a culture that will allow them to run efficient, self-sufficient software development teams for the long term. 9 00:00:38,460 --> 00:00:42,260 And our guest this week is Josh Rosso, a staff architect at VMware, 10 00:00:42,560 --> 00:00:48,320 who's been around Kubernetes for about as long as anyone, first at CoreOS, then at Heptio, and now at VMware. 11 00:00:48,460 --> 00:00:51,560 He spends a lot of time working with customers on their Kubernetes environments, 12 00:00:51,980 --> 00:00:55,560 and he's seen a lot with regard to what works, what doesn't, and where the gotchas are, 13 00:00:55,900 --> 00:01:00,520 especially as organizations move from testing Kubernetes to deploying it in production and then to scaling it. 14 00:01:01,080 --> 00:01:06,460 He also co-hosts the Podlets and TGIK podcast, along with other VMware Kubernetes experts. 15 00:01:07,100 --> 00:01:10,160 And if you're thinking about using Kubernetes to modernize your app infrastructure, 16 00:01:10,860 --> 00:01:13,600 sorry, your app infrastructure, you should learn a lot in this episode. 17 00:01:14,220 --> 00:01:17,720 And although we talk a lot about Kubernetes in the general sense, 18 00:01:17,720 --> 00:01:23,700 don't forget that VMware offers a whole collection of products to improve and simplify the Kubernetes experience. 19 00:01:24,240 --> 00:01:28,140 Our Tanzu lineup features tools that make it easier to manage Kubernetes clusters, 20 00:01:28,720 --> 00:01:32,840 manage multi-cluster and multi-cloud Kubernetes environments, and everything in between. 21 00:01:33,440 --> 00:01:38,240 VMware has also developed a range of open source projects to advance the Kubernetes experience, 22 00:01:38,320 --> 00:01:40,680 including Harbor, Valero, Octent, and Entrea. 23 00:01:41,160 --> 00:01:44,940 And of course, VMware Pivotal Labs has an entire team of Kubernetes experts, 24 00:01:45,100 --> 00:01:48,980 including Josh, who are dedicated to helping organizations design and implement 25 00:01:48,980 --> 00:01:51,960 a successful path to production at scale with Kubernetes. 26 00:01:52,660 --> 00:01:57,540 So listen to Josh now, and then explore our Kubernetes story at tanzu.vmware.com. 27 00:01:57,680 --> 00:02:02,060 And if you want to learn more about how VMware Pivotal Labs can help you on your modernization 28 00:02:02,060 --> 00:02:06,940 and Kubernetes journeys, visit tanzu.vmware.com slash labs. 29 00:02:08,540 --> 00:02:10,300 So Josh, thanks for joining us. 30 00:02:10,620 --> 00:02:15,700 Could you start by just giving us a little bit of background on your experience working with Kubernetes? 31 00:02:16,860 --> 00:02:17,340 Absolutely. 32 00:02:17,720 --> 00:02:21,480 So I've been doing Kubernetes for what I perceive to be a while, 33 00:02:21,600 --> 00:02:24,120 given that Kubernetes is still a bit of a newer project. 34 00:02:24,120 --> 00:02:31,780 I started out doing Kubernetes full-time at a company called CoreOS that a lot of the listeners 35 00:02:31,780 --> 00:02:33,120 might be familiar with. 36 00:02:33,660 --> 00:02:37,580 CoreOS worked on things like etcd, which is a data store of Kubernetes, 37 00:02:37,900 --> 00:02:42,620 and built out our own Kubernetes distribution, which was called Tectonic. 38 00:02:42,800 --> 00:02:46,540 And now a lot of those bits are relevant in OpenShift. 39 00:02:47,040 --> 00:02:50,440 When Red Hat bought us, I spent a very micro amount of time there 40 00:02:50,440 --> 00:02:58,100 before joining Heptio with Craig McLucky and Joe Beta and was helping bring Kubernetes to the 41 00:02:58,100 --> 00:03:02,880 enterprise, specifically kind of open source, upstream compliant Kubernetes, 42 00:03:03,060 --> 00:03:07,180 when that was a really big deal back in the day and still is today to some degree. 43 00:03:07,680 --> 00:03:08,760 And now I'm at VMware. 44 00:03:09,220 --> 00:03:15,900 And my day-to-day job has been pretty similar throughout that whole kind of progression of 45 00:03:15,900 --> 00:03:24,520 companies in that I go to fairly large organizations, you know, Fortune 500, Fortune 100, 46 00:03:24,520 --> 00:03:33,980 and help them establish a Kubernetes strategy and instantiate it, architect it, engineer around 47 00:03:33,980 --> 00:03:35,460 it, all that good stuff. 48 00:03:35,720 --> 00:03:42,720 So a lot of big banks, a lot of big retailers that some of the listeners probably interact with 49 00:03:42,720 --> 00:03:47,300 daily had some amount of involvement in helping them build out their platform. 50 00:03:47,300 --> 00:03:51,980 And I've seen a lot of the good, bad, and ugly that comes along with that process. 51 00:03:52,440 --> 00:03:55,100 I like how you say back in the day, I still hung up on that. 52 00:03:56,480 --> 00:03:58,540 Yeah, it's funny in Kubernetes years, right? 53 00:03:58,560 --> 00:04:02,080 It's like, you know, most people could say, oh, yeah, I've been doing virtual machines for 54 00:04:02,080 --> 00:04:04,980 this decades or whatever it might be, or a decade. 55 00:04:05,200 --> 00:04:09,780 And with Kubernetes, it's like five years makes you a extreme veteran, you know? 56 00:04:10,220 --> 00:04:11,800 Yeah, that's funny. 57 00:04:12,240 --> 00:04:14,520 You mentioned some of the types of organizations you're working with. 58 00:04:14,860 --> 00:04:19,720 I'm curious, like, what, I mean, this was maybe jumping into the deep end too fast, but the 59 00:04:19,720 --> 00:04:25,380 one thing I'm curious about is just what types of applications you see running inside those, 60 00:04:25,440 --> 00:04:27,980 like, what kind of things are running on Kubernetes at the moment? 61 00:04:28,820 --> 00:04:29,640 Yeah, absolutely. 62 00:04:30,420 --> 00:04:32,880 There is a ton of diversity to this answer. 63 00:04:32,880 --> 00:04:41,260 You know, if we were to go back a couple years ago, it was definitely less common for serious 64 00:04:41,260 --> 00:04:44,720 stateful workloads to be run inside of Kubernetes. 65 00:04:45,060 --> 00:04:50,100 So, you know, a lot of folks who are just getting started, and this includes the big organizations 66 00:04:50,100 --> 00:04:55,900 too, they were getting started by making sure their stateless web services could run really 67 00:04:55,900 --> 00:05:00,820 well in Kubernetes, applications that they had containerized and running really well would 68 00:05:00,820 --> 00:05:01,700 go into Kubernetes. 69 00:05:02,340 --> 00:05:08,260 And the idea would be perhaps they've got stateful services in a cloud provider like AWS or in 70 00:05:08,260 --> 00:05:09,340 their on-prem data center. 71 00:05:09,480 --> 00:05:14,900 They've been running Cassandra reliably for the last forever, as forever as far as Cassandra 72 00:05:14,900 --> 00:05:20,220 is concerned, and they would just kind of take that model of not trying to put everything 73 00:05:20,220 --> 00:05:24,140 in Kube, but trying to put the containerized stateless apps in Kube. 74 00:05:24,620 --> 00:05:26,740 Nowadays, it's definitely a bit different. 75 00:05:27,100 --> 00:05:33,280 You know, not only are people transitioning from their Kubernetes strategy being a bit of like 76 00:05:33,280 --> 00:05:35,960 a science fair project, if you will, right? 77 00:05:36,460 --> 00:05:40,820 You know, we're starting to see a lot of folks actually transition into getting workloads into 78 00:05:40,820 --> 00:05:47,540 production, and this includes workloads that are stateless and many times stateful. 79 00:05:48,120 --> 00:05:54,620 So when you go to, you know, a large financial services org, there's a good chance they might 80 00:05:54,620 --> 00:06:00,780 be running something like CockroachDB, and CockroachDB is something that they want to run as a service 81 00:06:00,780 --> 00:06:06,660 in the cluster so that as they onboard applications, their applications can consume those CockroachDB 82 00:06:06,660 --> 00:06:07,760 instances as well. 83 00:06:08,340 --> 00:06:12,420 So the short answer is all the applications, really. 84 00:06:12,700 --> 00:06:17,620 You know, the great thing about Kube is you can run most application types in there. 85 00:06:17,740 --> 00:06:22,120 I mean, at the end of the day, containers are wrapping a process and doing a couple simple 86 00:06:22,120 --> 00:06:26,900 tricks to, not really simple, but doing a couple tricks to make it run well. 87 00:06:26,940 --> 00:06:32,180 And it's just a matter of, you know, changing the paradigm a little bit of your application, 88 00:06:32,180 --> 00:06:37,320 like how it approaches high availability, how it approaches its ability to be rescheduled, 89 00:06:37,680 --> 00:06:39,780 just to make sure it can run well in Kube. 90 00:06:40,940 --> 00:06:45,740 And so, I mean, you kind of alluded to like, well, actually, it's not so simple. 91 00:06:46,520 --> 00:06:48,600 I mean, it's getting easier. 92 00:06:48,760 --> 00:06:53,240 But how would you say the experience has been for these organizations overall? 93 00:06:53,380 --> 00:06:59,260 Like, is it worth the effort and the change to move to a Kubernetes-based platform? 94 00:06:59,780 --> 00:07:00,980 Yeah, it's a great question. 95 00:07:01,100 --> 00:07:06,500 And as a VMware employee and someone who adores Kubernetes, my answer should probably be yes. 96 00:07:06,860 --> 00:07:09,460 But it is way more nuanced than that. 97 00:07:09,620 --> 00:07:14,900 You know, one of my first conversation points with a lot of folks with Kubernetes is just making 98 00:07:14,900 --> 00:07:18,020 sure that they should be using it in the first place. 99 00:07:18,180 --> 00:07:22,800 You know, a common, I don't know if this is a cliche at this point, but I'll call it out 100 00:07:22,800 --> 00:07:30,420 just in case if you're a startup that is attempting to acquire market share for your product. 101 00:07:31,160 --> 00:07:36,160 And, you know, at this point in time, there's nothing more important than shipping something, 102 00:07:36,780 --> 00:07:38,800 gaining users, so on and so forth. 103 00:07:38,880 --> 00:07:44,140 Like, I've seen so many startups that both friends and customers work at where, you know, 104 00:07:44,180 --> 00:07:48,920 they have this affinity towards, well, we really need to solve for scale and this thing and that 105 00:07:48,920 --> 00:07:52,960 thing and Kubernetes is great, so we should introduce that and use it. 106 00:07:53,060 --> 00:07:59,400 But the thing that they lose sight of is every second they're operating Kubernetes or working 107 00:07:59,400 --> 00:08:05,020 on kind of their infrastructure platform is the second they're taking away from shipping 108 00:08:05,020 --> 00:08:07,940 software that helps them get their market share. 109 00:08:08,180 --> 00:08:13,160 The thing I tell them is, like, your customers don't care whether you're running on Kubernetes, 110 00:08:13,440 --> 00:08:13,680 right? 111 00:08:14,220 --> 00:08:15,020 Unless it's me. 112 00:08:15,100 --> 00:08:16,780 If I'm your customer, I'll be like, oh, that's really cool. 113 00:08:17,160 --> 00:08:19,980 But aside from me, most people aren't really going to care. 114 00:08:20,120 --> 00:08:25,440 So if you're that kind of persona, maybe something like Heroku, you know, a platform as a service 115 00:08:25,440 --> 00:08:28,240 type offering is way more appropriate for you. 116 00:08:28,740 --> 00:08:33,320 Now, a lot of these big organizations in regards to your question, Danielle, about like the worth, 117 00:08:33,860 --> 00:08:36,020 obviously the answer is it depends. 118 00:08:36,160 --> 00:08:40,820 But a lot of them are really thinking through, you know, how do I kind of standardize on a 119 00:08:40,820 --> 00:08:47,460 application platform where we can have this kind of consistent experience to onboard apps and get 120 00:08:47,460 --> 00:08:55,040 things deployed and scale them out and have really solid declarative APIs and so on and so on and so 121 00:08:55,040 --> 00:08:55,340 forth. 122 00:08:55,720 --> 00:09:01,060 And I think what a lot of these larger organizations are seeing is Kubernetes is kind of a natural 123 00:09:01,060 --> 00:09:03,240 evolution for them to get to that state. 124 00:09:03,440 --> 00:09:07,360 And to be clear, Kubernetes is part of the puzzle for these groups, right? 125 00:09:07,420 --> 00:09:10,360 Kubernetes is the container orchestrator layer. 126 00:09:10,540 --> 00:09:14,940 It's not like they should be going in and saying, and we're going to introduce Kubernetes and our problems 127 00:09:14,940 --> 00:09:15,680 will be solved. 128 00:09:15,860 --> 00:09:20,240 You know, more so the problem is, oh, we need to think about how we schedule and think about 129 00:09:20,240 --> 00:09:20,660 workloads. 130 00:09:20,860 --> 00:09:24,320 So we'll use Kubernetes as kind of that foundational orchestration layer. 131 00:09:24,440 --> 00:09:26,880 And then for monitoring, we'll add this piece in. 132 00:09:27,020 --> 00:09:32,680 And for source control management and continuous delivery, we'll add this GitOps type flow in 133 00:09:32,680 --> 00:09:34,180 with these tools and so on. 134 00:09:34,320 --> 00:09:41,920 So, you know, I think the super honest answer is it's a bit to be determined for a lot of these 135 00:09:41,920 --> 00:09:44,300 orgs whether the investment is worth it. 136 00:09:44,300 --> 00:09:50,400 But in my case, I'm very lucky to say I've seen a lot of organizations see this process all the way 137 00:09:50,400 --> 00:09:50,800 through. 138 00:09:51,500 --> 00:09:57,800 And for many of them, they've gone from developers putting in a ticket and getting a virtual machine 139 00:09:57,800 --> 00:10:02,500 14 days later that's misconfigured, and then they have to open up another ticket so that they can 140 00:10:02,500 --> 00:10:03,720 finally get their app on it. 141 00:10:03,980 --> 00:10:09,420 They've gone from some of those really old legacy models to this completely API-driven 142 00:10:09,420 --> 00:10:14,260 container-based system that has enabled them to ship software a lot faster. 143 00:10:14,300 --> 00:10:20,540 It has enabled them to have easier primitives for scaling and monitoring and traceability. 144 00:10:20,780 --> 00:10:26,540 So, you know, it's a really inspiring direction for most enterprises, for most organizations. 145 00:10:26,800 --> 00:10:31,300 But I think timing is everything, is really kind of what I'm trying to say in too many words. 146 00:10:31,540 --> 00:10:34,220 You really have to figure out, is this the right time for you? 147 00:10:35,000 --> 00:10:36,360 Josh, can you go into it? 148 00:10:36,380 --> 00:10:38,660 You mentioned this and you mentioned scale several times. 149 00:10:38,800 --> 00:10:41,260 So it does seem, and I could be mistaken here, right? 150 00:10:41,260 --> 00:10:45,780 Like there's a kind of double-edged sword with Kubernetes where on the one hand, it'd say, 151 00:10:45,860 --> 00:10:49,620 well, if you're not operating at a big scale, it might not be worth the effort. 152 00:10:49,680 --> 00:10:53,160 On the other hand, you know, it seems to be that it gets a little, it seems to be a little 153 00:10:53,160 --> 00:10:55,860 more complex the more you get, the more you scale out, right? 154 00:10:55,860 --> 00:10:57,200 As most things probably do. 155 00:10:57,820 --> 00:10:59,460 So, I mean, does that kind of match? 156 00:10:59,720 --> 00:11:02,260 It sounds like maybe that matches your experience. 157 00:11:02,260 --> 00:11:05,960 And how do you find that balance between like, okay, well, now we're at scale. 158 00:11:06,020 --> 00:11:10,020 Now this makes a lot of sense, but also how do we manage this thing if we're actually doing 159 00:11:10,020 --> 00:11:13,360 it at, you know, let's say bank or mega retailer scale? 160 00:11:14,380 --> 00:11:15,060 Yeah, absolutely. 161 00:11:15,300 --> 00:11:21,100 So the universal principle that scale makes things more complicated, I am a hundred percent 162 00:11:21,100 --> 00:11:21,780 on board with. 163 00:11:21,900 --> 00:11:25,340 You said something really interesting at the first part of that question that I'll call 164 00:11:25,340 --> 00:11:30,420 out, which is like, you know, unless you're at a certain scale, should you consider Kubernetes? 165 00:11:30,420 --> 00:11:35,120 Now, you know, in a lot of the things I'm saying now I should mention are Josh's opinion. 166 00:11:35,300 --> 00:11:38,120 So listeners, please know that you might disagree and that's awesome. 167 00:11:38,580 --> 00:11:44,820 But my perspective is very much going a couple years back, you know, if you weren't in a state 168 00:11:44,820 --> 00:11:49,300 where like, I heard someone say once, like, you have so many machines that you can't remember 169 00:11:49,300 --> 00:11:50,240 their names, right? 170 00:11:50,260 --> 00:11:53,220 Like, or you have so many machines you can't, like, that could be a really good inflection 171 00:11:53,220 --> 00:11:57,780 point for adding an orchestrator that abstracts them like Kubernetes and on and on. 172 00:11:58,160 --> 00:11:59,780 Today, it's a little different. 173 00:11:59,780 --> 00:12:06,020 Like, you have to think a couple years ago, we didn't have managed services per se, like 174 00:12:06,020 --> 00:12:15,200 EKS for Amazon, TKG from VMware, AKS from Microsoft, and of course, GKE, I should call 175 00:12:15,200 --> 00:12:15,880 out from Google. 176 00:12:16,340 --> 00:12:18,580 And these have lowered the bar a bit. 177 00:12:18,820 --> 00:12:23,340 You know, what you can do here is you can go to a provider and you can basically say, 178 00:12:23,460 --> 00:12:27,180 give me a cluster and handle some of the bootstrapping and management concerns for me. 179 00:12:27,180 --> 00:12:35,840 So I think Kubernetes is at a place today where you don't have to be at mega scale to use it. 180 00:12:36,060 --> 00:12:41,560 You can still justify its use, especially if you've got expertise, especially if the container-based 181 00:12:41,560 --> 00:12:43,900 models and flows are things that make sense for you. 182 00:12:43,980 --> 00:12:48,560 So I'm not saying everyone should use Kube, but you don't necessarily have to be at a massive 183 00:12:48,560 --> 00:12:52,960 scale because no longer is it as onerous to operate Kubernetes. 184 00:12:53,180 --> 00:12:57,100 Now, the second part of your question, I'm super on board with. 185 00:12:57,240 --> 00:13:00,240 Like, what ends up happening is, you know, especially when you're one of these large 186 00:13:00,240 --> 00:13:03,800 organizations, as you gain adoption, right? 187 00:13:03,920 --> 00:13:08,340 And you actually get people onboarding, you get applications scaling out. 188 00:13:08,940 --> 00:13:15,160 Things do become way more complicated, which I feel like is probably true for almost anything. 189 00:13:15,340 --> 00:13:21,060 And with Kubernetes, how this kind of shows is, yeah, there's like, there's some potential 190 00:13:21,060 --> 00:13:27,700 limitations at like technical levels, like our deep lower level concerns, like people using 191 00:13:27,700 --> 00:13:29,140 the service abstraction in Kubernetes. 192 00:13:29,400 --> 00:13:32,060 It by default uses this thing called IP tables. 193 00:13:32,360 --> 00:13:37,560 There have been experiences where you have an insane amount of services with a lot of churn. 194 00:13:37,560 --> 00:13:44,420 And that particular piece in Linux called IP tables doesn't do so well with like mutable 195 00:13:44,420 --> 00:13:45,380 changes over time. 196 00:13:45,460 --> 00:13:47,220 It can cause some scaling issues with services. 197 00:13:47,460 --> 00:13:52,520 So like you end up like at the Linux level having to think through, oh my gosh, do I replace 198 00:13:52,520 --> 00:13:57,580 this thing called Kube Proxy that like handles this really low level implementation detail? 199 00:13:57,820 --> 00:14:00,860 Do I tune Kube Proxy or use it in a different mode? 200 00:14:01,040 --> 00:14:02,980 You get a lot of those lower level concerns. 201 00:14:03,380 --> 00:14:05,020 Now, there's also higher level concerns. 202 00:14:05,020 --> 00:14:07,480 There's like, all right, we're scaling now. 203 00:14:07,980 --> 00:14:12,520 Should we, you know, this is the most common one I'd say, should we have one mega cluster 204 00:14:12,520 --> 00:14:19,180 that just grows and grows and grows and puts stress on these edges of like how much the 205 00:14:19,180 --> 00:14:25,200 API server can handle and how much kind of communication can occur between the state of all these nodes 206 00:14:25,200 --> 00:14:26,300 as you go up and up and up? 207 00:14:26,300 --> 00:14:32,540 Or should we take this like multi-cluster federated model where we have things where we 208 00:14:32,540 --> 00:14:37,540 can just instantiate clusters, you know, clusters like cattle, if you will, and just start bootstrapping 209 00:14:37,540 --> 00:14:39,060 more and more and more and more. 210 00:14:39,560 --> 00:14:42,900 And that model is one that we've actually seen a lot of success with with customers at 211 00:14:42,900 --> 00:14:43,240 scale. 212 00:14:43,400 --> 00:14:50,080 The big trade-off with that multi-cluster model is that you end up with a federation problem. 213 00:14:50,500 --> 00:14:51,860 And there's open source projects. 214 00:14:52,000 --> 00:14:54,180 There's companies that try to solve the federation problem. 215 00:14:54,180 --> 00:14:59,240 But I'd say largely, it's still pretty difficult where basically you say, now I'm no longer in a world 216 00:14:59,240 --> 00:15:02,600 where I have this one scheduler that understands a singular cluster. 217 00:15:03,100 --> 00:15:07,440 Now I've got 27 clusters that I want my developers to be able to deploy to. 218 00:15:07,540 --> 00:15:11,680 And most of us don't want our developers to have to worry about which of the 27 clusters 219 00:15:11,680 --> 00:15:14,240 to deploy to, and then how to make it highly available. 220 00:15:14,240 --> 00:15:18,440 We want to build an abstraction or kind of a federation system on top of that. 221 00:15:18,520 --> 00:15:18,700 Right. 222 00:15:19,140 --> 00:15:25,400 So, um, so yeah, it's, it's really just kind of like, as, as you scale up, you end up having 223 00:15:25,400 --> 00:15:31,180 to think a little bit about, you know, what areas should we scale and how should we approach 224 00:15:31,180 --> 00:15:31,600 this? 225 00:15:31,700 --> 00:15:36,080 Um, and, and there's a lot of ways to kind of, uh, uh, to use a crude analogy, kind of skin 226 00:15:36,080 --> 00:15:36,580 that cat. 227 00:15:37,940 --> 00:15:38,340 Yeah. 228 00:15:38,340 --> 00:15:42,860 And I, I feel like you, you just kind of covered my next question a little bit, but maybe, 229 00:15:43,080 --> 00:15:45,500 you know, kind of a different angle. 230 00:15:45,500 --> 00:15:49,920 Like if you think about the things that you've really got to think about, um, kind of the 231 00:15:49,920 --> 00:15:58,420 gotchas as you move through different stages of setting up a, you know, a production, like 232 00:15:58,420 --> 00:16:03,560 getting to that production platform at scale. 233 00:16:03,700 --> 00:16:08,080 So like, what are the things you have to think about when you're moving from like desktop to 234 00:16:08,080 --> 00:16:14,800 like test development to like production to production at scale, like going through, you know, 235 00:16:15,120 --> 00:16:16,880 that process. 236 00:16:17,500 --> 00:16:19,500 Are there different concerns along the way? 237 00:16:20,580 --> 00:16:20,980 Yeah. 238 00:16:21,020 --> 00:16:23,540 I hope this won't feel like a cop-out answer, Danielle. 239 00:16:23,540 --> 00:16:28,880 Like one of the places that I usually start from, because a lot of times it's like, okay, 240 00:16:28,980 --> 00:16:32,540 let's, let's talk about what are, what are the things that I should be? 241 00:16:32,600 --> 00:16:33,760 I'm speaking for a company here. 242 00:16:33,820 --> 00:16:37,160 What are the things I should be worried about when I get to scale? 243 00:16:37,220 --> 00:16:42,340 And the first thing that I tell them is first, let's worry about needing to get to scale. 244 00:16:42,660 --> 00:16:45,880 Because so many times we don't even get to that point. 245 00:16:45,920 --> 00:16:47,840 And we've covered a lot of that already, right? 246 00:16:47,840 --> 00:16:51,780 It's like, do I actually benefit from running Kubernetes? 247 00:16:52,000 --> 00:16:52,980 Is it beneficial to me? 248 00:16:53,300 --> 00:16:58,040 Another really common thing is if, especially if you're building out, you know, an application 249 00:16:58,040 --> 00:17:02,280 platform on top of cube where like you're going to be having monitoring, maybe a service 250 00:17:02,280 --> 00:17:05,220 mesh, maybe X, Y, and Z thing to, to benefit the apps. 251 00:17:05,620 --> 00:17:09,240 Make sure you're engaged with your development teams during that process. 252 00:17:09,380 --> 00:17:15,040 It might seem obvious, but it's super sad how many times I go to large organizations that 253 00:17:15,040 --> 00:17:17,100 have a build it and they will come mentality. 254 00:17:17,280 --> 00:17:20,780 And then they wonder why platform adoption kind of lags. 255 00:17:20,840 --> 00:17:26,020 It's because you built something in a silo and you misalign some of your decisions with 256 00:17:26,020 --> 00:17:28,240 what developers actually need and want. 257 00:17:28,500 --> 00:17:33,580 So let's assume you did those two things right and you built a great platform and you got 258 00:17:33,580 --> 00:17:34,280 great adoption. 259 00:17:34,640 --> 00:17:37,820 So then that gets to, I think, what maybe you were more so getting at. 260 00:17:37,960 --> 00:17:40,660 What are some of the kind of key gotchas? 261 00:17:41,660 --> 00:17:45,420 I'll throw a couple off the top of my head that I commonly see. 262 00:17:47,000 --> 00:17:55,940 One of them, as you start kind of getting adoption, is really around, well, I'll use this one as 263 00:17:55,940 --> 00:17:56,260 an example. 264 00:17:56,340 --> 00:18:01,080 It's kind of random, but choosing your open source tooling wisely. 265 00:18:02,080 --> 00:18:07,420 And this one is interesting because we've had this paradigm shift from, you know, you have 266 00:18:07,420 --> 00:18:13,100 a vendor or an enterprise supply you with something to, you know, a lot more of a, like, open source. 267 00:18:13,280 --> 00:18:14,800 I can pull it off GitHub type model. 268 00:18:14,920 --> 00:18:18,820 Now, open source has always been a thing, don't get me wrong, but it's becoming even more prevalent. 269 00:18:18,940 --> 00:18:23,880 And if you look at something like the cloud native landscape, there's tons of logos for all types 270 00:18:23,880 --> 00:18:25,780 of projects and products out there, right? 271 00:18:26,000 --> 00:18:30,480 So the one thing that I'm oftentimes telling folks as they scale and choose these different 272 00:18:30,480 --> 00:18:36,500 tools is, you know, really think wisely and honestly about the onus it puts on you to run 273 00:18:36,500 --> 00:18:37,940 some of these projects. 274 00:18:38,880 --> 00:18:43,260 You know, the common thing, I don't know who came up with it, that people say, like, free 275 00:18:43,260 --> 00:18:45,900 as in puppy, not free as in beer for open source, right? 276 00:18:45,920 --> 00:18:46,520 It's very true. 277 00:18:46,580 --> 00:18:48,020 Open source is free as in puppy. 278 00:18:48,660 --> 00:18:51,100 Sure, it's free for you to download and deploy your cluster. 279 00:18:51,380 --> 00:18:59,100 But when, you know, your container networking solution, let's say you're using Cilium as an 280 00:18:59,100 --> 00:19:05,540 example, if it breaks down on you, who's on the hook for solving that problem? 281 00:19:05,540 --> 00:19:10,400 Who's on the hook if a critical bug comes up and sends your production system spiraling? 282 00:19:11,100 --> 00:19:16,300 You know, in cases like Cilium or Calico or Antreya, in the case of VMware, a lot of these 283 00:19:16,300 --> 00:19:18,580 open source projects have enterprise support. 284 00:19:18,980 --> 00:19:23,660 So not that you need enterprise support, but the question really is, do you have the operational 285 00:19:23,660 --> 00:19:29,620 maturity that when you scale out and something goes wrong, you understand how to work the project, 286 00:19:29,780 --> 00:19:32,540 how to work the code, how to fix bugs, how to solve problems? 287 00:19:32,540 --> 00:19:35,760 Those are really kind of honest and big things to solve for. 288 00:19:36,960 --> 00:19:42,320 And then I guess the last thing I would say, just to give one more random example is, you 289 00:19:42,320 --> 00:19:48,200 know, really commonly when you start scaling out, it's just really scaling out how you manage 290 00:19:48,200 --> 00:19:53,760 and how you do SRE like things to the many, many different entities you have to worry about. 291 00:19:53,820 --> 00:19:59,280 So like in that multi-cluster model, you know, let's say you end up with hundreds and hundreds 292 00:19:59,280 --> 00:20:00,000 of clusters. 293 00:20:00,680 --> 00:20:05,900 How are you going to have an SRE practice around all of these different units that you have to 294 00:20:05,900 --> 00:20:06,440 worry about? 295 00:20:07,100 --> 00:20:11,920 How are you going to ensure reliability, not just for one thing, which might be where you 296 00:20:11,920 --> 00:20:13,620 started, but now a hundred things? 297 00:20:14,260 --> 00:20:18,280 And how are you going to kind of federate and think about kind of the management plane on 298 00:20:18,280 --> 00:20:19,560 top of all of that stuff? 299 00:20:19,600 --> 00:20:23,840 And I think, I think a lot of this is maturing in the cloud native space right now. 300 00:20:23,900 --> 00:20:28,360 There's such great stuff happening upstream in products and projects that are out there, 301 00:20:28,360 --> 00:20:36,140 but it's very new because if I were to predict, I think from, at least from Josh's experience, 302 00:20:36,140 --> 00:20:41,060 I think, um, a lot of folks are just now reaching scale in production. 303 00:20:41,060 --> 00:20:44,440 Now there's tons of people who have been in production with Kubernetes forever, but I think 304 00:20:44,440 --> 00:20:46,820 we're kind of hitting more of an inflection point. 305 00:20:46,900 --> 00:20:51,300 And now we're starting to see more of the needs for how do I kind of scale out my management 306 00:20:51,300 --> 00:20:53,820 capabilities over, over many of these clusters. 307 00:20:54,900 --> 00:20:55,460 All right. 308 00:20:55,660 --> 00:20:58,360 I think that open source discussion is interesting too. 309 00:20:58,400 --> 00:21:02,220 And I should say, you know, we're working on, uh, publishing at some point soon there, and 310 00:21:02,220 --> 00:21:03,900 maybe it'll be published by the time this airs. 311 00:21:03,940 --> 00:21:05,280 So you can go back and look for it. 312 00:21:05,440 --> 00:21:07,060 But a buyer's guide to open source. 313 00:21:07,060 --> 00:21:09,620 And then one of the things where I think we talk about many of those things in terms 314 00:21:09,620 --> 00:21:11,680 of what does this actually cost you to run? 315 00:21:11,680 --> 00:21:11,900 Right. 316 00:21:11,900 --> 00:21:13,940 And yeah, who's, what's the community look like behind this project? 317 00:21:13,940 --> 00:21:17,360 There's just so much happening right now that to pick something out of the, what is it, 318 00:21:17,360 --> 00:21:19,180 what's been approved by your legal department? 319 00:21:20,640 --> 00:21:23,540 You know, there's, cause we do actually have to push it to production. 320 00:21:23,540 --> 00:21:25,940 Now you have a whole lot, whole other set of concerns, I think. 321 00:21:26,000 --> 00:21:26,300 So, right. 322 00:21:26,360 --> 00:21:30,500 There's a, yeah, there's a lot with the open source that, um, that maybe it's taken for 323 00:21:30,500 --> 00:21:34,740 granted, but, uh, sticking specifically to Kubernetes, I want to ask too, like 324 00:21:34,740 --> 00:21:38,540 because you, because you mentioned you were working, if you're building out a Kubernetes 325 00:21:38,540 --> 00:21:41,140 platform, the importance of working with your develop, with your developers. 326 00:21:41,860 --> 00:21:46,100 And I've heard this from customers and other people, like, you know, there's a, from both 327 00:21:46,100 --> 00:21:46,500 directions. 328 00:21:46,500 --> 00:21:48,740 One is developers coming and saying, Hey, we want Kubernetes. 329 00:21:49,300 --> 00:21:52,260 And the other is this platform team or the ops team coming and saying, Hey, we deployed 330 00:21:52,260 --> 00:21:52,820 Kubernetes. 331 00:21:53,380 --> 00:21:57,920 So how have you seen that balance play out in the field? 332 00:21:57,920 --> 00:22:01,220 I mean, is this something driven by developers, by the infrastructure folks? 333 00:22:01,220 --> 00:22:03,160 I guess there's benefits to both sides, but. 334 00:22:03,960 --> 00:22:05,640 Definitely both in my experience. 335 00:22:05,640 --> 00:22:08,000 And here, here's my current working theory. 336 00:22:08,000 --> 00:22:11,500 And I'm still learning about how all this plays out as we see more and more people adopt 337 00:22:11,500 --> 00:22:11,800 cube. 338 00:22:12,280 --> 00:22:20,680 If you can operate at the intersection of apps and platform, that is the gold place to operate 339 00:22:20,680 --> 00:22:20,860 at. 340 00:22:20,900 --> 00:22:22,660 Cause here's, here's, here's the thing, right? 341 00:22:23,540 --> 00:22:31,160 The, um, the developers to get their apps into production rarely find Kubernetes to be solely 342 00:22:31,160 --> 00:22:31,560 enough. 343 00:22:32,280 --> 00:22:34,780 Um, some app teams run their own Kubernetes clusters. 344 00:22:34,920 --> 00:22:38,260 That's, that's a bit of a different persona here, but the app teams, when they come to the 345 00:22:38,260 --> 00:22:42,360 develop, to the platform teams, especially in large orgs and say, Oh, we'd really love 346 00:22:42,360 --> 00:22:42,820 Kubernetes. 347 00:22:43,060 --> 00:22:48,360 What they actually mean is they'd love Kubernetes with a certain ingress, uh, controller set up, 348 00:22:48,360 --> 00:22:53,780 maybe a service mesh monitoring pre-baked in so they can access stuff, so on and so forth. 349 00:22:54,220 --> 00:22:59,100 And then the platform team, you know, they have desires of making sure they have great customer 350 00:22:59,100 --> 00:23:00,460 satisfaction of their developers. 351 00:23:00,460 --> 00:23:05,240 Like, you know, at the end of the day, the platform teams, uh, customers are those development 352 00:23:05,240 --> 00:23:05,540 teams. 353 00:23:05,640 --> 00:23:09,920 So what I mean by the intersection of apps and platform is here's, here's what I think 354 00:23:09,920 --> 00:23:11,400 we're largely doing a lot of the time. 355 00:23:11,720 --> 00:23:18,080 Um, there is this, uh, there is a desire to put apps on a more modern platform, right? 356 00:23:18,120 --> 00:23:22,920 So we start talking about adoption and understanding the apps and we start understanding kind of 357 00:23:22,920 --> 00:23:31,800 common patterns like, Oh, these apps put into their Java code, this mutual TLS system that 358 00:23:31,800 --> 00:23:32,380 they bake in. 359 00:23:32,380 --> 00:23:37,940 And then, Oh, this, these Python apps that we're pulling in over here for something machine 360 00:23:37,940 --> 00:23:38,640 learning related. 361 00:23:38,640 --> 00:23:43,200 They also do service to service communication over like some mutual TLS thing. 362 00:23:43,200 --> 00:23:47,880 And they all have to bake it in via some library that they import and so on and so forth. 363 00:23:47,880 --> 00:23:51,600 So then the platform team kind of learns about this common pattern and they're like, okay, 364 00:23:51,600 --> 00:23:52,320 this is great. 365 00:23:52,840 --> 00:23:59,500 So it sounds like maybe some kind of like service identity system that we could bake into the 366 00:23:59,500 --> 00:24:05,860 platform and offer developers would enable them to ship code without having to be worried 367 00:24:05,860 --> 00:24:09,620 about identity services, intra code. 368 00:24:09,860 --> 00:24:11,020 That's kind of interesting. 369 00:24:11,180 --> 00:24:11,680 Okay, cool. 370 00:24:12,020 --> 00:24:15,260 So let's think about, um, some type of technology. 371 00:24:15,440 --> 00:24:20,920 Maybe it's console connect, or maybe it's some service service mesh technology like Istio, which 372 00:24:20,920 --> 00:24:25,380 of course solves a bunch of other problems too, but we bake this into the platform as a platform 373 00:24:25,380 --> 00:24:25,800 service. 374 00:24:26,020 --> 00:24:29,800 And now we've relieved our app developers of that concern. 375 00:24:29,940 --> 00:24:35,440 That is one of the, again, where you can really make your platform super valuable is not 376 00:24:35,440 --> 00:24:40,300 just shipping random features, but shipping things that make a lot of sense with your understanding 377 00:24:40,300 --> 00:24:41,180 of the app persona. 378 00:24:41,320 --> 00:24:43,060 I'll give you one more super random example. 379 00:24:43,700 --> 00:24:44,760 I see this quite a bit. 380 00:24:44,880 --> 00:24:50,180 So app developers are going in and they're like, oh, you know, we, we so often we have 381 00:24:50,180 --> 00:24:52,800 to like talk to this external vault system. 382 00:24:53,040 --> 00:24:55,840 Vault is a secret management store by a, by a company called HashiCorp. 383 00:24:55,900 --> 00:24:57,120 It's a great open source project. 384 00:24:57,460 --> 00:25:04,420 And, um, and what we find is, okay, every application is having to like import the spring cloud library 385 00:25:04,420 --> 00:25:07,280 thing that allows them to communicate with vault. 386 00:25:07,280 --> 00:25:09,200 And then the Python developers are having to do the same thing. 387 00:25:09,260 --> 00:25:10,840 And the go developers are having to do the same thing. 388 00:25:11,300 --> 00:25:20,000 What if as a platform service, we set up Kubernetes to integrate with vault so that a application 389 00:25:20,000 --> 00:25:25,040 could come in, ask for a secret that it is allowed to have access to in vault. 390 00:25:25,640 --> 00:25:32,120 And by a, just like a little annotation on a YAML file, Kubernetes goes out, does the magic 391 00:25:32,120 --> 00:25:36,280 and just makes the secret show up in the file system of the container. 392 00:25:36,580 --> 00:25:40,900 Like, boom, what an amazingly powerful platform service, right? 393 00:25:41,240 --> 00:25:47,220 So it's those kinds of things where like, don't just guess, work together at that intersection. 394 00:25:47,220 --> 00:25:51,720 And what you're going to end up delivering is something that is insanely valuable for both 395 00:25:51,720 --> 00:25:54,320 the infrastructure team and also the app developers. 396 00:25:55,460 --> 00:26:03,060 So, um, Josh, I'm kind of wondering, just going back to talking about open source and the 397 00:26:03,060 --> 00:26:11,200 Kubernetes community, are there holes in the Kubernetes that you think, you know, still 398 00:26:11,200 --> 00:26:12,960 ought to be filled by the community? 399 00:26:12,960 --> 00:26:16,040 Like what's, what's missing or where, or where are we headed? 400 00:26:17,640 --> 00:26:19,180 Yeah, that's a great question. 401 00:26:19,180 --> 00:26:27,320 Yeah, I think, I think a lot of things are really in flight right now. 402 00:26:27,320 --> 00:26:32,180 So I'll, I'll include gaps to include things that like people are actively working on, but 403 00:26:32,180 --> 00:26:34,460 I think we're still pretty early days. 404 00:26:34,460 --> 00:26:36,340 Like you heard me mentioned many times. 405 00:26:36,340 --> 00:26:38,600 I think federation is a pretty big one. 406 00:26:39,000 --> 00:26:40,740 Um, there's been great traction. 407 00:26:40,740 --> 00:26:44,500 I know there's a bunch of humans doing awesome work here, so I'm not trying to discount that. 408 00:26:44,600 --> 00:26:46,680 It's just, it's pretty early days. 409 00:26:46,680 --> 00:26:52,120 And I don't think we've really seen something kind of, uh, fill that gap completely just yet. 410 00:26:52,120 --> 00:26:56,440 Um, you know, kind of, kind of like just to give an analogy, like kind of like service mesh, 411 00:26:56,440 --> 00:27:01,720 like we all knew maybe we needed to fill this service mesh gap for people who have the right 412 00:27:01,720 --> 00:27:03,320 need to implement a service mesh. 413 00:27:03,320 --> 00:27:08,200 Um, and we saw players kind of come up like Istio and Linkerdia and now that's got its 414 00:27:08,200 --> 00:27:09,180 own thriving ecosystem. 415 00:27:09,180 --> 00:27:12,440 I think, I think federation is definitely one of those big ones. 416 00:27:12,980 --> 00:27:22,980 Um, I think a lot on kind of like the, I guess a bit on the kind of app side where we're, 417 00:27:22,980 --> 00:27:26,520 we're really, we're really kind of moving up the stack at this point, in my opinion, 418 00:27:26,520 --> 00:27:28,900 as, as Kubernetes becomes more and more boring. 419 00:27:29,340 --> 00:27:33,300 Um, there's, there's a lot of really interesting things happening on the app. 420 00:27:33,300 --> 00:27:34,320 side that are filling gaps. 421 00:27:34,320 --> 00:27:42,060 Like how do we appropriately abstract Kubernetes to make sure developers can be successful 422 00:27:42,060 --> 00:27:44,020 without becoming a Kubernetes expert? 423 00:27:44,160 --> 00:27:47,460 That's a super interesting space because it's a balancing act, right? 424 00:27:47,620 --> 00:27:52,740 A lot of times it's, it's a little naive to say, well, we're just going to completely build 425 00:27:52,740 --> 00:27:53,620 a full abstraction. 426 00:27:53,760 --> 00:27:58,140 Developers will never know they're using Kubernetes and we'll keep exposing the right knobs to 427 00:27:58,140 --> 00:27:59,260 the developers over time. 428 00:27:59,260 --> 00:28:03,280 Like some really solid engineering orgs are successful at that. 429 00:28:03,280 --> 00:28:05,140 That model, but many can't do that. 430 00:28:05,140 --> 00:28:08,380 And Kubernetes offers so many great features that a lot of times we want to expose a little 431 00:28:08,380 --> 00:28:09,240 bit of that to developers. 432 00:28:09,240 --> 00:28:13,520 So like, you know, I think where I'm going with this is examples like GitOps. 433 00:28:13,920 --> 00:28:18,000 GitOps has become this really interesting model now where we're starting to see it play out, 434 00:28:18,100 --> 00:28:21,780 where developers can focus more on, I commit the thing to Git. 435 00:28:22,140 --> 00:28:26,620 And maybe I don't really understand all the things that get picked up in order to kind of 436 00:28:26,620 --> 00:28:27,620 make it happen, right? 437 00:28:27,620 --> 00:28:33,940 As we see things like things inspired by Cloud Foundry kind of come into the Kubernetes ecosystem, 438 00:28:33,940 --> 00:28:38,660 that's also a really interesting place that I think we'll see some traction. 439 00:28:38,920 --> 00:28:42,720 Like if those of you who have ever used Cloud Foundry have probably heard of things like CF 440 00:28:42,720 --> 00:28:49,160 push, like how could I, from my source control repo, say, push this app and all the different 441 00:28:49,160 --> 00:28:51,520 things kind of happen and it just becomes available. 442 00:28:51,520 --> 00:28:54,660 Like that's a really interesting developer experience too. 443 00:28:55,220 --> 00:28:59,500 So I would say if I were to hedge my bets on just two, because I could talk forever about 444 00:28:59,500 --> 00:29:03,760 this, I'd say federation of clusters is a really interesting space. 445 00:29:04,140 --> 00:29:09,040 And I just think upstack, like developer onboarding, you know, we're getting really good at Kubernetes. 446 00:29:09,280 --> 00:29:15,160 How do we make it frictionless for the people whose day job isn't Kubernetes to benefit from 447 00:29:15,160 --> 00:29:17,020 all the awesomeness that Kubernetes offers? 448 00:29:17,640 --> 00:29:24,940 Yeah, on a related note, I wanted to ask too, is there a, do you see like a standard application, 449 00:29:25,160 --> 00:29:27,240 like a Kubernetes application architecture, right? 450 00:29:27,240 --> 00:29:29,840 Or a standard development experience, developer experience? 451 00:29:29,980 --> 00:29:33,740 I mean, are these things, are we heading in that direction as you talk about all just all 452 00:29:33,740 --> 00:29:38,060 the, you know, the tools that are kind of getting critical mass and the way that they 453 00:29:38,060 --> 00:29:39,180 might be exposed to developers? 454 00:29:39,380 --> 00:29:43,260 Is there, you know, are we heading toward a point where if I'm a developer, if I'm building 455 00:29:43,260 --> 00:29:47,580 an application that's going to run a Kubernetes, I kind of, you know, I'm kind of, I'm architecting 456 00:29:47,580 --> 00:29:48,380 in a certain way, right? 457 00:29:48,420 --> 00:29:51,100 I'm, I'm expecting a certain experience and I'm building in a certain way. 458 00:29:51,100 --> 00:29:55,740 Cause that's just like, you know, maybe it's like the lamp stack for something. 459 00:29:57,000 --> 00:29:58,620 My answer is not really. 460 00:29:58,720 --> 00:30:00,860 I mean, it is, it's super interesting. 461 00:30:00,860 --> 00:30:06,040 Like speaking to like the application architecture, I help people run monoliths on Kubernetes all 462 00:30:06,040 --> 00:30:06,400 the time. 463 00:30:06,440 --> 00:30:07,040 It works great. 464 00:30:07,040 --> 00:30:09,000 There's not, you can run a monolith on Kubernetes. 465 00:30:09,200 --> 00:30:15,580 You don't, you don't have to re-architect into a 97 factor microservice architecture that 466 00:30:15,580 --> 00:30:17,440 is compliant with X, Y, and Z standard. 467 00:30:17,580 --> 00:30:20,560 You know, there are definitely things you got to do to get your app in Kubernetes. 468 00:30:20,820 --> 00:30:25,220 It's maybe possibly got to run in a container, although there's some really interesting projects 469 00:30:25,220 --> 00:30:27,020 to make virtual machines, first class citizens. 470 00:30:27,540 --> 00:30:31,760 You probably want it to be able to be highly available, resilient to scheduling events. 471 00:30:31,760 --> 00:30:36,020 There's, there's, you know, exposing probes for its readiness and liveness of the 472 00:30:36,020 --> 00:30:36,500 application. 473 00:30:36,500 --> 00:30:41,060 Like there are these small things, but largely we can make things run pretty well in cube. 474 00:30:41,580 --> 00:30:46,460 So as far as like how people are architecting and building apps, I'm seeing an insane amount 475 00:30:46,460 --> 00:30:47,020 of diversity. 476 00:30:47,020 --> 00:30:51,060 I mean, when I go customer to customer, I feel like I'm not even talking about the same Kubernetes 477 00:30:51,060 --> 00:30:51,460 anymore. 478 00:30:51,460 --> 00:30:58,740 Cause like the use cases and the application types and their, their stacks vary so much, 479 00:30:58,740 --> 00:31:01,200 which I think speaks volumes to Kubernetes. 480 00:31:01,200 --> 00:31:07,240 Like while Kubernetes is a lot of an investment to build out and determine which knobs to turn, 481 00:31:07,240 --> 00:31:13,340 it also can handle a lot because it did a beautiful job of making things extensible, customizable, 482 00:31:13,340 --> 00:31:14,500 and so on. 483 00:31:15,000 --> 00:31:19,280 Um, and then as far as kind of the, the more downstream thing, like, is there common kind 484 00:31:19,280 --> 00:31:21,360 of like build and deploy patterns? 485 00:31:21,360 --> 00:31:26,420 Um, I see a lot of diversity here too, like, uh, or, or variants, I should say, where some 486 00:31:26,420 --> 00:31:30,920 folks are just linking their old Jenkins system up to cube, uh, that runs outside of cube and 487 00:31:30,920 --> 00:31:31,460 just deploying. 488 00:31:31,460 --> 00:31:32,560 And that's perfectly fine. 489 00:31:32,560 --> 00:31:36,180 I think the GitOps model is gaining a lot of traction. 490 00:31:36,180 --> 00:31:38,520 Cause like, it's such a good intersection. 491 00:31:38,880 --> 00:31:44,360 Git is something that developers understand platform people understand, you know, it's like, 492 00:31:44,440 --> 00:31:45,760 Hey, commit this thing. 493 00:31:45,760 --> 00:31:50,880 And then all the other things will happen is super compelling for a lot of organizations. 494 00:31:50,880 --> 00:31:56,460 And, and, you know, and as far as like containerizing and on all the interesting stuff that's happening, 495 00:31:56,460 --> 00:31:59,620 there's so much going on right now, like build packs. 496 00:31:59,620 --> 00:32:04,660 Um, and I know, uh, red hat has like a source to image system too, where like with build packs, 497 00:32:04,660 --> 00:32:07,780 let's look at the source code and figure out how to make the container image without you 498 00:32:07,780 --> 00:32:09,500 having to understand how to write a Docker file. 499 00:32:09,580 --> 00:32:11,060 But then I go to another organization. 500 00:32:11,060 --> 00:32:14,280 It's like, no, we really liked the declarative nature of Docker files. 501 00:32:14,280 --> 00:32:16,120 Like it declares what's going to be built. 502 00:32:16,140 --> 00:32:17,060 It's super clear. 503 00:32:17,060 --> 00:32:19,360 Like we like this, like, and that's perfectly fine. 504 00:32:19,360 --> 00:32:25,700 So, um, I, I think, I think there's definitely a lot of fragmentation to answer your question 505 00:32:25,700 --> 00:32:28,380 as far as like how all these things fit together. 506 00:32:28,540 --> 00:32:33,100 But at the same time, that fragmentation is like a lot of healthy variants because there 507 00:32:33,100 --> 00:32:36,740 are simply so many styles to deploying and building software. 508 00:32:36,740 --> 00:32:42,540 And I think Kubernetes can support the, the 90 percentile of those, of those approaches. 509 00:32:42,760 --> 00:32:43,240 Okay. 510 00:32:43,300 --> 00:32:43,440 Yeah. 511 00:32:43,440 --> 00:32:49,020 So given all of that, do you think like, like what, how mature of an organization, I guess, 512 00:32:49,060 --> 00:32:53,420 technologically, and, and because maybe some of the diversities of this, the function of 513 00:32:53,420 --> 00:32:58,380 the, the, the technological maturity of companies that are adopting this right now, but how, 514 00:32:58,380 --> 00:33:03,360 like in order to do Kubernetes well right now, I mean, what kind of, you know, if we look 515 00:33:03,360 --> 00:33:07,200 at digital transformation or throw or cloud native or throw or modernization or any of 516 00:33:07,200 --> 00:33:11,620 these kinds of bigger picture things, how far along that journey does someone, does a company 517 00:33:11,620 --> 00:33:15,920 need to be to really be able to take advantage of, of Kubernetes effectively today? 518 00:33:16,620 --> 00:33:16,960 Right. 519 00:33:17,480 --> 00:33:22,560 I think, I think a good starting point, and I'm sorry to generalize here for everyone 520 00:33:22,560 --> 00:33:26,540 who's listening, but I think a really good starting point is like thinking about the things that 521 00:33:26,540 --> 00:33:31,880 Kubernetes solves and whether it's actually aligned with problems you need to solve today. 522 00:33:32,460 --> 00:33:40,400 If you look at your current setup and your software is, I don't know, let's say buggy, 523 00:33:40,480 --> 00:33:47,020 it has stability issues, it has X, like Kubernetes is probably not going to fundamentally solve that 524 00:33:47,020 --> 00:33:47,380 problem. 525 00:33:47,520 --> 00:33:51,800 In fact, it might distract you from actually solving real problems. 526 00:33:52,100 --> 00:33:56,720 You might actually need application work and re-architecture of apps, and maybe you need 527 00:33:56,720 --> 00:34:00,920 to put a microservice back into a monolith or a monolith needs to be broken up into a microservice. 528 00:34:00,920 --> 00:34:06,460 Those are things that Kubernetes inherently shouldn't be viewed as, in my opinion, as a forcing 529 00:34:06,460 --> 00:34:07,300 function to solve. 530 00:34:07,460 --> 00:34:12,200 So the way I'd say it is like, be weary of that really ambitious engineer that comes into 531 00:34:12,200 --> 00:34:16,580 your org all of a sudden and says, oh, and we should add Kubernetes to our roadmap, unless 532 00:34:16,580 --> 00:34:20,440 there's really good alignment for why that should occur. 533 00:34:20,600 --> 00:34:24,680 Not to state the obvious, but that why question is super, super critical. 534 00:34:25,260 --> 00:34:30,180 Now, as far as maturity goes, you know, maturity can mean so many things and has so many different 535 00:34:30,180 --> 00:34:31,020 axes to it. 536 00:34:31,140 --> 00:34:35,540 But, you know, again, the first starting point is like, will the things Kubernetes solves 537 00:34:35,540 --> 00:34:36,700 actually help us out? 538 00:34:36,720 --> 00:34:40,720 And then you take a step up from that and say, do we actually have organizational experience 539 00:34:40,720 --> 00:34:41,400 running Kubernetes? 540 00:34:41,520 --> 00:34:44,980 And if the answer is no, how quickly could we get spun up on it? 541 00:34:45,240 --> 00:34:52,780 Are we cool with using managed services like Google, Amazon, Microsoft, VMware services that 542 00:34:52,780 --> 00:34:59,300 give us Kubernetes in a much easier way that negate the need for us to manage the control 543 00:34:59,300 --> 00:35:00,060 plane and otherwise? 544 00:35:00,140 --> 00:35:02,340 That'll take a lot of operational burden off you. 545 00:35:02,660 --> 00:35:06,600 But if you're evaluating like, okay, we have a lot of operational maturity and we want to 546 00:35:06,600 --> 00:35:07,580 run our own cube. 547 00:35:07,860 --> 00:35:11,600 Are we ready to handle lifecycle management concerns of the cluster? 548 00:35:11,860 --> 00:35:15,160 Are we ready to handle building on top of Kubernetes? 549 00:35:15,240 --> 00:35:18,700 Because remember, it's rare that Kubernetes in and of itself is enough. 550 00:35:18,780 --> 00:35:21,120 It's usually a foundation we build upon, right? 551 00:35:21,240 --> 00:35:26,140 So it's really just kind of being honest about what would that future state look like? 552 00:35:26,540 --> 00:35:28,620 And what's the engineering effort involved? 553 00:35:28,700 --> 00:35:30,960 And I'm not going to say you're going to be able to get that number right. 554 00:35:31,020 --> 00:35:33,400 Like we need this many humans and this many hours. 555 00:35:33,400 --> 00:35:39,620 Obviously, that's naive to think it's that simple of algebra, but trying to just have that kind 556 00:35:39,620 --> 00:35:46,480 of sit down moment where you really think about the benefit to cost analysis and really understanding 557 00:35:46,480 --> 00:35:47,060 your team. 558 00:35:47,180 --> 00:35:52,320 You know, going back to that startup Heroku example I gave where I said, if market shares 559 00:35:52,320 --> 00:35:54,180 your biggest thing, maybe cube isn't right for you. 560 00:35:54,400 --> 00:36:00,500 On the flip side, if I land on that team and there are a bunch of really amazing system engineers 561 00:36:00,500 --> 00:36:05,580 and Kubernetes experts, and heck, maybe they know more about Kubernetes than they do about 562 00:36:05,580 --> 00:36:08,860 Heroku, I'd be open to having that conversation about Kubernetes. 563 00:36:09,040 --> 00:36:09,440 Heck yeah. 564 00:36:09,640 --> 00:36:11,940 Let's spin up something on a cloud provider. 565 00:36:12,280 --> 00:36:13,980 Let's run our app stack on Kubernetes. 566 00:36:14,660 --> 00:36:15,160 Done deal. 567 00:36:15,540 --> 00:36:20,800 So all of these have gotchas and kind of corner cases, but generally speaking, I hope that gives 568 00:36:20,800 --> 00:36:25,820 kind of a sense of how I would at least view that question about maturity and timing. 569 00:36:26,420 --> 00:36:26,900 Yeah, absolutely. 570 00:36:27,080 --> 00:36:32,400 I think it's a matter of having heard customers talk about this too in various formats, right? 571 00:36:32,980 --> 00:36:37,060 There's this idea of, right, sometimes like their applications just are not ready, right? 572 00:36:37,100 --> 00:36:41,060 They need to be like, you know, from an architectural standpoint, you're just in your team. 573 00:36:41,520 --> 00:36:42,540 You don't have people who can work with. 574 00:36:42,620 --> 00:36:43,020 So that's right. 575 00:36:43,260 --> 00:36:44,100 That's kind of what's getting at. 576 00:36:44,100 --> 00:36:48,680 It's just like, it's just not, if you're a fortune 500 company, like you might have some 577 00:36:48,680 --> 00:36:53,520 fantastic, fantastically talented people and modern stuff in some parts of the org, but 578 00:36:53,520 --> 00:36:57,580 in other parts, right, it might be looking like it's the 1980s. 579 00:36:57,680 --> 00:36:59,960 And so I think that's perfectly put. 580 00:37:00,080 --> 00:37:05,260 And if I could just say something, it's like, we all have an insanely long list of problems. 581 00:37:05,640 --> 00:37:10,040 And I just want to make sure that you know that Kubernetes solves the important ones up 582 00:37:10,040 --> 00:37:10,320 top. 583 00:37:10,320 --> 00:37:14,760 And if it doesn't, maybe injecting it is actually going to cause more work and pain 584 00:37:14,760 --> 00:37:16,260 for you than it's going to benefit you. 585 00:37:17,500 --> 00:37:17,860 Right. 586 00:37:18,120 --> 00:37:18,340 Okay. 587 00:37:18,880 --> 00:37:20,780 So anything else, Josh? 588 00:37:21,360 --> 00:37:22,940 Or is that a good ending place? 589 00:37:23,480 --> 00:37:25,800 That was, I think, a good ending place, at least for me. 590 00:37:25,860 --> 00:37:27,680 I super appreciate y'all having me. 591 00:37:27,740 --> 00:37:30,260 It was great to kind of throw some thoughts out here. 592 00:37:30,380 --> 00:37:32,760 And at least, again, a lot of this is just opinion. 593 00:37:32,900 --> 00:37:35,180 So it was great to be able to kind of voice my opinion. 594 00:37:35,180 --> 00:37:38,220 And I'm super interested to hear what people think. 595 00:37:38,900 --> 00:37:40,320 No, we love having you, Josh. 596 00:37:40,340 --> 00:37:42,400 We're going to have you back for a GitOps discussion. 597 00:37:43,000 --> 00:37:43,640 Let's do it.