Everything I know about platform operations, platform as a product

Episode 183 · 42:11 · SRT · archive.org · all Tanzu Talk

Well, hey, everybody. This is another selection from my week daily Tanzu talks. You know, if you want to check them out, every day I come up with some topic to talk about. There's been a lot of interesting things, if I don't say so myself, about the process of doing meetings better. And also a bunch of advice if you're looking to learn more about Kubernetes and you're more of a traditional VI administrator or whatever. And I don't know, other stuff. But this is one where I kind of did a brain dump on platform operations, which I thought was worth including in here. So if you want to check out the actual video of this and all the other ones, if you go to Coté.io slash Tanzu talk, you can see an archive of all the videos and show notes. And in general, you can go to Tanzu.tv as well and see all the videos, the streams that we do. I generally broadcast every weekday around 11, 1130 a.m. Amsterdam time. So you should check those out as well. There's a whole lot of good stuff over there. And with that, enjoy the episode. And what I wanted to go over today is, you know, a bit of a brain dump about a topic called platform operations or as we fancy calling it platform as a product. I mean, this topic can also just be like, it more often comes up in how do I run my DevOps teams or how do I run Kubernetes stuff? It's like the people in charge of infrastructure and operations and stuff like that that are like running your infrastructure, maybe even running your platform as a service. Now, this idea has evolved a lot over time. You know, I just yesterday had a part two of a discussion with with Bosky and there's another one. And I think, you know, it traditionally in this majority of what still happens is you have people basically running your vSphere, your VMware estate, and you run all your stuff there. And as she was talking about, you know, they do a lot of capacity management, a lot of kind of setting up of VMs. And to a certain extent, it sounds like helping people out with

those VMs. But developers, the people writing and running the custom software in large organizations are just sort of left up to do whatever, right? They can specify things differently. Now, I hadn't actually thought about this kind of introduction of why this topic comes up. So this is fun to kind of run through it. But I think the reason this new idea comes up of platform, you know, operations, and what does it mean to run this is the nature of what you do when you're operating, when you're running this infrastructure, this centralized platform for a large organization. It, you know, I don't really think it changes. I think there are new responsibilities that you have. And that new responsibility is basically thinking a lot more about what's running in your VMs and your containers and how they coordinate with each other. You're taking a much more active role in what we used to call the enterprise architecture and defining what the architecture of these applications are. And the reason that you do this, there's two main reasons that I can think of at the moment. The first one is that it's really inefficient to not centralize and standardize it. Now, you know, any centralized piece of IT or ideas eventually gets neglected so much that it doesn't evolve. And it becomes not only a huge piece of technical debt, but a huge calcified concrete thing that's weighing you down. And you saw this with enterprise service buses, with Java application servers. You can also see it with lamp stacks and old versions of, you know, open source stuff that you just never upgrade. And SOA stuff, all of these ways of centralizing and standardizing the way that applications are architected, designed, the way they're run. They were all great at the time. And I don't know, people just neglect them. And then they become crap. I don't know what else to tell you.

That's the way it goes. So we're constantly coming in every five or 10 years and kind of renewing what those things are, because we've decided we don't want to pay attention to them anymore or evolve them. There's all sorts of reasons, whatever. So because we have something, you know, let's call it cloud native or Kubernetes, and then the platform as a service built on top of that, there's a whole new way of doing applications that let's just say, is good and desirable, right? Like, and so this means there's a new way that operations people need to think and, and run through things. So I want to go over just kind of like I was saying, a brain dump of everything I know, at the moment, I should say no, and can remember, or find in my notes, about platform operation stuff about what there's a new way of being assist admin, whatever you want to call it is. So let's switch over to looking at my notes. So you know, if you really want to see macro stuff, if you're you can see how this could be like a presentation, but you know, there's some great Gartner survey stuff that's basically like, this is a good idea. It people that we surveyed who are running things in a platform structured way, they see that things are going better. And I think as always, you know, paying attention to satisfaction, right? And I'm pretty sure what they mean by this, I'd have to go look it up as developers, not, you know, people like you and me who are operating with businesses. Although maybe it does go that far, that's, that'd be great. But essentially, they find success with doing things in this way. And one of the key things that Gartner and we as well, right, like, this is kind of my, my not quite a vendor pitch, sort of way of going over things, you know, people always want me not to give a vendor pitch. So, you know, I'll add before I get into this that I've kind of, uh, pulled a lot from a couple of Gartner reports and other things, but, uh, we in, in the pivotal labs world, which is a part of, uh, VMware Tanzu, uh, we find all the

same stuff and we've been doing this kind of, uh, platform operation stuff for a long time, at least five years, if not more. And we have a great business to give you a little CTA, uh, in actually not only helping people become aware of and train and stand up their platforms, the VMware Tanzu stack of stuff, you know, what you would expect from a professional services organization, where you buy some big chunk of software and you pay some extra to have someone help you install it. But we actually pair up with people who are doing, doing, uh, platform operations to, uh, train them up on it, to kind of figure out the, um, we don't call it a run book, but kind of figure out the book of practices and things that they'll do and, uh, start to do some of the initial projects with developers. You should totally look into that. Uh, you can email me at Codem. I'm not sure who this Codem character is, but Codem, C-O-T-E-M at VMware.com or, you know, otherwise try to contact us and, uh, we can go over that in some more depth, but pretty much all of this matches, uh, all of the stuff. Well, all of it matches what we do. Otherwise, as someone who works at a vendor and never gives a vendor pitch, I would not be vendoring it to you. Um, so let's, uh, let's go over what generally occurs. So the idea of a, of a platform, uh, operations team is that you're centralizing this, this platform that you're running. Now, what do I mean by platform? It could be you're running Kubernetes and having multiple clusters that developers can package up and run their things on. It could be like you're using a platform as a service, like the VMware Tanzu, uh, application service, you know, cloud foundry. Uh, and so you're, you're, um, again, you're, you're giving all the development teams, this standard centralized way of doing things. It could be that you're, uh, you might even be building your own stuff, uh, whether it's on public clouds or your own infrastructure, but the goal remains the same in all of these cases. And that is to remove as much

variability as possible, right? To standardize on how the infrastructure is, uh, sort of allocated out to people, how your development teams use that infrastructure, how they make that infrastructure ready to be in production. Um, how they standardize on the types of frameworks and services they use, all of this type of stuff where you're trying to centralize, uh, the it that you're using, uh, just as you would expect. Right. And I think, I think a major difference again, why things are different because in the traditional more VM led world, you really don't spend too much time kind of like as an infrastructure person, again, as an operations person, your responsibility kind of stops at the VM level, right? Like you're not really dictating a lot of how the applications are architected or built, right? You're not being involved in as we'll get into kind of like the build process or the middleware, the framework, right? You're not really a provider. You're not a, a vendor to developers of the stack that they need. You're more just kind of like arranging and giving them infrastructure and you don't really care, uh, what happens with it. And so it really comes from that, you know, these major differences that I think drive this need to have a platform team. So the, the, the, the key sort of consequence of that, if you think about it, one, you need to centralize as much as possible. This is sometimes a bad idea for developers, but like, again, the more variability you allow, the more ways you allow people to package up and run and architect their applications in Kubernetes or in, you know, a platform as a service, uh, like the Tanzu application service or whatever, the more stuff you're going to have to manage, the more you open things up for errors and doing things kind of wrong, the more knowledge you need to, to garden and persist and keep to keep your platform, all your stuff from atrophying, right? Like variability, not cool. Like that's, that's what causes a lot of problems. Um, so looking inward, right at the, at the, the platform team, first of all, uh, getting to the

point where you have this strategy, like, I mean, this is what, uh, what Gartner recommends. And it's kind of what I've seen in our practices over the years is like when you have like three or four teams, that's when you really need to centralize a platform, right? In contrast, you can take the kind of full stack approach where each team, each software team is essentially building their own, um, layer between raw infrastructure, between compute network and storage, and they're running applications, the way that things are packaged, managed the way that they're made ready to monitor and production. They're kind of determining what that framework is. And they're kind of one-offing a lot of that. And, you know, doing that for one or two teams is probably okay. But once you hit three or four teams, once you've got this momentum and you're going beyond that, you're going to have lots of problems. Again, you're going to introduce variability and, uh, that's always an issue, right? There's no way around that. So once you hit that three or four team thing, or if you want to be proactive and anticipate it, you really need to build a centralized platform team, right? So this team, what is it that they're going to own, right? So obviously they're going to own whatever that upper interface is, the development teams, right? And that might mean just Kubernetes, right? So you might be giving your developers just direct access to Kubernetes to deploy their applications, or it might mean a, uh, you know, again, uh, the platform, uh, the paths that you're using, but you're going to own running that specifying that, uh, and evolving that you're going to own it as a product. Hence that phrase we use, uh, platform as a product. And so that team, uh, needs to be the one in charge of that. Now, what this also implies, and if you'll remember, I think it was, um, I think it was Bosky yesterday. I was talking about this with, or maybe someone else, I forget. Um, but looking downward, that team also needs to own as much of the, the, the stack downward as possible, right? So essentially that means three areas, right? They compute your servers, uh, networking,

uh, and storage. And anytime that they have to talk to someone else, another team that is managing, uh, those three, you know, one or three, one of those three things on their own, you're going to introduce immediately a constraint, a bottleneck, right? They're going to have a block. They're going to have to wait on that team anytime that they need to add capacity, that they need to change the way that networking works, you know, that they need to do anything. They're going to have to have a meeting with that team, prove that that those teams should do anything that this wacky new way of doing stuff should be allowed. Um, and it's just going to slow things down, right? And the point of all of this is to not slow things down. So initially this team is going to have to spend a lot of time with these external parties, or if you're lucky, you can collapse the management of those things into this, this team as well. And this team might be the amount of people that it is. I don't know. You'll have to figure that out. It could, it could be a handful of people. It could be a lot of people. There could be a lot of sub teams, but you know, the, the area of responsibility, you want to own as much of that stack, uh, as possible. Um, otherwise again, you're, you're going to introduce, uh, just friction into the system, which, which doesn't really make sense, right? Like if the point of what you're doing is to remove friction from the system, you don't want to introduce friction into the system or, uh, keep it there. So, um, let, let, now let me talk about the, the kind of mindset and the orientation, which I mentioned briefly, but kind of, uh, uh, specify that out a little bit more and kind of go over some, some ideas of what it means. So as I was saying, so the major shift, um, I think that I see these teams taking is again, you know, I mean, again, from my canon of spieling what we're doing here, the whole concern of digital transformation of Kubernetes of cloud native

development for us is that we want to evolve the business rapidly. We want to add new features, experiment with things on a weekly basis, if not daily. This means we need to speed up our ability to get new features out the door, which means we need to, um, really think about the role of software development and product management of software, uh, in the organization and enable that as much as possible, uh, and enable as much as possible. And I mean, that's what we're constantly paying attention to. So from an infrastructure standpoint, from an operation standpoint, that means we automate as many things as possible. So we don't have to worry about tedious things, uh, that like, don't really have direct customer value that are just kind of like, I don't know, standard tedious junk. But it also means that as operations people, our customers become those developers. We, as the operations people are trying to help our customers, the developers do things as best as possible. Now that doesn't mean doing everything they want at all, it doesn't mean that, but what it means is analyzing what problems they have, what jobs to be done. If you want to use that terminology, they have what features are needed and providing that to them in the, in the platform and the infrastructure that you're doing. This means your product managing, uh, that, right? Like you're constantly studying, uh, what is it that developers need? Let's theorize a way that we could give that to them. Let's give, let's figure out kind of like a minimal viable product, a minimal viable way to gather experimentation and validate or invalidate those theories. And then keep going on this, this cycle of really product managing what you're giving them. Now, obviously there's going to be a whole lot of stuff that you don't have to product manage that you will just know that they need, uh, and you can start to set up. There will also be things taking kind of an SRE standpoint that you want developers, you will sort of negotiate with them, excuse me, that they, they will need to do right. Like even if a developer is not asking for it,

when this application is running in production, you will need to be able to, uh, let me adjust my camera. You really got to be able to see the top of my head. I mean, don't you think, um, you know, it needs to be manageable. You need to be able to monitor it. You need to be able to restart it if needed, which is something nice that Kubernetes and a lot of higher level platforms like the Tanzu application service do for you. You need to be able to do rollbacks. There's all these things that you as an operations person probably intuitively know are going to be required that a developer may not exactly be thinking of, but you build up this list of features, right? And the important part is you're constantly going through and improving it by taking a real product management, look at it. Now let me scroll down to where is it? Uh, right. There's two like, like Gartner lists that I wanted to go, but you know, as help, and this is, uh, let me see which one there's two Gartner papers that are pretty good. Uh, as far as kind of going over a lot of this stuff and even giving you some stuff to start with. And this one is from the, uh, ah, the lengthier one, the, uh, they don't call himself Burton group anymore, but this is the part of Gartner that puts out like 50, 80 page PDFs that are a lot more prescriptive than the market analysis, but there's a good list of things to kind of kick off. Uh, what, uh, when you're putting kicking off and ongoing your platform team, like things you probably will want to pay attention to things that people, uh, that you'll put in that developers will need and that you'll need, right? Like, as I was saying, you know, you're going to need some monitoring, uh, you know, this is, this is an example of toil, right? So like, what are, what are different things that people do over and over again, uh, that you can automate for them? Let me, let me space this out a little bit. Yeah. Yeah. And, uh, I don't know, there's, there's all sorts of things here, right? Like, uh, something that's kind of missing from here that I would also think about in a, um, in a cloud native, right? Like in a Kubernetes, uh, or platform as a service

kind of world is like, what service mesh are you going to provide for people? And by service mesh, what I mean is a standardized way of having all the different, not only the components of one piece of software, one app talk with each other, because all apps nowadays are basically distributed applications where you carve off sub components of the application to run on more, I'm simplifying it to run on different IP addressable things, different servers or in different containers. And you're really a developer doing the style of applications is really kind of orchestrating a bunch of these services together. And then there's also all the types of middleware, uh, that you want to provide, whether it's databases or message queues. And then of course, you know, you're going to have all your security and compliance and governance things. So orient yourself around that, right? Like, I mean, if you've never really spent time understanding what product management is, or, you know, if you don't know, if you've never encountered the phrase lean product management or the product pragmatic product manager, I mean, that's a, that's a really old one, but like get familiar with, uh, what the deal with product management is. And there's, there's actually a book I should reference here. That's a really good book. I read a couple of years ago that, that, uh, let me, let me put it to do thing here to, uh, insert that in. Cause it is, it's a good overview, but figure out product management. Cause this is, this is going to be a key to doing things better, right? You have to shift your mind from doing service delivery. We've been told we need to deliver this set of capabilities, this set of services, right? We needed to deliver VMs. We needed to deliver a load balancer, right? We have to deliver these things. And instead of just, you know, it evolves, but generally you deliver a service and you just incrementally evolve it as needed. You don't actually revisit it and constantly study. Do the developers needs for this service. Have they changed, right? Like, do we need to add

new functionality, take away old functionality, right? Like think about what you're doing as constantly providing new features to developers instead of services, right? And how do you evolve and study what those features are? And that's a huge part of what's different from a product management mentality to a service delivery mentality. And to that end, right? Like another thing that's worth thinking about is that you're making a long-term commitment, right? So sometimes when people set up a chunk of infrastructure, they're thinking is that we'll have this initial, maybe even like an advanced POC proof of concept. And we're just kind of going to like set it in motion. And then we'll have some, as traditionally, you know, a lot of the jobs that some ops people do, that was a lot of that some, but a lot of operations work is basically just keeping things up and running, right? Meeting the SLA that it has uptime and availability rather than like, let's call it an SLU, service level of usefulness, right? And so what this means is that you don't want to just build this infrastructure and keep it up and running. You're going to be spending a time, especially initially, I would say the first three months, maybe even six months getting it wrong a lot, right? Like a constant theme with me, getting good at messing up. And what you want to do, what you're doing here is this is the essence of product management is you're coming up with a theory of how to solve a developer's problem. You know, you can think of observability as that, right? Like the problem we might have is that things are always going wrong in production and it takes us a long time to recover from that. And it takes us even longer to figure out like, what's going wrong so that we can fix it. So you have an observability problem, at least in that second case. So you might come up with several ways, not only technologies to instrument and make observable that you might bundle in there, but also, and this is another key shift is you as a platform team are going to have to come up with practices and mindsets, even culture that people follow, right? So if an

issue that you have is that developers are constantly putting stuff into production and something goes wrong and you can't diagnose it and fix it, it takes a long time, then there's some kind of process problem the developers have. Like they're not writing their code to be observable or diagnosable, knowable, if you will. I'm disclaiming too much. I just don't want to get the observable observability monks all up in a tizzy because I'm not being precise enough in my definition. Essentially there's problems in production and the developers aren't really helping the situation out, right? So you're going to have to think about what kind of process, what kind of mindset shift can I as the platform team help my developers go through and tools that I provide them. And this is a, you know, that'll happen in the first, the initial kind of a couple of quarters, but then ongoing, you can see that there's all sorts of topics that come up that you'll need to figure out, not only that they exist and how to solve them, but to constantly be addressing them. And, you know, there's a couple of initial things here, right? Like chargebacks is going to come up. I think some time ago, I had a little episode about chargeback stuff, but you're going to figure out how to need to figure out how to do chargebacks and kind of how to cycle through different ways of doing it. You're going to have to figure out how to, again, do all your monitoring stuff. And then also just generally, right? Like in your organization, you're going to have to evolve who has responsibilities for what in your DevOps world, right? Like how much operational response in production responsibility developers have versus you, the platform team? How do you divide that up? Like there's a lot of this constant discovery that you're going to go through. So you really are making this long-term commitment to doing something. You know, you're more, this is all soft, the way of putting it, but you're more providing this idea of what a platform is, not just the, the actual infrastructure, the code, the running stuff that you're providing. Now, a couple of more things. One, if you think about this idea that what we

operations, infrastructure, sysadmin, whatever admin people are doing now is we are making the lives of our development teams better, right? Like we are, we are the, the servants, if you will, of them. Some of the things, you know, you also have other stakeholders and that will largely be your like compliance and security people, right? But this brings in two other areas that traditionally, I don't think most infrastructure ops people think too much about. One of them is for developers, again, to remove variability, but also to make it better, to make the overall quality of running their software and all of the production concerns that you have. It's highly likely that you will want to control as much of the build process as possible, right? So, um, you know, I'm always a little leery of, uh, kind of centralizing a build, but that's just my own personal history with like the build person who was always a bottleneck long, long ago when I was a developer. But nowadays, I think it behooves the platform team behoove, uh, and also developer teams to try to standardize on a way of automating their builds, right? Their continuous integration tool and how the tooling that they use in the policy to move from checked in verified code to packaging it all up and making sure that it gets into production, right? So generally what I see is this is a function that the platform team really is in charge of. And you can think about all the other tools that are involved in doing software and how the platform team is probably best suited to be in charge of that as well. Now, the other side that comes with this is it's probably a good idea for you, the platform team to kind of be the focal point for dealing with compliance and security and things like that, right? Because if you control the build pipelines, uh, and you control the runtime environment, right? Your Kubernetes stuff or your platform as a

service, you have, you're, you're the people who have the ability to automate and improve the quality of compliance and security because you can automate and bake in and enforce a lot of those things rather. And this is an example of how variability is a problem rather than across your 10, 50, 2,000 product teams relying on them to talk to the compliance and security people and relying on them to do the right thing and also relying on them to report it back and to constantly be doing that, right? Instead, you can suck a lot of that down into the build pipelines that you have in the platforms, not as far as enforcement, but also just standardizing on how it's done. So those, again, this is the part of the product management mentality is like, how do we always make our developer lives easier? How do we always make the quality of the software that they're running easier? Not just the infrastructure that traditionally we are in charge of, right? Pay attention to the whole picture there. So finally, after that, um, kind of in the ongoing way of running stuff, right? Like what, what you get to very quickly is, all right, how do we scale that up? I mean, this is how you scale thing. Anything new up in an organization is kind of the only concern for the next, depending on what position you're in two to five years in our industry, right? Like you'll need to settle on how to do something in the small, right? Like how to start doing a couple, a handful of new projects this way. But then for large organizations, the next thing is going to be like, how do we sustainably scale this out to thousands of different teams, thousands of different whatever, right? And I think as always, right, when you're putting together your strategy, the important thing is to start small and slower than you think, right? Start with a handful, you know, like two to five projects, get, get not only like, uh, I don't know what you would call them really eager and overly skilled, full stacky kind of people and developers to work on that. But you also will need to get people who are

normals, right? Who are just sort of your regular people, uh, and use them as this kind of the customers initially to start specifying what this platform should look like and all those things I was just going over. Right. And what that means is you're going to be learning along the way. So you don't want to do everything at once. And so you need to start small and probably over the first year, you're not going to get extremely far unless, unless you're lucky. Here's a tip about feeling lucky. Everyone thinks that they're going to be lucky. They think that they're going to be the ones who, uh, who, uh, who are lucky. Now, the opposite of that is, is this quippy thing to point out that 50% of the people are better than average and 50% of the people are worse than average. I think it might actually 49.5% if I were to think about it, but whatever. Um, but you know, try to be more conservative in what you're doing here and, uh, plan things accordingly. Now, uh, equally what that means, not equally, but another thing that comes up a lot that people skip over is that you're going to need to be spending a lot of time initially, probably the first six months, if not the first 12 months doing a lot of consulting with the developer teams, uh, basically really sitting with them and doing a lot of hands on like, here's how you package things up. Here's what it means to run stuff in a cloud native architecture. Um, here's how you can make things observable. You might even need to have some capability of, of actual development, right? Uh, here's how you just use the tools to request resources and, uh, set up your own clusters and your own things like that. So I've found that pretty much all organizations that they need to, uh, they do a lot of this consulting. Um, and also, uh, you're going to need to spend a lot of resources, um, not only on that, that hands-on consulting, but what I think of as internal training and marketing where you're going around and advocating, or as we used to say, evangelizing, uh, the use, what this platform is and people using it. And as I've mentioned several times,

it's almost a year ago now, but like, um, there's, there's some good examples from, uh, BT, formerly British telco, um, where they have this project canvas is the name of their whole platform initiative. And they spend a tremendous amount of time. They have at least one person fully dedicated to just going out and internally marketing, raising awareness. Um, I don't know what else to say than about evangelizing, but evangelizing the platform. Um, uh, and you know, it's, it's great, actually, uh, people get very interested and it helps, helps, uh, those development teams you're trying to reach rate, you know, know about your platform and kind of figure out how they can start being in it. Now, bigger there is that probably your platform team is going to need to start, um, running internal conferences about every three months, and you're going to need to find help eventually other people outside of the platform team. But you want to get those developers who are running, uh, applications on there to start speaking at those and, and again, start helping train, raise awareness and train people. And you're going to need as platform people to do those sessions as well. And hopefully you can record these and put them online on your intranet or whatever, and start to use them as the material to bring other people, uh, up to speed. So I think I've already gone over the, uh, the product management part, uh, quite a bit, but finally from the beginning, start thinking about how you are going to prove yourself, report metrics to whoever it is, is controlling your fate, controlling your budget, uh, controlling your ability to do things, your, your, um, your priorities, the bosses, whoever your boss is, right. Um, and start putting that, that together and reporting on it regularly. Now, obviously what you want to show with metrics is improvement, right? The other thing you want to show with metrics, um, despite what, you know, if it's good or not, you want to show ROI, return on investment. Now, a more sophisticated way of thinking about financial metrics is you're showing that you are getting value for your spend.

Now, Americans are particularly bad at thinking about getting what you pay for because it's part of our culture, uh, to really try to get the cheapest deal possible. Like we don't really think about there is, there is a point, I forget what they call it, of marginal returns. There is a point of spending where you're not getting that much more for what you're spending. Um, but until you reach that point, the more you spend the better quality and the more that you get, uh, which is something us Americans don't understand. We always think that if we're clever, we can horse trade and we can spend a lot less money than someone else and get the same quality, if not more. Right. So, you know, this, this mentality percolates a lot, especially in, in us thinking, but it does in other firms. Um, but you still have to report on ROI. Uh, and you know, the way, the way that this TD Ameritrade is great on do it that they figured out how to do that is they won the model or the framing. They won the definition of what that meant. And what the definition of that meant was that we will achieve value. We will achieve return on investment as we move applications to the platform. So the, the, the one metric that they started tracking was how many applications that we moved to the platform. So the, the less applications they have moved, that means they need to investigate and figure out why the more that they had moved, the more success they would have. So that's a good metric to report. Right now, again, to this idea of constantly evolving, uh, what you're doing, they shifted that after a while, they shifted that to, well, we will actually achieve value, even more value return on investment when we move these applications to production. Right? So that's the new metric. They started tracking after some time, but that's just an example of how to track ROI, right? You're spending time and money. And usually the way you figure time is just staffing, right? Um, you can get really sophisticated with opportunity costs and things like that, which is totally cool. If you can get an agreement on that, but start thinking about

return on investment based on staffing time, uh, and, um, things like that as they basically did now, and, and just moving things, uh, to the platform. So then the other thing, uh, that you will have to start thinking about tracking is you can call this time to market, but somehow start, start to think about how you will model out and win agreement on how you report on, we are, the business is moving faster, right? Which could be the business can innovate new ideas. So the actual business can change how it operates, which basically means adding new features. Um, even if they're not changing how they operate, we are able to deliver more frequently. So even if we're just kind of making incremental improvements, uh, we're improving how the business currently functions instead of changing how it functions, but we can do that more rapidly. Right? And this is kind of just tracking feature delivery, right? Like we are making it faster for developers to deliver features. Now, you know, you can also track in, you should also track like how fast you can do. Um, people like to be all cool and say CVE, but you know that you can do security patches and you can address needs that you have. Um, and that's a great thing to track as well, you know, off in, uh, here in to be a little vendor pitchy, we have this five S's message that methodology. That's, uh, as you can imagine, five things that start with S and there's a good framework that we have there. If you want to use that as a baseline for, I think there's like five, you know, it's like speed, stability, security. I forget what they all are. I don't have my charts with me, but there's basically five or eight or 10 submetrics in there. And you can kind of a pick and chooses makes sense for you as a kind of a baseline of metrics to do. And, you know, if you start doing that from day one, if you have a baseline, it allows you to really track improvement and start reporting on, um, on, on that success, that success on how things are going. But, you know, so that's my, my kind of brain dump on everything that I know about, uh, platform operations and, uh, and delivery. And just to go over this last list and I'll put this

stuff in the show notes, why not? But you know, this list is kind of funny, but it is a good list from, from the, uh, from the Gartner people from this other report of like the type of people, uh, that you want for your platform operations team, right? The type of people that you, the skills that they have that you need to start thinking about that's kind of in contrast to traditional infrastructure people. Now, as always, I would suggest that like, these are the roles, these are the types of people that you always want, right? Um, which is fine, but like, it is, it is a good list to kind of start with. And, you know, the other thing I was, I was making a, a snarky tweet about this this morning, but you know, you're going to have a skills gap. It's really hard to find all of these, uh, all of these kind of like, uh, angelic, uh, perfect, uh, profile of people. So, you know, figure out, don't figure out how you're going to, uh, hire some perfect person who has all of this stuff, figure out how you're going to train up the existing people that you have, you know, how you might find, uh, some people that even, even though they're probably not going to have all these skills carefully, how you train people up to this, right? And like I said, we here in Tanzu land in our pivotal labs practice. We have a, uh, uh, an old, very old in a good way. We have a very mature proven practice of helping organizations do this. We help build up, uh, this competency, um, more so than just a PS capability of getting things up and running, but we can help you build up that capability. Um, and it's not staff augmentation. We're helping train people by pairing with them and, uh, setting that up for you. But I mean, look, you're going to need to do that. Like, you're going to need to spend some time training and learning how to do this stuff. Uh, cause really, no one knows how to do it. And if they really do know how to do it, they're, they're getting paid a lot of money. Uh, and, and, uh, you know, you can always use money to hire people away, but you're talking about, um, uh, basically going in and doing some, uh, do they say poaching, poaching from other

organizations where people are, uh, well compensated. And that's a low volume thing to find people who already know how to do this stuff. So instead be more realistic and focus on how you bring your existing people up to speed, uh, for, for what they can do. So, uh, that's what I got for you today. I think it was, uh, instructive, helpful for me to go over that kind of work. Um, and you know, as always, Hey, are you interested in figuring out more about all of this? Let me bring up, uh, some references, uh, that you might be interested in. Now I've mentioned several times, uh, that we have, uh, if you want to, we can help you out with, uh, doing a lot of these practices. So if you go to Coté.pizza, here's what you can do. You can set up, you can go here and you can select software development office hours, and you can just submit this and we can figure out like not only how to sort out your application priorities and things like that, but we can help you start figuring out how you might put together your, uh, your platform operations team, uh, and your strategy there. Also, like I said, you can try to directly contact me. Email is pretty good at Codem, C O T E M at VMware.com. You can send me a DM in Twitter if you're into that kind of thing. And, uh, you know, I don't really do this work. I just talk about it. So, uh, you would have, I can hook you up with someone else. Now, also, if you are someone who's interested in figuring out, uh, Kubernetes speaking out, is there any embarrassing stuff there? I always wonder that. Nope. Looks pretty good. Uh, if you, you know, speaking of training up people that you have and, uh, getting better, uh, with, with yourself and your, your team, you can go to kube.academy and there's a tremendous amount of, uh, free training and certification. I mean, I almost feel like I haven't gone through all the training. Oh, look, there's Cora. I should see what she does. But I feel like if you were to go through all of these courses, you would have a pretty solid, uh, standing of what, of not only

what Kubernetes is, but how you use it and put it into place. And, uh, eventually, hopefully we also have some training on more platform oriented things, uh, for tons of application services, all sorts of training out there for, for that as well. Speaking of, if you're interested in developer, uh, knowledge, you know, resources, this is kind of, even though we call it the, uh, the developer center, it's actually kind of becoming, uh, as they say, the hub or, or the center of attention for all of the kind of technical material that we have. I just finally submitted a piece on what, uh, you know, digital transformation is beyond the BS way that it's used. Um, but you can go check that out. We've got all sorts of topics over at tonsu.vmware.com slash developer. Now, all of that is available. If you want to see the, the, the show notes, the archives, past episodes, uh, for what we have here, if you just go to Coté.io slash tonsu talk, it's all there. You can see yesterday's past episode, uh, you know, all the CTA, CTA stuff that I went over, it's all there. So with that, we'll see everyone tomorrow. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.