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

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?

What is it? I know this is super hard to say, you know, like an elevator pitch, but if you can do it in a couple words. Briefly, Tanzu is like the name we apply to all the stuff, most all the stuff we have in VMware that helps out your application developer stack. So if you're an organization that writes and runs your own software, that's what the Tanzu suite handles. So there's your very small explanation now. I love it, I love it. So that is the question following, right? So the question is, why do we need Tanzu if there is Kubernetes, you know, like a pure one, like open source, like this native one, Vanilla. Tak, tak, tak, więc Kubernetes jest tylko jedną częścią całego stacku, prawda? Więc patrząc na Kubernetes samemu, powiem tylko generalnie o tym, prawda?

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.

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.

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.

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.

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

It's very business talk to match that desire that we have. And so, yeah, I mean, I think. And that gets back to kind of like the other reason why it takes a long time. And a lot of what I study is that like Not only does taking a year to get a lot less done than you think you should, and also trying to standardize and remove as much variation as possible, but the other thing why it's important to be up for learning and experimenting with what's going on is that, kind of as I alluded to, also you're going to be refactoring is a fun word to use, but you're going to be reprogramming and rewriting the organization itself. Hopefully, right? Hopefully, exactly. Right. And that's also why, you know, from kind of like, I don't know how you want to think about it, but kind of the enterprise architect to the low level executive to the high level executive, like they need to think about their role as being programmers of the organization, right?

So in the same way that a good programmer will kind of come up with a theory, write software to test that theory, observe if it solves a user's problem and go, you know, go through that cycle. Like executives, and I use that term very loosely, right? The people who are the programmers of the organization, they need to go through that same loop, because just as with the platform, as you were rightly pointing out earlier, right? When it comes to people and processes, there's a very, very well proven out documented ecosystem and understanding of how you do it. But I'm sure you encounter this like, It's the same as introducing technologies into an organization. People need to and like to customize it to their organization, right? So, you know, whether you're taking, you know, the Scrum book, whether you are having to do SAFe or you like the team topology stuff, or like you eagerly read the two DevOps reports each year and, you know, you've bought the Accelerate book and given it to everyone with a signed copy of the Phoenix project and the sequel novels.

Like what you'll find is that within your organization, You need to customize those technologies, those thought technologies to steal a phrase. And that's where the executive role becomes very important because their job is now to do that, right? That is their product to start thinking about. You know, I'm thinking like When you're entering to this world of new platforms, let's say a new containerization platform that you go beyond your VM deployments, right? And you start to use the modern apps platforms. Wherever it is, in your, let's say, data center or in the cloud, you need to, as an organization, or you should, start to think about the user as not only the end user, right?

And the first sort of technology, like mind technology that's required is to instead of, in a classic way of IT, You think about providing services, right? Like you are shipping an image or a container or you're setting up a service for someone to use. But instead it's good to think about I am shipping a product to a customer. And the way that's important is, the distinction makes it important is that when you start thinking about developers as your customers, instead of just sort of like guaranteeing that your service is good and you provided them what you want, what they need, Instead, you start thinking about how can I solve more problems for the customers, right? Like how can I make their experience better?

So what this means is that once you've solved the infrastructure problem, you start looking at all the things end to end that developers do to get the software out the door. They don't really get it out of door anymore, but you know, to get it into production. Names mentioned in English. Names mentioned in English. There's probably a lot of local optimization and the developers can probably do everything on their laptop more or less. But then once you hand it off to the rest of the process, it probably takes a long time, right?

So, you know, that's an example of like the infrastructure people can start like thinking about, well, how would I fix that? And on and on and on, right? Like you kind of keep finding things iteratively that to make your product, the infrastructure you're providing better. And yeah, I mean, I think Myślę, że też pytasz o to, jak rozwijać to przez resztę organizacji, aby ludzie byli świadomi i myśleli o tym. Mam na myśli dwie rzeczy. I to wraca do marketingu, o którym mówiłem. Kolejną powodą, dlaczego jest beneficjentem zacząć mało, z tylko jednogłośnymi zespołami, jest to, że bardzo prywatnie, na początku, i znowu, myślę, że to jest rolę, którą przewodnicy muszą wziąć, jest to, że budujesz,

Yeah, no, I like the way you're putting that, right? To make a distinction between a user and an end user, right? And then also, you know, I think An important phrase you said there is that they are equally important, right? Because I think to agree with you by like explaining it, you know, adding on some explanation, right? Like I think it's kind of like attractive to no matter where you are in the stack to talk about, you know, I am doing this work for the end user customer, right? Like, you know, there's the The anecdotal thing that like when I forget who it was, but when some US president asked a janitor at NASA like what their job was, it was like to get, you know, to get to the moon, which is like, yes, that is your job, right?

Right, right. But then, you know, the more detailed answer is exactly what you're saying is like, and to do that, there are multiple layers of end users that I go through, right? Like, so I have end users here. Names mentioned. Episode. First customer are these developers, right? And they hope indirectly to affect like the actual customer of the business or the citizen working with the agency or whatever.

We don't see much that of movement, more or less seeing like, okay, this is the platform, let's use it. Yeah. And this is kind of, you know, like, I wanna use it. Nobody asked me that I like it, right? Yeah, yeah. No, I think, I think, you know, the, the phrase developer relations or DevRel, like I, I see that used more and more inside organizations who are solving exactly the problem that you're going over, right? Which is, um, like this, this is another area where, W 2015-2017 roku zauważyliśmy, że tzw. aplikacyjny serwis Tanzu, Cloud Foundry, stało się, że tak jak wspomniałeś, ludzie przystąpili i wysyłali e-mail do wszystkich deweloperów, a wtedy byli zaskoczeni, że nikt go nie użył.

I mean, this is what my team does. The team that I'm on does. Just raise awareness and Interest in usage and kind of explain not only the technology itself, but we talked a lot about this, like the thought technology that goes around it, right? If you'll pardon the phrase, the thought leadership, right? Like that's what this person needs to do. And I started seeing this role, I don't know, maybe four or so years ago, like at various organizations, even longer. The first time I encountered it was at this American insurance company called Allstate. And then at another, this is back when I still lived in the States, at an energy company and on and on and on.

And now, most recently, I gave a talk with some people from Mercedes-Benz about the platform that they run internally and they have this role as well. And you can see this at JP Morgan Chase and all sorts of places. I I'll use I'll use the the the JP Morgan Chase example. They have a team now of about I think it's like seven to ten people. I forget the exact count that operate globally and they do exactly this role. Right. And so that role becomes very important one to raise awareness of what you're saying. And then just to add on and I'll stop talking here like the other thing going back to Product managing the platform is because this role is talking with the developers in your organizations all the time.

They also are a great source of feedback and input about what the platform should do and how it can make things better. I think this is the first change, right? You want to go for modern apps in your organization because you're feeling that push from the ecosystem of your partners, competitors, wherever. And the first thing that you change is that there is a dev role. It can happen on the level of the CEO that the guy is just pushed to be Names mentioned.