Kubernetes as enterprise architecture, with Rick Clark

Episode 178 · 33:40 · SRT · archive.org · all Tanzu Talk

Well, hey, everybody. This is another dual episode of Tanzu Talk. Rick and I recorded this live streaming on the Tanzu TV. You can go check that out if you go to Tanzu.tv. It's all sorts of great shows we have there from programming to operations to this one. There's an upcoming one that's all about architecture and design of software and things like that that I'm looking forward to, sort of an interview format. And if you're watching this in video form, you should also subscribe to the podcast, which has all sorts of podcasting interviews we've been doing for years on Tanzu Talk. So anyhow, in this conversation, you know, Rick and I talked for quite some time, and I wanted to edit it down to just highlight one bit. If you had wanted to see the full thing, you could have tuned in live to see all the stuff that I took out. I mean, it was fine. I just thought I would focus at some. But anyways, we had been talking about something that Rick has been seeing with large organizations he talks with. There's, of course, lots of people who are interested in getting Kubernetes up and running and are kind of trying to fit that into their overall idea of improving the way that they do software. And he's been noticing, as have I, that there are many sort of perspectives and theories about what Kubernetes is and why you would be using it. So one of the things I've been thinking about recently is that there's this very implied enterprise architecture architecture that's in Kubernetes based on the constraints that it puts on you and the way that you need to organize your applications. Well, I mean, I'll get into it when I jump into it. But you can see where we pick up in the conversation is I kind of lay out this idea that there's an enterprise architecture and then we go from there. So enjoy. Yeah. And, you know, to start to pull apart a perspective of this platform that you're building, of Kubernetes that you're standing up. I was watching, you know, a couple of weeks ago, we had SpringOne platform and there's a, there's a good, I think kind of a good 27 minute tour

of, of Tanzu Kubernetes and all the ancillary things around it, the portfolio that Tiffany on my team did. And it's really, it's fun to watch it because she kind of starts off from here is, here's kind of like a dashboard, a visual of what everything looks like. Here's how you manage multiple cross clusters. And here are some of the other things that you'll need to be able to do, like, uh, have configuration and policy backing up things like all these, I keep saying ancillary, but all these supporting things, uh, that you layer on top of it. And then she even manages, uh, well not manages, but she manages to fit in, uh, deploying like the spring pet shop. Right. So, and kind of showing some of the basics of like, if you have an application, here's how you kind of break it up and deploy it and you can see it running, uh, you know, across whatever infrastructure that you have. And then also here's an example of like using, um, we call it, uh, observability now, but it's wave front and how you can kind of trace a request that goes through, uh, your application and how that surface is up there. And I think, you know, early on, when, when, when I was learning about Kubernetes, at least I sort of assumed that a lot of everything that I went over was like what it was. And I remember, I remember last year, I spent a lot of time to actually, uh, learn and look things up. And, and just recently, like the conclusion that I've come to, uh, is, and, and you kind of hinted at this, but is that essentially I struggle with what's, how to describe it, but it's sort of like a standard set of interfaces and practices that are codified in what we used to call APIs. I don't know what all the still APIs. Yeah. What, what all the cloud native people mean when they say API is confusing to old programmer me, but I, I think what it means is like a standard set of data formatting and steps that are taken. And then also what I would call an API,

just like, here's some methods that you call on a thing, right? Like here's some operations that you call, but they sort of mean the combination. So you got two separate things, right? So I think you've hit on the, this is the real value of Kubernetes. It's what people miss, right? Yeah. The value of Kubernetes is that the industry and the world is coalescing on an interface for, uh, deploying and managing infrastructure, right? Those that, that matters a lot more. If you look at containers, um, what Kubernetes does with containers, that's not actually that interesting. Yeah. You're small evolutionary steps from a PC on your desk, right? It's, it, it is marginally more efficient than virtual machines. Right. It is on its own. That part of the technology isn't exciting. What's exciting is that we shouldn't have to care about this stuff anymore, right? We should have this default API, this interface into these things. That's, that's the important part. You know, that, that's the thing that, that, that matters to me. And I think that's what a lot of people miss. People think that Kubernetes is, is somehow this, uh, miraculous thing. And it, it, it's, it's, it's not, it's that it's becoming a standard. That to me is the big thing. I mean, that's what actually adds the value that there's a standard and, and what's underneath that standard, what's underneath that interface can change. You know, I'm, I, you, you have a long history in OpenStack and I, and I'm curious, like, like that was the goal of OpenStack as well, right? Like how would you have, I was thinking about that this morning. So yeah, the, the, that was the goal of, of OpenStack initially. I think, you know, some serious strategic mistakes made that not happen. In fact, in 2011, I actually, um, was pitching at OpenStack at the, the third summit, a project called Donabe, which was container orchestration in 2011 that no one got behind. Same, same basic thing. Um, so yeah, there, there's, that was, that was the goal. Um, and it'd, it'd be interesting that that's a whole nother topic.

Why that seemed to, why that missed the mark. Yeah. Yeah. But was it, was it a similar goal that, that people were following? Like, I think it's instructive both on the, for the community that, that, that like is creating Kubernetes, but also for the people who are trying to use it. Um, because I mean, the way we opened is like kind of a build buy versus decision, right? Like what, what do you want to build on your own versus buy it? And, you know, in the OpenStack days, um, it seemed like there was a lot of building, right? Like, like, and I was never sure if that was encouraged or not encouraged. I mean, I guess there were a lot of vendors selling distros, but I remember there was one story, I forget who it was, but there was this, this infamous story in the OpenStack world of one, one big company that had built their own and they quickly like fell behind on, uh, on getting the new versions of OpenStack. That probably comes up quite a bit, but it was, uh, retold over and over again. And it seems like, it seems like the same lessons would apply between the two. Absolutely. And even, you know, even if Kubernetes is done better, right? Even if it's more, it's, it's integrated better and it, it upgrades more easily. Um, it, it's still, it's still, once you start integrating with other things, once you start integrating it with your stuff, you know, you've got a problem. You've got a problem where the, if the API start to change, you, you can't update and you get stuck. And that's, that's, that's the same problem. And that's, that to me is one of the biggest risks of, of, of DIY of building your own. I mean, it's, it's really, to me, it's no different than a Linux distribution. You know, you, you, you wouldn't, you wouldn't build your own Linux distribution. And I have experience with that. I, I, I, um, led the team that created Ubuntu server and it's not easy. Um, but I saw, I've actually seen companies think that they should build their own. And I've seen, especially startups think they should

build their own Linux and think that there was value in that. And they, they all failed and they all were wrong. Um, they all ended up with, with problems. They, they didn't keep their main thing, their main thing. And, um, and I, I think that's one of the biggest risks with Kubernetes is you end up being an IT shop that does nothing but care and feeding of Kubernetes and other things that actually move your service, your, your customers, the business, those don't get done. And back to the disconnect we always talk about. Yeah. Yeah. Yeah. Yeah. The, uh, way up there is, uh, your, your customers wanting to do things with your software and then way down below is, uh, configuring YAML files, like is, is, uh, what things about to break it into two chunks of, of things we've talked about in the past. The first chunk is, uh, something, you know, we'll skip over the first chunk, which is like, you're, you're not, you're choosing to spend your time on plumbing basically. Right. We can return to that. But the second thing that I'm always intrigued with, and my dog is getting very excited about it is, is all of the things that need to be added. Right. Like, I think, I think you kind of alluded to this, like integrating with your systems and your policy and, and kind of crafting those things. And like, there's even, even more than that. I mean, so the thing that people miss and something that I think that, I mean, this is one of, to me, this is the biggest, one of the biggest advantages of Tonsu that VMware offers. Um, you have to build containers, building containers and managing containers is probably the most complicated part. Once you get stuff set up that, you know, anyone can read a guide and set up Kubernetes. But if you can't build and manage containers, well, you're going to end up with a giant cesspool of a mess and the Tonsu build service, which, you know, is the descendant of, um, of the build service and PCF. It does that beautifully and,

and lets you, lets you make sure that you have upgradable applications, not just an upgradable, manageable Kubernetes infrastructure, but the, the applications on top of it. That's really, really important. Right. And so, so that's like the first major thing is the, uh, what would you call it? The, uh, front loading, right? Like, like, and, and, and describe, like, describe what that process is, right? Like, so I'm a developer here writing code and I'm done writing the code. Like, then what, how do, how do I get my feature, uh, running on the platform? Like what, what, what's all the stuff that goes through that? Well, you know, so, so that's, that's interesting. So if you do this from the, in my mind, what, what I think should be and what most companies are doing are not the same thing. Yeah. So, um, I think that you should, you know, you should have a developer, they should write a spring app, they should commit it. They should do a get pull request. And that is their interface into the system. If they have to know they're using Kubernetes, they have to know the environment. You've sort of already failed. Everything should be CICD driven, getting something from the developer's laptop to, to production. And what I see more often, and this comes from sort of the fallacy that developers want Kubernetes and that some of them might, but they shouldn't. Right. It's like saying it, drivers want asphalt roads. You know, I don't really care what my road's made of. I just care where I'm going and they should care where they're going. And the whole goal of this, the whole goal of all of this, right, is to accelerate your development and to remove barriers, to remove things that are not important, things that they shouldn't have to care about. If they're writing something that tokenizes someone's identity, you know, to, to anonymize them for, for an app, they shouldn't have to think about, uh, Kubernetes. They shouldn't have to think about the environment. They should just write that

business line. There is another thing that I kind of disagree with, which is the full stack developer. Um, they're, they're wanting people to be full stack developers. I'm going to build the OS. I'm going to build all the different parts. I have to know everything. And I don't think that's efficient. I don't think that's the way that you quickly get something from, I, from ideation to production. I think that, that you have to have all that stuff done in the background. You have to have automation that handles that. And there's a lot of complexity underneath having that kind of automation. And that's what Kubernetes provides. If you do it right and you use the right distribution, like something like, like times, it provides all of that for you. The issue over the years that you encounter with like, uh, a full stack developer is, is what you've already alluded to is, is just how you prioritize your time, like, like your resources of time and attention and all of that. And, you know, I, I don't really know the generalized case, but it seems like, you know, spending time on your platform is often not worth it. Like building your own platform, right. And doing your own configuring. Now, I think, you know, I, I think the idea of a full stack developer like came about in maybe the late 2000s, the early 2010s when there were no other options, right? Like, like if you wanted to do things at web scale, you had to like build a bunch of your own stuff, right? Like you had to figure out how things fit together and build it out. And so there was probably some validity back then, but to the, you know, there wasn't more of a standard way of doing all of this and an understanding of how to package things up and make sure that it's manageable. And so, you know, there's still kind of this lingering idea that you need to be a full stack person to like be a great developer or to do any development at all. Whereas I think nowadays, there's plenty of, uh, there's lots of understanding and tools and platforms like things like Kubernetes

kind of filled out that will, uh, do those things for you. Right. So you don't really need to have that huge skillset of, of doing everything. Well, and you know, not needing to have it. That's one thing. Most people don't have it. That's the, the, if you think you're going to hire a bunch of people that, that know the stack from top to bottom that can replace a sys admin for you, they can replace all of those different, uh, knowledge sets that people have. I, I mean, unless you're a startup, a very small startup, I don't think that makes sense at all. I've, I've, that's never made sense to me. I mean, the, I came up through operations through system administration. I was an infrastructure guy. Right. And, um, I can't imagine the developers being able to do, do their jobs without me providing that infrastructure and that base for them. And really, I don't think that that's really changed. I think that's what the platform team should be doing. They should be, they should be supporting with, with the way they deploy Kubernetes, with their automation, they should be supporting developers so that they can not have to think about other things, write your business logic, man. You shouldn't have to think about anything else. So, so I think, I think like in the delivering on, I think, I think if we were to take, if we were to take like an infrastructure person's idea of who their customer is, right. And in our conversation, it's developers, right? So they want to provide value to their customers and sure, ultimately you want to do it for your organization, but that's kind of the most immediate customer that you have to deliver to. Uh, so you've identified one thing that's part of, of all of this, just the, you know, the build path, right? Like, like putting, putting your pipeline in place and making sure you can do that. Another, another thing that, uh, that, that you mentioned, or that, that I forget if it was when we've talked before or when we're talking now, but as this idea of like how you enforce governance and policy

and how, how that gets added in versus kind of being more open and free floating. And I feel, I feel like with my limited technical understanding of Kubernetes, there are ways of enforcing policy built into it, APIs, if you will, but to a certain extent, how you implement those and how you kind of do it at a, at a large scale or sort of left up as an exercise to the reader. There's a lot of choices of, of how to enforce those things. The other area of, you know, it's interesting and kind of just thinking out loud about this, all of a sudden you're getting like enterprise architecture involved to, to specify, like, here's the types of applications that we want to be running. Here's like the policies that they need to follow. And here's how we enforce those policies, right? You can use this framework, you can use that API, but you shouldn't use this one. And you've got to follow this stance so forth and so on. And, you know, getting back to the idea of how you're spending your time building out this platform, that seems like a lot of time that you need to spend deciding on all those things. And I, and I think, so that architecture being, uh, like basically distributed application, right? Where, where you, you've broken up your application into smaller components that coordinate with each other over a network. And, you know, they need a registry to look things up and do service discovery and all of this kind of stuff. That's, uh, that's all very exciting. Um, and I think by nature of having to put things in containers and then also having this very constrained, um, I don't know, connection policy, the way that various, uh, containers in nodes and pods can talk with each other in, in Kubernetes, it really has this like limiting effect on how you can architect your application. And more importantly, if you want your application to be, uh, like manageable in

production and to be able to do all sorts of things like, you know, uh, all, all the great things like rolling upgrades and kind of separating out to get all the benefits, you really have to like separate things out and put a lot of thought into how you're architecting it. And it feels like the way, uh, that Kubernetes things were built was exactly around this application architecture and, and it's to service this way of doing applications, which I think, I think what that, you know, why, why I get interested in this is it's kind of moving further up the stack of things to pay attention to that you're alluding to where I think sort of like understanding that this is our new architecture and therefore that's what we need to kind of focus on that, you know, when we go to our customers, what we're delivering is this architecture to them in the same way that like way back when for better or worse, the architecture we were delivering was like an ESB with, with data change in our formats. And, uh, or we were delivering like J2EE as an architecture to them. And, you know, what, what I'm interested more of like going forward is this discussion of like what that architecture is and, and what, what the, the best practices, uh, that people follow it are. Like I was watching another talk from, uh, from Swing Run kind of going over like a comparison of what was it, uh, Spring Cloud stuff and Istio. And it's like very minor, like what a service mesh does for you seemingly, but it has this great, like, uh, there's, it's that, that presentation is a great view into how you coordinate all those little nodes talking with each other. And therefore this is like the architectural focus of the application that you're doing, right? Like this is, this is how you coordinate and describe all the lines and dotted lines between things. And it seems like in contrast, a lot of the effort people are spending on Kubernetes now is basically on like getting it up and running and

building it and kind of, you know, getting to that blinking cursor instead of, instead of describing, like, here's the patterns of how to do applications. And here's how you, uh, you move forward with it. You know, I, I think some of that's intentional. I think that, um, there's kind of, uh, a movement, a trend to think that developers need infinite flexibility, but infinite flexibility is sort of the, the opposite of where we've been going with, with, uh, the cloud, cloud native, right? If, if you want things to be fast, if you want to do things quickly, if you want things to be maintainable and scalable, they kind of need to be uniform, you know, and, and, and I think another fallacy that, that's, that's out there is that developers need access to, you need, you could end up with a problem. So you have to have access to everything. I need to be able to use everything. I need access to every tool, to every library, to every service. But, um, I don't, I don't think that's actually true. You know, I think that you, you, uh, you lose a lot and I think, you know, like I'm looking for a house right now and it would be a lot easy, easier for me if there was only one house. I have to look up in Atlanta, there's a million houses and I'm spending a lot of time instead of just finding the house and moving, I'm spending a lot of time thinking about it. And while that's maybe good for finding a house, cause I want to find the right house. That's not good for a developer. If, if I have to spend time figuring out what tools to use, what libraries I need to use, what language you need to write, I, I think that that is not efficient. I think that's not modern. Um, and I think that 95% of what we do is the same across every application, across every industry. You know, 5% might be unique to, to, to, to the project you're doing or to your company, but we all basically do the same thing. So we don't, we don't need,

we don't need the confusion and the chaos that supporting every single thing in the world we give you. Right. But if you're, if you're, if you're an infrastructure team, you can create a list of the things you support and it looks pretty good for you. Look at all these things that we support. It's just, I think it makes it harder to be a developer. It makes it harder to actually get your business code out there to actually push your stuff. And you know, the, the key, the goal, right, is to get from ideation to production quickly. It's the path to production. And if you put a thousand more decisions in there, you're not speeding up that path. You're slowing down that path. And I guess one of the reasons I joined Pivotal is that I'm, I'm a true believer in, in that way, that walled garden that, you know, support 90% of what people need to do. And that's most of, most of everything. Yeah. Yeah. It's sort of, sort of like using constraints to reduce variability. Right. So instead of having a lot of options or choices, I mean, this is the, uh, was it, uh, was it in the nineties? There was, I think it was, uh, that Ruskoff guy who introduced the idea of like the serial row is overwhelming. Like not, not here in the Netherlands, but maybe since you're back in Atlanta, you've now encountered this where you go to the serial row and there's just like too many choices, right? Like there's, there's hundreds. Would it be hundreds? Well, there's probably, I think it's hundreds. Yeah. There's probably, I mean, it is 80 to 150 different options for cereal in, in, in an American grocery store, not to mention the various, uh, what would we call them skews? There are, there are cereal sweets in the cereal row that you can choose from, like the raisin brand sweet that you can buy, uh, all sorts of things from. And it does seem like shredded wheat sweet. Yeah. You definitely have those. And, and it does, it does seem like that is, um, to your point, right? Like if you're thinking about if, if, if you're an infrastructure person thinking about your customers as the developers that you're trying to basically speed up their work, right? Make it

easier for them to, um, think about and get features out faster because there's all sorts of positive benefits to that. Then there's a balancing act between giving them like the tools they need and giving them some amount of choice, but also like not too much choice, right? Sort of constricting down to a standard. Um, and there's all sorts of issues that we've encountered over the years with that, when it comes to sort of like evolving those capabilities long-term and kind of integrating in like this year's new learnings, instead of getting stalled out in like a three-year-old or four-year-old stack. But I think, I think that's another thing that like, when you look at the cloud native style of developing, like it really tries to give you a minimal set of things you can do, right? Like, like there's a very small set of concepts of how you package things up, how they talk with each other. And that's kind of it. Like you're not left to just decide to do things willy nilly any way that you want. It's you're not sort of like, here's a server connected all together. Like it's, it's a very constrained environment for you. Yeah, that's just absolutely right. And I think that's one of the problems we're seeing with the way enterprises are doing Kubernetes is they're losing track of the cloud native part of it. Like, you know, the, the, and I think that's because of the thing that drives the, you know, both the infrastructure team and the developers. Developers love to use different tools. You start using different tools, those just, that pads your resume, right? And the, the infrastructure team loves to build complicated things because that's, that's fulfilling. So I think we've kind of, there's, we're psychologically set up to make this more difficult, but we're losing the cloud nativeness. Can you say cloud nativeness? Well, you just did. We're losing that. So I think you can. Yeah, we can't say it. Yeah, I said it twice. Um, so I think we're, I think we're losing it. And what we've done is taken,

and, and I see this. So we've taken the old enterprise architecture and jammed it into, uh, Kubernetes. We've made Kubernetes as complicated as the old enterprise architecture and lost some of the cloud native value, but you don't have to, you know, you, you, you don't have to do that. It can be done right. I think there's three main points that like, like we, we should, we should think about and then get back together to discuss one of them being, um, this idea of, is, is it a valuable idea to build out your own things, which, you know, coming from two people who work at a vendor is a highly suspicious conversation to have from us, but I'm also someone who likes to build things. So, I mean, I think that I think so I, and we can deal with this tomorrow, but the answer is yes, but. Right. Right. Right. And, and I think, I think as always with that, that kind of supposition, uh, what's important in the discussion is to kind of like frame and model, uh, what your requirements are like, like why, like why you would be building something on your own and what you would be achieving with it and, and like what the drivers are. Sometimes it's good. Sometimes it's bad, whatever, like who knows, but just kind of more knowing like the context of it instead of just assuming that you should always start with that. I've got a whole model I use to decide whether to build or, or to buy. And, and we can talk about that. See that, that would be nice. And then I think the whole matrix, I need a name for it. So maybe someone can help me name it. And then, and then I think the second thing, I don't know the order of the second there, but the second is, is to use your phrase, losing the cloud nativeness. And, and I think, I think what that means, what, one thing that means is that if you are an infrastructure person in this, in this context that we're talking about, uh, your customer are, is developers and you could call them, you know, product teams or, uh, you know, software enabled businesses, whatever it's,

it's, it's the teams of people who are working on features for the software that is helping run your business or kind of be the storefront to your customers. Right. And you're doing that primarily through a software, but the customers, the infrastructure people have are those, those teams, those, those people who want to build that out. And then, and then the third thing that, you know, it's easy to lose track of that. And, and the third thing that I think kind of follows from that is that what you get with Kubernetes is a type. I'll just call it. This is an enterprise architecture. And like any enterprise architecture, it can be subverted and munged around. And you can always just end up running a monolithic application that requires on a scale up architecture to perform well. Like it's, it's easy to arrive there. But if you, if you kind of follow the enterprise architecture more, it's basically just like, here is a constrained set of ways, uh, to write a distributed application. And here's how, here's how we'll specify how everything talks with each other. Now, I think the fourth part after that, which is, which is the part we haven't got around to, which is like, all right, so we got that. And what's every single thing else I need to install to, to, to make things work well. Like we talked about the infrastructure layer a little bit, but I think if you kind of start off with that goal of a product that we're trying to build, right, this platform, you know, everything else kind of follows out of that. Like all of the kind of governance and security that you need, uh, the monitoring and observability, and you sort of kind of start to build up this, uh, this, I don't know, you can product manage out of platform, uh, which I think, I think is, is useful for doing over the longterm. Cause that, you know, going back to my original question, when the, uh, the infrastructure people are looking at an empty whiteboard, that's what they're going to be building out, right? Like that, that kind of drives all the

different components and, uh, the teams that they need, but we'll see. Perhaps we could, uh, pick this up tomorrow or some other time this week. And, uh, I'm sure we'll have thought of something that has nothing to do with my summary by then, but we can, uh, we, we can try to fill out the rest of that whiteboard. Well, uh, for people who are only listening, do you have a Twitter handle or someplace someone can go to follow you? Oh, I do. Dendrobates. D-E-N-D-R-O-B-A-T-E-S. Now, have I ever asked you, what is that? That is the genus for poison dart frogs. Oh, poison dart frogs. Okay. What makes them dart frogs? And like, do they, do they like go forward? Because they, because, you know, because traditionally, um, you could dip your arrow or dart in there on their skin, rub it on their skin and it would paralyze something. Huh? But so that one of the reasons I have the, the, the, the, the, I use that handle, which I've used for decades now is, um, they are only poisonous in the wild. They are, um, they are, they are completely tame and safe in captivity. Just like you, I guess. Just like me. Yes. Yes. Now, now we need to do, have some sessions to define what the wild is versus captivity for you. That that's, that's the, uh, the next layer there. Yeah. Yeah. Yeah. That's good. I like that. Well, you know, I bet, I bet there's, there's a name for, there must be a word that describes naming something based on the function it gives humans, right? Like, like sometimes we call cow beef, right? And, uh, you know, like, like it's not named based on its own virtues, but the way that it's used in our, what we do with it on the whiteboard, so to speak. Yeah. And pork, but chicken is pretty much chicken. It's, it's, it's interesting, interesting linguistic thing. Yeah. I like that. Whereas, you know, an eagle isn't called like mascot, like, or you would think over the years, a lion or a bear could be called. Anyways,

uh, that's, that's, uh, an idea for another time anyways. So, uh, as always, this has been a, uh, a little Tanzu talk episode. If you want to get the show notes, I mentioned a couple of videos and, uh, maybe I'll put in a link to a dart frog, but you can go to tanzu.vmware.com/podcast and look that up. And also, uh, if you're listening to this, uh, you should check out the schedule that we have for the, uh, VMware Tanzu, uh, streaming. It's, it's fun. And you get to see the, or I guess you see, you get to see and hear the sausage being made. Uh, you know, it's, it's, uh, that can be, which everyone should do. I mean, that's really important. They, they recommend that before you eat sausage, you should see it made. Exactly. It's, it's, it's, there must be some alternate phrases for that, that, uh, I need, I need to look up, but, uh, if you want to get on that, you can go to, uh, uh, twitch.tv/vmwaretanzu, and, uh, there's all sorts of other things that you can look up, but we'll see everyone next time. Bye-bye. Bye-bye. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.