#25 Why VMware Tanzu if there are soooo many open source choices?

So basically, Michael, what you do in this lovely containers world in VMware company? What is your role? So I work on the developer relations team, but as I like to, maybe this joke is getting a little tired, but like I neither talk with developers nor relate with them. And instead what I do is I talk more with, I guess you could say, I don't know if so much enterprise architects but managers and executives like people who are like programming and architecting their organization. So most of what I spend my time like on like researching and talking with people about and then like you know making all sorts of content for publishing let's call it is basically like if you want your organization to get better at doing software

What does that mean organization wise? As far as what the organization looks like, the processes that you follow, the kind of roles and responsibilities. I don't know all that kind of stuff. Sometimes people call this like culture, but like I'm always a little like dodgy on that term. Well, I mean, I'm not. It's fine, but it's just like, you know, it begs the question, what is culture? But yeah, I mean, if you read all the DevOps reports stuff and whatever from the last ten years, I guess you could say that culture stuff that I spent time on. All right. So when you think about this developer relationship, right? Because developer relationships, like you said, they can be on the different levels, right? So you can have developer relation with the real developer teams, architects, so on, but sometimes also enterprise architect.

Do you think that the culture of this Names mentioned. Names mentioned. The larger the organization, I find the more effective tops down can be. The more needed that it is. Now if you have a small organization, I mean let's just say one, I don't know, I'm making this up, one to three teams, then you can have change from all directions.

You're a pretty small organization. On the extreme end, like I often cite like, if you think about like JP Morgan Chase, they have, I don't know, last time I looked like 25,000 developers globally. And so like, you know, you're not going to get a hundred developers to agree what to do, let alone like 25,000. And however, right? Like, so you don't want to be all dismissive of bottoms up stuff. Cause like a lot of the time, well, I would say all of the time when you're changing an organization, you're asking all those individuals to change, right? So they need to be willing and be interested in it. And also like you need them to figure out what to do day to day. So they have to be behind it and that has to be effective.

Now, the reason why I like to emphasize that tops down is also important is like Sooner or later you're going to need to change what the organization looks like. The incentives and the career paths that people have. Those 25,000 developers aren't going to want to go sit down for the annual budgeting and finance meeting. The tool takes ages, right? There's all sorts of things that in a cynical position you don't think about these things, but there's just like A lot of stuff the executives and managers do as their job, right? And like, they need to do them in order for it to be effective. I love that you used 25,000, you know, because this is the 25th episode, so it's a perfect fit, right?

Exactly. Yeah, 25th episode of evoilcast. Well, hopefully you'll get to 25,000 episodes. That would be amazing. Hopefully, you know, but I will, you know, my beard will grow a little bigger, I think. So today, with us, Michael Kotę, my name is Maciek Lelusz. I'm running the podcast over last years and we talk generally about case studies here. So we think about technology and how to use this technology in your infrastructure, in your organization. Depends, you know, on what level it's something important to be changed, right, by this technology. Names mentioned because the VMware is in the air, right? So what is Tanzu? Could you could you say to our listeners a little bit, just a brief explanation?

Rzecz, dlaczego potrzebujesz dystro Kubernetes, chociaż to nie jest naprawdę terminologia, którą ludzie używają, ale czy potrzebujesz dystro, aby je uruchomić samemu, czy chcesz je uruchomić w publicznym cloudzie, ktoś to uruchomi dla Ciebie, jest, mówię, to te same powody, dlaczego chcesz, tak, dystro Linux. Or whatever. It's just like you could like build and run and configure and kind of learn how to do all the stuff on your own. And some people do. Like I think, you know, I'm not really sure, but if you're not really supposed to cite people who aren't your customers when you're a vendor, but like the Chick-fil-A people in the States, they're a fried chicken restaurant. They gave a recent overview of how they do Kubernetes stuff. They might like license it from someone. But, you know, in reading through what they do and if you look at like what our customers do, like they got other stuff to do.

Take care of Kubernetes. I'm no longer astonished, but over the past five years, you know, I have another podcast that I do, Software Defined Talk, and we cover Kubernetes here to here, week to week. And there's an ongoing joke that like, you know, not each week, but we would often discover that there was something that Kubernetes didn't do that I assumed it did, right? Because if you kind of read about how great Kubernetes is, it seems to basically be like Names mentioned.

Names mentioned in English. Kubernetes is to personified responsibility to do like extensive monitoring and management, right? So we have things like Tanzu Mission Control and other things that you can use to monitor and manage it or provide all of the the catalog of services and things that developers and other people would want to use, right? So we have a catalog that does that and you know there's all and then you know the way that you enforce security and governance and then one thing that's like hard to capture is like

Let's call it like the way of using it. So like, you know, the way you configure things, the way you govern it, like all these sorts of things is also not like, you know, it's something that you bring to what Kubernetes does. So once you start to think about, and again, you know, just think analogously to any platform you would use to run an application, right? Like it's a whole bunch of stuff. And so one, you need all those extra things. And then two, The other parts of Tanzu have a lot more to do with application development

What developers do in organizations, all the frameworks that they use, the tools that they have, all of those sorts of things. And that's why I say it's like our application stack stuff, right? Like Tanzu isn't like just one thing that you install. It's just the name of our collection of, again, if you're doing custom software, you're writing it and running it, it's Tanzu stuff in VMware land. Dajmy to tak. Mówimy o Tanzu jako platformie, prawda? Jest to taki zestaw narzędzi, ale skutecznie wybrany przez sprzedawcę, aby wspierać generalnie modernizację aplikacji. I wiele klientów, kiedy rozmawiamy z nimi przez lata, ostatnie lata, może nie tysiące lat, ale ostatnie lata,

When you get to that 25,000th episode. Yeah, maybe then I will say like over those years, right? So those guys, they always thinking like this. Initially, we have small setup, right? So we can start pure with the toolset, know the toolset and then with some experience, knowledge, we can choose a proper platform to us. Would you recommend that approach if it's a right approach or they should do something Oh, you mean like choosing a platform when you're starting off? From the very beginning, right? Yeah. Or just take a vanilla tools and learn them hard, you know, like real hard. Yeah, yeah. I mean, I think that it is probably, despite how much I might be an advocate for like, you know, the stereotype of Agile of just like, go do stuff, which whatever, you know, some Agile people might say that's a mischaracterization, but whatever, it being a stereotype, like, yeah,

I think it's worth spending, at minimum, a couple of days, if not longer, depending on the size of your organization, thinking about, like, your platform choices, right? And there's two reasons. One, like, if you're, like, at a small organization, like, you know, you have, again, a team or so, then, I mean, even in that case, like, you need to think about, like, so let's say we're successful in 3 months, 6 months, 12, and then 24 months, right? What are things we're going to need at that point? And what do we need at all those phases? And let's see if whatever platform we... Why don't we kind of like plan for that happening? Because retrofitting stuff at the platform layer is difficult and painful, right?

And that's kind of like a minimum of why it's important to think about the platform that you have. Now, on the extreme end, back to, you know, your 10,000, 25,000 person company, right? Like, I think You have to think about your platform stuff a lot before you go into it because you're not primary, but a huge amount of the problems that you're going to have are going to be due to standardizing on the platform that you use across all those developers and removing as much variation and Posibility for variation as you can. If you imagine, let's say, you have 10,000 developers that are supporting, I don't even know how many applications and services that would be. It's got to be a couple thousand, and those are big teams.

If you imagine governing the long term coolness, I was going to say agility, but just like, Names mentioned in English. Right? Just you need to think how to operate it the day to all of what you said. But as well, we see that if we introduce the platform, that is fairly complicated stack, right? Because, you know, when you look at the standard customer, you have this physical layer, underlay, overlay, plus on top of that virtualization in VMs, you have Kubernetes in any form, right?

On top of it you have service mesh. So it's fairly complicated stuff. I think that it's super important when we introduce to the organization that kind of toolset, wherever is a platform, if it's Tanzu platform, it's fine, wherever other platforms, any platforms we choose, there is a need to introduce this platform to the teams, because it's like giving them, you know, let's say Concorde plane, right? And the guy is just flying normally with Cessna, right? Super simple. And suddenly they get a Concorde, right? And they think, oh my god, it's using so much fuel, you know, and I'm flying only to the 7-Eleven to buy a bag of chips, right? Sure. One thing is the introduction of the platform, but second thing, in my opinion, is to present this platform to the people that they will use it and maybe not the force is not the best word, but encourage them, right?

Yeah, sure, sure. Encourage them a little bit to use it and try and teach them to understand that. So when you, in your journey, when you introduce those big, those platforms to those big teams, how much time it's taking from, let's say, presenting the tool, aligning with the tech teams or backend tech teams to fully use it by organization? It's a long process or a short process? Yeah, so I think, you know, what you're pointing out is this is an area that, like, Names mentioned.

Names mentioned. In order to be successful with the platform, kind of like I was talking about earlier with the bottoms up thing, like you need people to be enthusiastic about using it, otherwise they'll do a bad job. Or not even a bad job, they just won't excel. So anyways, what I found like, you know, for, I need to go look, but I think it's about seven or eight years now that I've been kind of in this role doing this stuff, first at Pivotal and now at VMware, but kind of studying how people Names mentioned.

Names mentioned. Names mentioned. I don't know 8 or 10 teams including those original ones like so cumulatively that are doing this and then after about a year I think it's reasonable that you might get to like 15 or 20 maybe more depending on like how well things go but you know again in relation to like a ten thousand twenty five thousand person organization this can seem really slow right but it's you know it's it's validating what you were saying is

Well, yeah, it's hard. Right? And it's complicated. And I think long term, what I've noticed is that one of the more important things is to manage failure. Right? So like, in contrast to taking a slow time, if you just sort of like, you know, Names mentioned. Names mentioned in English.

You start with one team with this complicated stack and you then you go to two teams and three teams right and what you're doing is you're learning what that stack is not only how to use the stack but what the good stack is for you right and if you're conscious of and humble is the wrong word because it's the right way to go about doing things if you are Names mentioned.

When you think about ready to use platforms instead of vanilla solutions put it together. So the learning curve for sure is easier for platforms, right? But is it deeper if it's The less you want to or need to customize the stack to how your organization works,

Just to choose one that seems to come up all the time, everyone has their own exciting way to do certificate management. Key management. Secrets. If you're running our stuff, you can run our stuff on public or private cloud or whatever. Depending on what you want to do and how much you want to customize it, that's another thing that has customization. Depending on how you want to do your build pipelines and the way you want to add security in there. All of these things You can start with great templates and defaults that are again supported by like an ecosystem around there. But as you start to customize things more and more, that's where you introduce like, I don't know, more time to get to what you wanted.

Sorry, just a little bit here to add. So when you think about it, sometimes it's easier to change your organization. To jest interesujący punkt, który zawsze się zastanawiam. I jak ekscytujące jest to, że siedzę i zastanawiam się o tych rzeczach. Kiedy byłem młodym programerem, nauczyłeś się, że nie pozwalasz, aby narzędzia cię zmieniali. Like you know you fit the tools to the job but like as I've gotten older and talk with more and more people I sort of I kind of agree with you more is that you you figure out what tools you're gonna use and you almost fit the organization to what the tools make possible right and you know there's another angle that's kind of a kind of has come up uh my I used to work at RedMonk as an analyst there and one of the analysts there Stephen O'Grady like wrote this up recently that there's this phrase that

Organizacje, organizacje rozwojowe często skupiają się na ich organizacji, prawda, co jest, wiesz, różnicą z prawem Conwaya, która jest w zasadzie, że architekta Twojej aplikacji porównuje się z komunikacjami komunikacyjnymi w Twojej organizacji lub Twojej strukturze organizacyjnej, żeby to zrównoważyć, prawda, i więc myślę, że są te dwie różnicy, które, nie różnic, ale te rzeczy, o których trzeba być świadomi, jest to, że Twoja organizacja będzie musiała zmienić się w zależności od narzędzi, które używasz, Because the tools tend to be built to benefit certain organization structures and not benefit others. But then also you need to think about what is the software that we're shipping and how do we need to change the organization to match that outcome, right? And sorry, I used the word outcome there.