DevSecOps in Practice with VMware Tanzu - A Discussion with the Authors

Episode 256 · Fri, 17 Mar 2023 12:26:55 +0100 · 48:58 · SRT · archive.org · all Tanzu Talk

We're starting a new series here, Cora and I. We're going to, you know, whether it's books or articles or just some idea that we had while we were doing something, but you're sort of having a conversation about some artifact. We don't really have a name for it yet. But to kick off, Cora thought, had a great idea that we should check out a book from some of our former co-workers called DevSecOps and Practice with VMware Tanzu, which I read through it, and it was a great overview of the different components of Tanzu and what they do. What about yourself, Cora? How would you kind of summarize this book? Well, so, I mean, in the title, you'll have this idea of DevSecOps, right, with a particular product coming from VMware. So the breadth of it is quite wide, touching the interests of developers, of operations, of security, and sort of this idea of managing software end-to-end with a platform that's built on top of Kubernetes. And so the book does a really great job. I really enjoyed reading it as well. It does a great job of laying out what the challenge is at every stage in this end-to-end process. Challenges for developers, challenges for operators, challenges for security teams. And it just kind of goes step-by-step presenting the answer to that problem from within the Tanzu suite. And so Tanzu itself is a platform that is an opinionated, curated, and integrated sort of coalition, I guess, of built on top of a lot of open source projects. And so the book is divided into three sections, build, run, and manage. So in the first section of the book, it talks all about building applications. In the second, it's more about how you get them to runtime and that initial runtime platform.

And then the last part of the book is about managing them at scale. When you have many Kubernetes clusters, many applications running on many clusters, how do you actually do that as an organization? So I think it brings to the forefront this idea of what do we mean by a platform in this modern day and age because it does a platform today, I think, addresses the needs of developers working to manage a lot of different applications and APIs and collaborate, and then the actual pipelining, moving of those applications securely and reliably to production, and then making sure that everything is running in production well and that you know what's going on there across a fleet of Kubernetes clusters. But I think the book, it covers all of that. It describes the problem in general, and it shows you the solution that VMware is offering through the Tanzu. So yeah, it does a great job of all of that. So yeah, I really enjoyed it. And I'm looking forward to talking to the authors. Yeah, yeah. And as you're saying, right, like there's, if you break down the process of getting your software into production, you know, figuring out how to package and containerize it, all the stuff, more or less aside from coding, like, like that's, there's a little bit involved in coding when it comes to like the gateways, the API gateways and things like that, that you would use. But it's mostly about the running of your application and the way that it's configured and the way that it goes through the factory of how you're creating it. There's a whole bunch of components involved in there, and they do a great job of kind of identifying all those components in a cloud native app and describing the different components of the Tanzu portfolio that addresses it. And, and also at the beginning, it's great. There's, we, we get a fifth guest that was very excited about a squirrel, which, which I enjoyed.

First, let's have the two authors introduce themselves. So we'll start with myself. Thank you, Cora and Coté for giving us this opportunity to be here. I'm Parz Pandit. So to introduce myself, I started my journey as a developer beginning in 2002. And since then, I organically grew from a developer to a kind of project management. And then eventually, based on my technical areas of Intel, I jumped into the world of architecture. And then I was fascinated by how the cloud ecosystem was evolved. In 2015, 2016, and then jumped into that area. And I got a fascinating opportunity to work with Peutal in 2018. And then I learned about how you can scale and deploy thousands of containers on a platform like Cloud Foundry. And then eventually, Cloud Foundry grew into the other side of the container world. I know it as Kubernetes and Tanzu came up to the surface. So I had a very good ride with VMware Tanzu for a couple of years with VMware. And then just about the time when this book was published, I got a bittersweet moment where I got an opportunity to be a cloud architect with AWS. So I thought to even explore this public cloud domain, whereas I was mostly working in the private cloud domain with Tanzu and Peutal Cloud Foundry. And I grabbed that opportunity. So that's where we are here, mostly working in the architecture space around containers and cloud ecosystem. That's me, Parth. Thank you. Yeah, thanks, Parth. And the fifth participant in our conversation today is a completely out of control doodle puppy that I have no control over. So apologies in advance. I'm Rob. I like a lot of software people. I have a degree in such a phone performance from the University of Rochester. Wow. I quickly learned that that was not a viable way to navigate life touring around.

So I taught myself a job. I got my job, got my first coding job at a grocery retailer, a big presence in one of Coté's former hometowns. Worked my way kind of to the top there. That was, yeah, after about 16 years, it was time to do something else. I got a call from a recruiter. So I checked out the company on YouTube and there was this hairy guy in Austin talking about changing how you write software. And I said, oh, this sounds pretty, sounds pretty intriguing. So I jumped over to Pivotal where I got thrown into the deep end and learned a lot in a very short time and kind of got a front row seat at kind of changing how witnessing and helping some household name companies, you know, change how they build and deliver software. So, yeah, that was that was that was a that was a huge change for me. And, you know, I kind of witnessed the evolution from Cloud Foundry kind of morphing into, you know, into Kubernetes and then kind of landing at what we now think of as the Tanzu portfolio. So it's kind of rolling series of ever increasing abstraction kind of going from, you know, bare metal containers to cloud to, you know, container orchestration like Kubernetes and then finally to kind of a completely realized platform like Tanzu. So, yeah, that's kind of how I landed where I am. You know, there was this period in my daughter's life where she was maybe, let's say, two and a half. And every time my wife and I would start talking, my daughter would just start talking her babbling talk, like just, you know, no words or nonsense, just kind of keeping up with us. And so, like, I feel like, one, that was that was a, as they say, tour de force of professionalism to give your introduction while the dog was in the background. And it also reminded me of that that cute period in my daughter's life where she was just like, I'm going to I'm going to join into this conversation. Thanks.

I thought I was like, are you comparing your daughter to a dog? I was like, is that where you're going to be cute? I golden doodles are is it a golden doodle? There's a labradoodle, but yeah, gorgeous. But this is this is the most epic squirrel encounter we've ever had. So she's so excited for you. She's like, you wrote a book. This is amazing. Speaking of which, I'm I'm curious because, you know, normally you go to the you know, you go to the bookstore and you pick out a book and you don't know the author. And, you know, I you know, you put them on a pedestal. I still put you two on a pedestal. But but it's amazing to know the authors. Right. And to know that they're they're your colleagues. So I'm I'm always curious about, you know, what like what inspired you to write a book at all? What inspired you to write this book? And what was that process like? And I don't know, you know, what did you get out of it? Maybe if you got something out of it that you didn't expect. Yeah. Let me take that up. So it all started from a, you know, it was a kind of rippling effect when I participated in a global competition that we had internally within VMware to build and deliver a demo of end to end Tanzu. And I think I did a good job in that and marketing team noticed that and they approached me that, hey, do you want to write a blog about what you have been an end to end story about how Tanzu is solving the problem of DevSecOps, the supply chain for every step of the development journey. So I wrote that blog on VMware and that was noticed by TPEC publication that this is a good narrative of what this technology is about. There wasn't any book in the market. And being them, the publisher, they approached me that, do you want to write a book about this thing? Just expand this whole blog into a book and put more details into it. And I was like, yeah, well, I can, I can't because that was the first time I have ever thought about writing a book. I never thought of like, yes, it was always a kind of to-do list and wish list that I wanted to do, but this was it. And I was nervous at the same time because I didn't do that.

And it's a huge amount of work. So I and Rob partnered before in a few projects that we did together and I have a huge respect for him and he's always dependable. So I approached him, would you like to partner with me? This is the opportunity in front of me and I don't think I can do it alone. Let's do it together and divide the work and we can provide you good justice to it. And that's where we are. I'll add a little bit of color commentary to the Rob Parth dynamic. So the way that we were teammates at VMware for quite a few years and the way that we generally operated is that Parth would call me up and he'd say, hey, I've got this thing I'm thinking of. It's going to be five, 10, 100,000, 10,000 hours, nights and weekends, time away from family, no personal life. Life is going to be a perpetual chore for three, six, nine months of your life. You want to do it? And I say, yeah, buddy, let's do it. But in retrospect. Partnership. Yeah, exactly. So that's, you know, I think Parth would tell you that's kind of how we operated at VMware. And I think this was just the kind of the expression of that kind of working relationship, you know, like the different presentations and customer engagements, proofs of concepts that we did at VMware. They all kind of culminated in putting all of our learnings and findings in a book. So, you know, that would be my contribution. I think it's amazing. Like it's, you know, to start with a start with a demo and then, you know, that becomes a blog and eventually that becomes a book. That's an amazing story. And I think it's like, you know, people, anybody out there who's listening, who has this thought that they couldn't write a book or it's too, you know, it's too big of an endeavor. It's I think probably I imagine a lot of stories are like that, right? You start with something small and that gets good feedback and you grow it and then it takes another form. And eventually you get to places maybe you didn't imagine. Yeah, it's such a it's such a tired expression, but really the the blank page is your enemy, right?

If you just sit down and write something, you know, and get over that initial inertia, you'll be amazing at what you I mean, I read through the book now and I say, do we really write all of this? Like where did all that where did all that time come from? Yeah. And then you also have the the other the other depressing effect where you're like, I don't remember what's in this book. But we have to read it. So that if you know him, that's the other thing. Go ahead. Yeah. So just wanted to add one more thing into this mixture, like it would be unfair if I don't call out David Kramer, my ex-manager in Tanzu, who pushed me that this is a big opportunity. If you are thinking to let it go, don't do it. It doesn't happen often in life. Just go for it. I know it's huge work, but he pushed me and I eventually got into it. So big thank you to him. I owe him a lot. Yeah, I second that. Absolutely. Yeah. Amazing. So so as you were writing this book, who who were you writing it for? What was your what was the audience that you envisioned? I had a very there's there's a few audiences in mind, but really I had in mind 2015 Rob Hart, honestly, because I was writing the book for because I I was delivering software of, you know, depending on who you ask, you know, some some degree of quality. And, you know, I thought I was doing things right. I thought I was solving the right problems. And then, you know, as the as your scale and scope increases ever outward. Right. As I got, you know, I got to pivot old VMware and learn from people who are doing things at massive, massive scale that I never could have even imagined this. These entire classes of problems start to emerge, like it's like you don't know what you don't know. And then then you learn that and then you realize there's another level of you don't know what you know and there's a level after that. And so having progressed through, you know, three, four, 10, 12 kind of iterations of abstraction on abstraction, I thought, man, maybe maybe there's some value in putting this on paper and sharing it with people who are in some some phase of that journey.

Right. So you can learn what are the right problems to solve? What should you be focusing on where you're actually delivering value as a software professional? So developer, security engineer, you know, opera, you know, dev engineer, operations person, you know, dev sec op. Right. Those are our people, but really people that are in some stage of their journey and kind of increasing their value prop as an engineer. You know, like y'all spend a little bit of time in the book kind of talking about what you just discussed, like the the milieu, if I pronounce that right, that that your your ideal reader sort of stews in to mix metaphors or whatever. But like, especially with the background that y'all both have, you know, and and also having worked at a couple of different places working in the same industry, like, well, let me put it this way. When I think about like what what we we collectively here have done over the years, you know, at Pivotal and then in VMware Tanzu, like I'm 70 percent sure it's mostly for large organizations, but I don't know. Right. Like, like, like I throw that out every now and then that like to some people and then often people come back and talk about like, well, I don't know if you had two development teams, these things would apply as well. But like, I feel like, what would you call it? The the floor, like, like the you must be this high to ride this ride is like you probably need 500 developers, 200. I don't know, like, like, like, that's the wrong way to gauge the present you have or the opportunities that lie ahead of you. But like what what's especially after going through this and and, you know, seeing working at a new place like what you're thinking about the type and scale of organization that something like a Tanzu applies to part. Do you mind if I I'll start this one off, too, because I had a I had a I had an observation about this based on, you know, so I moved kind of out of solutions architecture into a kind of core systems development engineering role now for, you know, a big, big cloud provider.

So I'm kind of doing in practice what we were helping customers do at at VMware and Tanzu, right? And I realized we're we're a small team, but our pipeline to engineer ratio, I think, is about five to one, right? Like maybe between 10 and 20 developers. And last night, I don't think anybody could even rattle off all our pipelines. It's probably 50 to 75 pipelines, right? So it's not necessarily even the number of developers, it's more of the scope of what you're doing, I think is as right from more valuable, a smaller team of engineers is able to, you know, take advantage of these very various kind of force multipliers and operate at this massive scale and scope. So you might have a single team of 10 or 15 engineers, but they've got, let's say, 50 pipelines, you know, for the various products that they're that they're, you know, managing from a tool like Tanzu is absolutely applicable to them, even though there's only 10 developers, right, because the scale of what they're doing is so huge. And I don't think it's that uncommon, I don't think it's that uncommon anymore for small teams to be working on these kind of massive scale projects. So it's really, you know, I'd put it in terms as a unit of work, if you're doing CICD, like number of pipelines, right? So yeah, yeah, you've got five pipelines, you can probably manage a 10, you know, if you're a team of 10 guys, uh, and gals and people with, uh, you know, 70 pipelines. Um, you are, you know, you're probably kind of constantly scrambling, keep everything up to date, right? When a log four J comes out and you've got 70 pipelines, you've got to go check all of a sudden your life becomes very unpleasant. So maybe, maybe the inflection point where it becomes really valuable is 20, 30 pipelines, right? Like that kind of economy of scale really, really kicks in. Do you want to add anything part?

Yeah, only a couple of thoughts here that today you might be small and you might not need that complex toolkit in your, in your bag. It's about thinking what's possible, about thinking what problems lies ahead when you grow in scale and what problems that you may need to solve. So if you're small today, that's fine, I mean, we would say that just go through the book and see what are the scaling problems that you might encounter down the line and how this toolkit will help you solve them. So it's about doing the right thing from get go rather than course correct yourself, starting on the wrong foot and then find out that, oh, we have been doing this wrongly so far. And this is the right way of doing it. This is how it can be done better. I mean, it's interesting. You bring up in the book this idea that every time you solve one problem, right? You discover a whole, every, every solution to one problem sort of like catalyzes a whole new set of problems, right? There's so, uh, if you're managing VMs, uh, then containerization will solve your problem of managing VMs, but then that can explode into a lot of applications that you have to manage. And then Kubernetes is the answer to that, uh, proliferation of containers problem. So somewhere in the book, you also talk about, uh, you say two things that I think were interesting. One is that, uh, Tonsu is the answer to the problems that Kubernetes has a sort of, um, unveiled, I guess. Um, and then, uh, at another point you say that Tonsu is sort of the next generation platform. So this conversation on, on whether or not this is for only for large customers or large, you know, large teams, um, it makes me think that probably in the evolution of Tonsu, I mean, I'd like you to speak in general about this whole idea of Tonsu as the next generation and the problems that Kubernetes unlocked. So we can spend some time on that, but, um, but it just made me think that as, as Tonsu has evolved, it solved those problems of managing things at scale that Kubernetes brought on.

But at the same time, it created sort of a path the other way where, where we're also now addressing sort of point needs that are per, per application, right? Like if you don't have to be managing a hundred applications to have to make sure that your one application is totally secure, right? And so once you start looking at things at that granular level, it's hard to say this is only for customers at scale, right? It's sort of Tonsu maybe, uh, uh, spreading its, its breath so far out that you it's, maybe it's no longer just for a big scale companies, but so I know that was a lot. So I guess let's start, let me break that down for you. What are the problems that, that Kubernetes has, has brought on for us that we have to solve that even give Tonsu a reason to. You're welcome to jump in, Parth. I always have something to say, so, um, okay. Um, yeah, that's a great question. So first off your, your synopsis of chapter one was so much clearer than the actual text of chapter one. So I'm going to, uh, probably record this and maybe in the, in the next edition, I'm just going to give the, uh, core version of it. But, um, anyway, the problems, um, that Kubernetes presents you're, you're exactly right. Like there's the sort of evolving consciousness and this is why I say I wrote it for the 2015 me, because I feel like I've made a few evolutions. And, um, one thing we saw, we saw, you know, when we were back in the cloud foundry days, we saw a lot of customers doing Kubernetes and Kubernetes was going to answer all of their, you know, it's going to solve all their problem. And in the world, the high tower, you know, Kubernetes is a platform for building platforms. So each individual software team, uh, was effectively building their own platform to develop, to deliver their product. Right. Or if you're a team with, you know, 50 pipelines, each of those pipelines might, uh, might have baked into it, its own kind of mini platform for delivering that particular piece of functionality. Right. And that is, um, that is a, uh, waste of, uh, time and money and attention and brain cycles, right.

To rebuild a platform every time. So the idea is, and as an architect at a big company, you know, like, um, you think you're the guy that can build that one platform that will work for every team at the company. Right. And I've met that guy at probably 15 different customers, right. They, they, we exist everywhere. Um, the truth is, is that building platforms is really hard and building a platform that a works and delivers value and B will be adopted by all those different teams is extraordinary. And there, it's a lot harder than it sounds. Right. And so, um, the secret sauce of Tonsu where it solves Kubernetes problems is that it's got all of this kind of collective culture and knowledge going all the way back to, you know, the early pivotal days where we know how to write this kind of software. That succeeds in an organization and checks all the boxes and everybody wants to use. So it is an, it is, it's an opinionated set of components, right? So you can, you can still configure the platform how you want, but it is a platform that sits on top of Kubernetes. So the Kubernetes is the platform for building the platform. Uh, Tonsu is an opinionated, an instance of a platform, an opinionated instance of a platform that sits on Kubernetes, um, and tries to solve all those problems. Right. So it's the, the, um, it's what we've all been saying for, you know, probably a decade now. Right. Which is that like developers need to be delivering valuable software, not building platforms. Right. So that's, that's the problem, essentially the problem that it solves, right. The platform instance that sits on top of the platform for building platforms. I guess. So from that perspective, if, um, the, I mean, the other interesting thing is, is how, as technology evolves, uh, everything that we used to manage again, as sort of like a pet, I hate this analogy. I hate the pet cattle analogy. Cause like, I just, you know, we should care about every, every cow in the herd as well. You know, it's just, there's, is there another, is there another analogy that could, that could replace that one?

Uh, I don't know. Maybe, maybe like, uh, bricks versus cakes. I'll have to think about that. Wow. I mean, if a, uh, you know, you got a bunch of bricks in your house and if one of them breaks, you just get a new one, you don't, and you don't name the brick. Whereas like a cake, you're like, if you're a handmade, if you're making a cake by, from scratch, there's a lot of effort put into this. And like, you know, if, if you only, if you, if you had one slice out of 10 left in the cake that you made by scratch, you'd probably be like, I'm not going to throw that away. That's my cake. It's hard to, it's hard to, you can't just replace this. Yeah. Okay. So, uh, bricks and cakes. So, so our, our, we're cakes and we've turned them into bricks with containers and so on. Um, uh, where was I going with this? So, uh, so, so, so our Kubernetes has been our latest, our latest cake. We take care of each Kubernetes cluster. Do you think, are we, does, does Tonsu, uh, and, uh, allow us to start to think about and treat Kubernetes clusters more like bricks? Uh, or, or, or cattle. Uh, I think, I think my substitution doesn't work. We should move on. Are we there? Are we, because we, we, we're managing, are we, are we there where we can manage fleets of Kubernetes and we can, are, you know, the way we think about a Kubernetes cluster becomes something itself more ephemeral, replaceable. Um, you know, we're not managing the cluster itself. I'll take that drop. So, uh, you know, when I was developing my demos and talks to my customer, when I was back there in Tanzu, I was giving one analogy to them that we had containers. We had Docker. When they scaled, when they became thousands of them, we needed something to manage those containers. And that's where we help platforms like Kubernetes, who is orchestrating these containers for us. Now, big organizations grew and they keep deploying Kubernetes and clusters. Now it's, we are again in the same phase where you need something to manage Kubernetes clusters.

And that's where we have time because it solves that problem of scale, not for containers, but for your Kubernetes clusters. And that, that's where your Kubernetes clusters become your bricks. No matter whether you build your building in one cloud platform or other cloud platform or your on-premises data center, it's, your cluster will be brick. And you can create as many number of bricks, put them wherever you want, build whatever type of buildings that you want using platform like Tanzu. I love that. So I want to, I just want to, I can't shut up this morning. I want to add just one more anecdote to that, right? So yeah, there, there are organizations out there that have rooms full of brickmakers as it were, right? They're very highly paid brickmakers, whereas, you know, they could just call up the brickyard and just get a truckload delivered. Right now, right? And so the anecdote, and I don't, I hope I'm not casting aspersions at anybody, but there was a, we were at KubeCon, I don't know, two, three, four years. And there was a financial institution that wanted to get into the Kubernetes distribution space. And so I'm not, I don't, I'm not, I'm not throwing shade at anybody. It was just an observation I had. It was a financial institution there in the, the business of moving dollars around. And they were paying a, you know, presumably a highly paid good sized team of engineers to come up with, uh, you know, Kubernetes distribution to kind of compete, compete in the Kubernetes distro horse race. And, uh, um, you know, the observation, we hope that a reader of this book would come to is that Kubernetes is a commodity, right? It's like bricks. It's not a cake. Sorry, Coté, that's living forever. All right. Well, that's fine. You know, I'm, I just, I just, in, in case it's terrible, I don't want to be associated with, but it looks like it's turning out well. So, uh, I'll, I'll, I'll go for it. Wait, you know, to, to attempt to jam two questions into one question here, uh, you know, going off what you were saying, you just added a writer to the first thing. Like, so like what we, we, we, we keep saying platform, but like, what is a platform as far as in the practical world, right?

Like never, nevermind what we think a platform would be. And, and I ask it this way because like, I, you know, I, I read a lot of tech news stuff and there's a lot of different people talking about platforms. And I always think like, I don't know if you were like, actually have encountered them. It's just like this theoretical thing. And so one, like, I'm curious, like what y'all think of as a platform, as far as what you're seeing people do. And then, and then the, the kind of, uh, you know, part of that question is like, is Kubernetes part of a platform or is it the thing underneath a platform? It's the latter. And you, you've actually brought up, uh, um, like an interesting distinction, right? Like even in the context of software, there, there are many different things that are platforms. So, uh, Tonsu in particular is enterprise production software platform, right? So I, um, I write a piece of software that takes a customer's information and generates a set of recommendations for what they might want to purchase. Right. So I've got this software, it's got an input and an output. So what a lot of people newer to software don't realize is when you're doing, uh, software in the real world, uh, you know, doing it as a profession, doing it at scale, doing it in a secure, responsible way. There are, um, uh, dozens and dozens of steps between that software leaving your desk, um, to, uh, to actually running in production. Right. So a big telecom we worked with, uh, before we came in, they, they, um, they actually went and tracked it down and it was, uh, seven months and 72 steps for a piece of software to get into production. Um, and so, uh, tons, it was a platform in the sense that it is the means by which your software goes from the developer's desktop to delivering value in production.

Um, and there are not, uh, uh, salaried human beings manually executing those 72 steps over the course of seven months. Right. So it is the set of building blocks that goes from A to B to C to Z to running in production, um, that, um, you know, takes humans and human effort out of the, um, out of the, uh, out of the, out of the picture. Right. So, um, I'm glad you brought up that distinction because sometimes when you think about a supply chain going beginning to end, you don't think of that as being a platform, but I think that's essentially what it is. It's all the tools that enable those various steps to get to production. Yeah. That's I've, I've, I, every now and then I've started to think of as well after, you know, reading your book, what you just said, like popped into my head that like, maybe the, the primary thing is the supply chain. Right. Like, and, and everything else is like, to, to say things are under it or over it is, is like too much of a, a, a layered approach to think of it, but it's like contributors. They're, they're, they're, they're components in that supply chain. Right. And, and so, so what, kind of, kind of what, what emerges from your book is that like, there's this supply chain. It's all the steps it takes from like, what are we used to say conception to code to running. There's no C for running. Uh, and, and so like all the activities, any, any sort of way that you automate or wrap things around that, or kind of like second or third things removed that need to happen to have that supply chain running. A lot of that is just like, that's your platform. It's almost like, I don't know why we don't like to use the word factory, but like factory is another good word for it. Right. Like, if you think that you're producing software, you need a factory that, that produces the software, which is why all of a sudden you care about like, you know, cooling circular saws. When what you're making is like Barbie dolls or something. There was, there's one quote in the book where you say, I bet this is really more, um, this is in the chapter about in particular Tonsu application platform.

Uh, but you mentioned that, which is, you know, one, one component, right. Um, of the Tonsu suite. But you say that if you think that, if you think of Tonsu application platform GUI, the UI as the eyes and ears of the platform, then the supply chain choreographer would be the beating heart. Yeah, that that's, that's exactly true. I'm glad you said it because I would probably would have reused those words because that's sort of my go to analogy. But yeah, I mean, that being said, we talked about things in the, the abstract, right. We should maybe talk about some of the things in that actually compose that factory. Right. And it's true. Um, TAP, Tonsu application platform is that beating heart, right? Like it's that it is assembly line going from one end of the factory to the other. That's taken the code and delivering software into production. Right. And you can think of the other pieces, right? So when it's running in production, maybe it needs to run on five different Kubernetes clusters across different cloud providers. Right. Then you've got something like Tonsu service mesh. Right. And then you need like a single place to look at all of your, your metrics across five clusters and all your different pieces of software. Right. And that is ARIA because that is just ARIA now. Sorry. They didn't rename it recently. Sorry to make sure I got the name right. And, um, you know, then you've got all of the, you know, the developer facing tools, the IDE plugins and the API game. Right. And then all the stuff that kind of gets you through the various phase of phases. Yeah. So, uh, yes, tap is the beating heart, but all of these other things are like stations in the factory that your product will pass through at some point of its life cycle. So, yeah, because it's, which is interesting because like when you think about the problems that Kubernetes has, uh, forces to deal with these problems of scale, uh, on the one hand, of course you do need, you need that beating heart, right? You need that thing that's going to move your apps into production securely. And, and, you know, and that, that's a conversation in and of itself. Once your apps are, are there, uh, of course you need all these sort of, uh, at scale eyes and ears on that end to, to make sure everything's working in the way that you expect.

But then there's on the other end, on the, on the developer end, you also need some sort of eyes and ears and portal to make this massive platform usable at a, at a developer or at a team experience. And it's interesting because like the, the, the problem is actually much broader, right. Then, then the problem of, of managing containers or, or clusters at scale. And it sort of like on this question of like, what is a platform? I think that, I think actually the, what is a platform is a moving target, right? It's the same thing as, as we solve one problem, we encounter another, we redefine what that platform is. And so I guess if you, if you include this, maybe focusing a little bit on the, on the developer side, the Tanzu application platform, GUI as the eyes and ears of the platform. How would you define, like, what, how do we think about a platform today? What are we trying to attain and how, and how is Tanzu answering that question for developers? I'll take a quick step of that, Kora. With one thing that I would like to say to the listener who are not very familiar, what Tanzu is, if you are getting that idea that it's just a pipeline tool. It's not the pipeline and the choreography is just one very small piece of the entire platform. It's just one assembly mechanism, what Rob has said, which is your application from your desk to the production thing. But think about how you build your product. Think about how you package them. Think about after deploying into production, how you link that application with other application. Think about how you will get on top of your entire ecosystem of your products, talking to each other and see if they misbehave, putting the guardrails for your products or applications that you deploy to make sure that they play within the established boundary. All these controls and operation mechanisms for your end-to-end of your application from an idea to a running software, that's the whole idea of Tanzu platform. And tap is one piece into it, which helps you move your build application from your desk to production.

Yep. So I like what Parth said. It's not just the assembly line, right? Like if you look at a factory, I was saying, first off, I love how we're describing everything through metaphor, right? So I'll keep going. You know, this is maybe not a Barbie doll factory, but maybe it's more like a Steinway factory, right? Like you have that assembly line, but not every Steinway piano is the same, like the one in Parth's living room there, right? That's a Steinway. But then there's like, you know, every shape and size. You kind of think of that as software, right? And so it is an assembly line, but, you know, it's not just stamping out carbon copies. That's where we add value as developers. But there's a lot more than that core assembly line, right? There are stations where people are doing quality control. There are stations where people are doing, you know, creating the components that feed into that assembly line, right? So, you know, tap maybe is the beating heart. Maybe the aorta or the left ventricle is something like build service, right? Like turning your compiled software artifact or your source code into a container image that can run safely in production is surprisingly difficult, right? Like you, it is very easy for people to poke holes in your container images and to do something that passes muster and checks all the boxes is really hard to do. So like one component in tap is build service, right? Based on KPAC, right? That, those kinds of decisions, right? Like, so now you have a team with five, 10, 100, 1,000 developers that don't have to think about turning software into a container image, right? So that's one component in the assembly line that's part of a wider factory, right? With all these other components. So yeah, that's a great distinction Parth makes, right? It's the whole factory. It's not just the, like the central assembly line. And also, like if being a listener, if you would be thinking that, hey, anybody can build this kind of a pipeline. Yes, you can. And anybody can build this kind of a platform also. The question here is, should you do that?

I mean, which business are you in? Whether are you in the business of building this platform? Or whether you are in the business of lending money or providing telephone lines or groceries or what, right? So you have to pick your core business and let this kind of complex engineering away so that you can fully utilize that and devote that time that you have to add more anxiety to your own applications that will bring more better user experience for your end user. And that's sort of the build versus buy conversation, right? It's like when does the economic shift? So you're saying we've shifted. We're not in the economic stage anymore where maybe it's economically advantageous to use your own resources to build your platform. As an industry, we've moved past that tilt point, I guess is what you're saying. Is that right? Yes, that's right. In history, people were a bit tempted to buy this kind of products because they were proprietary. They were like, once you buy that, like heavy, hefty licensees and all that were involved into running those kind of platforms. But what if these platforms are built with all open source tools and technologies underneath? I mean, then the worry of getting logged into a proprietary technology would be a bit reduced. I would not say it will completely get eliminated because vendor locking cannot be avoided in no matter what you do. It can only be reduced to a certain extent. And it can be reduced only when you use a tool and a platform that is built with all open source technology. Well, so there's, you know, we have talked broadly here, but that leaves the book as the fun place to go to find all the exact details and the components. And there are like, well, y'all probably have it memorized, but there's like, I don't know, six or seven different components or like parts kind of running around that you would go into.

But as kind of like the last, like the last question, at least that I have to go to go deeper than than kind of the broad stuff we've been at, like, you know, reading through your y'all's book, I had the same idea that I have all the time. I read about like builds that involve containers and developers, and it seems like it's a really bad idea to let developers build containers that you then deploy to production. Like, it seems like a lot of the work that is done in Tanzu, but then everyone does, is all about like, hey, let's not do that, right? Like, don't let that happen. But my perception is that's the way everyone does stuff. So, like, I don't know, I guess, like, is that a good idea to let developers be building the containers that get deployed to production? Or is it a bad idea? That's a great microcosm for the whole broad problem set, right? Let's talk about that one thing. So, there are two, I guess, kind of very common developer character flaws that actually play into this thing, right? So, we have the desire to be extremely clever and impress your friends, and then you have laziness, right? And so, step A is you employ unbelievable cleverness and abstraction on top of abstraction and reusability and come up with this amazing path to creating a container out of your code, right? And then you deliver that and you start using it, then you forget how it works. And everybody who interacts with it subsequently manifests the other character trait of laziness and doesn't go back in to see how this super clever way of building containers, you know, actually works. And the net result is you get stuff running in production that you don't intend to be there, right? And so, build service is creating containers, you know, designed and built by the adults in the room, right?

Like, people not trying to be too clever and people who are lazy and they're going to make sure that the right thing comes out the other end. Yeah, lazy or just using time wisely, because you can have a very hardworking person reinventing a wheel only to find out that, you know, they have to reinvent, they have to resolve all the problems that are already solved. By developers, I mean me. I don't mean in general. Developers are generally, just to add one thought on top of what Rob said is, that developers are generally like, they are responsible people, right? They don't do things lazily or I would say dropping the ball in terms of security and all, but unintentionally, there should be a mechanism, there should be a process in the organization to make sure that whatever they are building for their containers, putting inside their containers in terms of dependencies, the runtime version, the operating system and all, that is all in line with the organizational acceptance thing. And putting that guardrail and the process to review all those things is a very challenging task. Rather than that, what if we can have a mechanism where intentionally also somebody cannot put anything which is not approved inside the container? And that's where this concept of build service comes into picture, where it creates a framework where developers would not have to think about what will go inside my container image. So, the engine will itself identify what will your application need to run inside a container. And all that will go inside the container will come from all the approved libraries which your organization has checked and found usable in product dimensions. I want to make sure that anybody listening, if they're wondering, I guess, should I read this book? I figure maybe we'll give them a little bit of what they can expect to get out of it, right? So, I just have sort of the table of contents in front of me. So, I'll lay out that the book is talking about Tanzu, the suite, a whole set of products that VMware provides that are inspired by this problem of solving the problems that Kubernetes has sort of unveiled for us.

Of managing containers at scale, but then also managing clusters at scale, and then managing developers at scale in a way. So, enabling developers to be productive when the system behind them is running at this scale, but also there's such a high bar for security and for efficiency and all that stuff, right? So, Tanzu is sort of like an answer to that. It's not only the platform that sits on top of Kubernetes, but it sort of expands its reach into all of that single pane of glass that you need in order to really manage it properly. And also the developer portal that you need so that developers can have a good experience in collaborating with other teams and managing their APIs and all of that stuff, right? It sort of reaches both ends of that gamut. And so, if you're looking to read this book, two things I think that you get out of it are, one, obviously an understanding of how Tanzu in particular is going to solve these problems, but also just a really great, as you were saying, Rob, at the beginning, right? Like you're talking to 2015 Rob, what are these problems? Like, how do you think about this? And it is for security people and it is for developers and it is for, you know, architects and, I don't know, other roles, many different roles because it lays out the problems from end to end because it is this end to end solution. So, it really has a wide breadth. And so, while you will learn about how Tanzu and VMware solve these problems, you will also get a very clear, very insightful, and I have to say very fun, for me, I really enjoyed reading it, a fun explanation of what these problems are, why they matter. You'll maybe recognize them in your own life and be able to see how they can be solved. And you learn about a lot of open source software because, as you said, Parth, right, like there's a lot of open source software at the heart of these components, and it is an opinionated delivery, an integrated sort of integration of these. So, you'll also learn through those opinions, there is sort of like the view into what VMware considers to be the best practice to solving.

So, even if you don't use Tanzu, you've come to understand what VMware thinks are best practices for solving these problems. And so, I got a lot out of this book. Yeah, just because the breadth is amazing, and the way that you explain the problem set before you get to the solution is engaging and so clear. And so, yeah, just to make sure that people understand what they can get out of it. And I... One thing just... Congratulations. Yeah, Parth. Yeah, yeah, thank you. So, I just jumped in. One thing that I would like to say to our audience is that this book is not for you. If you think that this book will give you a production-grade deployment of the platform, it's not for you then. It gives you an idea of what Tanzu platform contains and gives you a way to have your hands dirty just to play around and experience the technology and do some high-level stuff like day one, day two activities with different tools. If you think that this book is a good thing, it's not for you. It's not for you to help you become production-ready. And for that, we have VMware documentation, which is your go-to place, and it is quite in-depth to give you the best practices in terms of how you should run them in production. So, I just wanted to call it out for the audience to set the invitation here. If your production system falls, you can't call Parth. You've got to still call VMware. That's right. Well, I appreciate you two being on. That's great. And the name of the book, again, is DevSecOps in Practice with VMware Tanzu by you two. I think, oh, look, there's even a three-dimensional version of it, which is always fun to have. Well, yeah, I mean, I agree with Cora. It was good to read over it. It'll make you interested and exciting about the portfolio. So, thanks. I appreciate you two being on. You got it. Enjoyed it. Thank you so much. Thank you. We really enjoyed this conversation.

Tanzu Talk · 🍕 Get more pizza.