From Objects to Capabilities: Joe Hoh on Infrastructure Team to Platform Team

Episode 186 · 44:34 · SRT · archive.org · all Tanzu Talk

All right, welcome back, folks. We are here for another episode of Tanzu Talk. And with me today is Joe Ho from Great American Insurance Company. Say hello, Joe. Hello. So great to have you on. And this is kind of part of the series that we've been running, looking at folks who've transitioned from having more of an infrastructure background over to really having more of a platform focus and sort of the evolution that we've been seeing over the last, you know, five or so years where, you know, as folks are really trying to focus in on supporting developers, there's been a kind of change in the roles that people have. So with that, we'll go ahead. But my first question is usually around kind of walking through what sort of the day in the life before when you had more of an infrastructure background and feel free to kind of fill us in on, you know, what specifically your role was on the infrastructure side. I know when we spoke before, you mentioned, you know, kind of a really diverse background. We were talking networking. So I know that that came up. But yeah, kind of tell us about what where that came from, and how you kind of got into it. And then we'll get into what your day in the life was. But how did you how long did you do that for? And kind of what was that that role all about? Okay. Well, so I've been with Great American since, since I got out of college. I started in actually as an actuary, back when we only had green screens back in 1990. So I'm dating myself quite a bit there. But had an opportunity to put in the first server into the environment. And that was like,

you know, we had a we had a product come in, that needed some storage, some shared storage. And we were like, how do we do this? Because it was back in the early days and cobbled together a server and some Arknet and installed Novell Network for this very, very focused delivery. So it was the first server in the in the company. And yeah, it was so, so it was really customer driven from day one, I guess. You know, it was like, find a need, and then fill that need. So throughout my career, that's kind of been my, my mantra, or, you know, or, you know, what, what is, uh, um, driven me to discover new, new technologies and explore new technologies. So, um, moved into, to networking around 2001. Um, I was given the opportunity to, uh, join an engineering group. Um, I had been working in networking and, uh, we had some changes in our organization and they were going to make an engineering team. So I decided to jump from, uh, from strip, from being focused on networking to move up there. And the first project I had was for monitoring. So we wanted to monitor our environment. Well, nobody wanted to monitor. Nobody. I was an intervener. I was, it was, it was very, um, frustrating. I was getting nowhere. Um, um, so we were a windows based environment and, um, it was, it was just a, an uphill struggle to get any movement because of political, you know, really it was political, uh, you know, that this other group was telling this other group how to, how to run

things. So, um, um, I decided, well, I'm going to go down and join the infrastructure team to do the monitoring from the ground up. So I joined the server team on the Unix and Linux, well, Unix team at that point, cause Linux wasn't really a thing. Um, three people, me, including me. And, um, about two months later, the other two people left. So I was stuck with, um, some HP UX servers and, um, uh, a burgeoning Linux environment that I was trying to build out for monitoring and like figuring out how do I run this stuff? Um, so, um, starting from there is really where I kind of got into the, got, started thinking in a platform mindset, um, from a, from the monitoring perspective. Okay. Um, if that makes sense. Um, you know, like what are the, what are the, you know, core capabilities? How can we, how can we, um, provide, um, base levels of functionality across many different systems, whether it be, uh, a networking device or a, or a server. Um, because those were the main components at that point in time, maybe we had a small sand, but anyway, so just thinking like, you know, working with, uh, with consumers, but at their level, because the top down approach didn't really work to, to partner with them to say, what are the problems that you have? And how can we take some of that burden off of you and from a monitoring perspective? And we were doing it in, in Linux at that point in time, which was helping to build that platform out. Not too far after that, it was, it was, um, time for virtualization because, um, uh, I could not warrant purchasing hardware for all

these little projects that I was having. So, um, um, it was time to, to make use of, uh, virtualization to get more out of less resources. And so, um, I brought in VMware and started to build a platform around that, how to, how to turn a, a set of, of activities for delivery into a consumable service that somebody, you know, with, with predefined inputs and outputs that is consistent every time. And, and can, can you give me an example of like, what's, what, what's, what were some of these activities? Like, well, I mean, I mean, it was not monitoring. No, well, we were focused on, so we, we were, we were building the, the monitoring was, uh, uh, uh, a use case for virtualization, but then once virtualization, well, you know, we, we had our first cluster, you know, we had our first non-prod VMware cluster and our, and our first prod VMware cluster. Then it was like, people started coming out of the woodwork saying, wow, you can deliver something that was very custom. And it took a long time to get servers onto the floor. And now you can turn that around very quickly. So we had, you know, we had lots of consumers of that product. And so I, I, my team worked to create the t-shirt sizes, if you will, or, you know, like, like you fill out this form and then you will have a VM and, in some, you know, piece of time you to, to basically, um, standardize the process versus everything being a customized tuned, everything was different, you know, um, you know, in the, in the old days, when you were building a physical server, it depends on who built the server

as to how that server ended up being realized for all time. Lots of snowflakes. Lots of snowflakes. There you go. Um, so that, you know, seeing that from the monitoring side and realizing that we had to get better at consistency and standardization and seeing VMware as a platform on which we could do that with, um, at, you know, your gold images and, and whatnot, um, we, we built that out and it was, it, it was a beautiful thing. It was very rewarding and all along learning, you know, everybody that was involved in that learned a bunch of new skills at the same time, you know, learned about automation. We moved a data center, um, through automation from one data center to another using VMware and, you know, taking things down. So we had a big, a big project where we P to V to V to a bunch of things. We did vert, we did automation for that. So I guess, um, every, every step along my journey was filling in another puzzle piece and what would eventually be used in my current role as, as platform operations and building a platform on the, uh, Tonsu products previously pivotal. Okay. And, you know, just to kind of fill in a little bit of color, cause I'm curious, as you kind of built out that initial platform years ago on, on VMware for just, Hey, here's, instead of just a custom thing, every time someone wants a server, we can stamp out, uh, uh, you know, across a couple of base configurations, we can stamp out a, a VM for you. Who were the customers in, in that situation? Was, were it developed, was it development teams? Um, so most of, most of that

time, um, we were delivering, this is, this is also where we started like an architecture, architecture, um, practice where, uh, customer would come in and that would be like a line of business. It wouldn't be really the business. Okay. It would still be somebody in it and they would say, Hey, we have this product that we just purchased. How do we get this in our environment? Um, sometimes we would be able to, um, um, get ahead of that and be part of the product evaluation because infrastructure is always, you know, in our environment, at least they're always the last to know that they're going to have, you know, something to, something to support and deploy and, and manage at the end of the day. And so the architectural side was trying to get ahead of that to say, Hey, get us in on the front end so we can understand before or while you're buying it, what the costs on the infrastructure are going to be and what the integrations are going to be, what operating systems, how big are they going to be? What do they need to talk to all these other kinds of, uh, um, non-functional requirements. So our customers were people that were trying to get their products deployed. And some of that was for development, you know, in-house development, but a lot of it was for, for COTS applications. Okay. And when we built, when we wanted to support development, those were pretty cookie cutter because we were a Tomcat shop or we are.net shop. So it'd be like, Hey, we need a Tomcat VM, you know, we're going to be running, uh, you know, we need a stack from dev all the way up to prod, make it so. And we'd build out, you know, 14 VMs for them and, and across those environments.

Yeah. Okay. But the COTS actually dragged a bunch of specific requirements and... Exactly. Yep. Interesting. Okay. Yeah. That was one question, which I'm sure will come up again later in our conversation about, you know, who the, who the customer is. Um, and so, you know, if you think about, you know, it's, it's interesting, you, you described really this, this whole arc that's, you know, the, the industry has really gone through frankly, but I guess maybe thinking about the sort of most recent sort of time before, uh, before kind of engaging in sort of the new platform operations role that you've been in, what, what was your day kind of like at that point, you'd already sort of stood up the, um, the platform, the kind of VM based platform for years, and we're going to stamp that out that that's up and running. You already had that architecture practice to kind of get involved, but what was kind of the day to day like? It was a lot about, um, focusing on delivery of objects. Okay. It was very, um, or at least the, the, the, the, the people that were, that were, um, building the VMs are responsible for the virtualization environment or even hosting or networking. It's very object oriented. It's very, I am, uh, uh, um, I, I have to, I have to deploy this VM. I have to provision the storage. I have to create this F5 with no context as to what value it provides. Well, you know, what's the big picture of this thing? Um, you know, we, we, in the, from the architectural side, we try to have, you know, good documentation, uh, you know, an overall system diagram and stuff. But at the end

of the day, that's really the, um, the way that it works is you're just given a unit of work and you just had to get that done. So, um, kind of, uh, probably less rewarding, um, because you don't see the full picture. And a lot of times it's, it would be like firefighting. Um, you know, that's the other part of it. You're either, you're either delivering things or you're firefighting for some unknown requirement that wasn't, you know, once you delivered it, all of a sudden they started to use it and the use case deviated from the original use case. And now all of a sudden, now it's, it doesn't fit. It's not fit for function. And that was always, I mean, it still is, I'm sure very frustrating. Yeah. Um, I can see how that, that happens. It's like, oh, I have this in place. Now I can use it for this other thing too. Exactly. Yeah. So we're like, I thought I was going to use it like this, but then the business requirements changed or somebody created different code. And now it's like, it's a, it's, it's, it's a completely different thing. And so we have. So this sort of is past or firefighting. Um, okay. Sorry. You were about to say. No. Um, I mean, we have, we have pretty stringent security requirements because we're in financial services and sometimes, you know, all of a sudden they'd want to consume something or connect to something in a non-standard way. And we're like, well, you can't get there from here, from our security constraints. And then that would cause all kinds of, you know, rework, which is, you know, something that I really, really hate to have to do. Um, I hate to have anybody else have to rework anything. Um, that's one of the good things about the platform is that it's built for rework. You know, it's built to automate any kind of rework that has to be done.

You know, if you have to get, you just deploy, just deploy it again, just deploy another one that works right. And, you know, migrate users over. So the, the impedance, I guess, to having to rework is much less or not the impedance, but the, the effort to have to do rework is greatly lessened on the platform that we're running today versus what we do in the old environment. Okay. That's, that's super interesting as, you know, one of those almost like fundamental truths of in the, in the olden days, right. In the before times, we, you know, and it's not that it was actually true back then, but it was, it was the mindset and the assumptions, which is that we are going to build this system and we're going to build it. So it's resilient so that it doesn't have a failure and it's going to serve the purpose and it's that it's, you know, been designed for and, you know, and we're never going to have to rework it. And the reality is things will always fail. People are going to change what they're doing because, you know, the business isn't static. So why would the way people use their technology be static and things will have to get reworked? So kind of inverting that whole paradigm and saying, what if we just embraced the fact that things fail and they need to be reworked? Right. And so don't be afraid to blow it up because it can be recreated immediately. Yeah. Versus etched in stone. You know, they used to be children. I used to know every server name by heart because I was, I was intimately involved in what it did and why it's there and you know, everything about it. Yeah. Now it's just, Oh, that's just another app. Okay. Okay. We, Phyllis runs a little hot. We already know that about her, right?

Yeah, exactly. And there's, there still is a lot of that because we, you know, we have, you know, 5,000 VMs that are still traditional because you can't run cots on the platform yet. Yeah. So now let's contrast that we're sort of starting to get there a little bit, but contrast more the day in the life for you, right? How you spend your time before kind of, Hey, we're stamping out tasks, sort of delivering objects, as you say, or we're firefighting, um, and potentially that leading to very painful rework. Now let's kind of fast forward. You're, you're kind of, um, on the, the operating a platform. Yeah. What does your day look like? Yeah. So, um, it's, it's very much focused on delivering capabilities, um, versus that, that can be used to automatically create objects. You know, it's not the individual object that matters. It's the capability to create objects. So, um, you know, we've got projects for, um, enabling, uh, new foundations. Uh, we're a pretty small shop. We've only got four foundations. Um, but we know that we're going to have more foundations. So, you know, how do we, how do we isolate those foundations away from the developers, um, that they don't have to know that they're foundations or, uh, we just enabled, um, the ability to use, uh, spring cloud data flow because that is a, that is a, uh, a capability that has business value. So, you know, how do we do that? How do we, how do we manage that? How do we scale it? What's it going to take? And so you're not really worried anymore about the individual instances

of it. Although, you know, we try to understand architecturally what they're doing so that we understand the capacity, you know, the network capacity, the, the memory capacity of the platform that we need. But, um, at the end of the day, it's, it's much more rewarding to work with a business use case that says, Hey, we need to operate on this data to build this, to deliver this business value. And we think this is the right tool for it. How can the platform help us scale that? Um, so it's, it's, like I said, it's much more, much more focused on delivering capabilities than, than objects. Obviously you've got your regular, um, you know, you want to make sure the health of the platform is good. You look at that daily. Did my backups occur? You know, what are, is anything failing? Um, you, you get notified on those. Um, and then you've got developers that have, you know, that have fires, um, to them, but they're usually in dev and it's, and it's more of a more, more of a collaboration than it is a, an emergency because you're, you, you, we know what they're, we, we, we know the types of things that they're doing based on their consumption of the platform, um, ahead of time versus this wall between devs and devs and operations that exists in the more traditional, um, infrastructure roles. Yeah. That makes sense. Tell me, tell me a little bit more about that. So it's, you know, dealing with the, dealing with a fire in dev, how is it more collaborative and, and how is it that you already know kind of what's going on?

How, how, how are you at that point? What's different? Well, we try to, we try to get before anything becomes targeted for the platform. We try to have a discussion with them. So we're, you know, we're going to create a new org and we're going to put some apps in it. Okay. We have, we try to have a discussion with them as it goes through an architectural gate in our, in our corporate, you know, process for, um, uh, project planning. So, um, we try to be at the table there to say, okay, what, you know, how many, how many of these things you're going to do? What kind of, how, how many apps are you going to have? How many APIs are you going to have? What's what services are you going to consume? So we have some like basic understanding of what the general consumption is. And then from a firefighting perspective, it's usually because we're still in the early, early phases. It's usually, um, about the developers understanding cloud native development and how, how to, how to, how to configure their projects so that they can plug into the concourse automation that we have and the, the ability to scale, you know, we have some, some issues with, you know, uh, you know, session IDs, uh, you know, not being stored in a, in a backend so that, you know, they, they can take available, uh, make available all the instances, this, the horizontal scaling that the platform provides. So it's a lot of education and it's good for both parties, I'll say. Um, because when you know a subject very deeply as, as our, our, our platform operations do and some developers, I mean, most developers do who have been on the platform,

it's easy to assume that somebody new coming in also knows those intricacies. And so it's a, it's a, it's a, it's a, it's a, an opportunity to, um, educate, um, because I think that's a lot of what, uh, platform operations is and DevOps in general is it's educating each other because nobody knows everything. We all have more to learn. So that's, that's very rewarding. I think for, uh, at least that's the feedback I get from the other cloud ops, uh, the, the other, um, platform operations folks is they always get to learn something new and they also have the ability to provide that information. And we have documentation, um, for a lot of that stuff, but, um, and it's easy to, you know, go point at the documentation, but it's also, you know, fun to walk somebody through it because people learn in different ways. Yeah. That's a, that's an interesting kind of nugget there about, Hey, it's really this kind of constant process of educating and, you know, engaging with all these teams, keeping that beginner's mindset, right. And remembering that, you know, even though this other team has been operating on the platform for a while, so they get it, they know what they're supposed to do with say their session IDs. Um, this new team that's coming on isn't going to necessarily know all that. So how do you go about that? I'm curious also, like, you know, how do you, how do you kind of, uh, navigate egos in that scenario to like, not show up with, let's sort of walk you through everything in case like, they're like, well, we already know that you don't have to talk to us that way versus also not completely like showing up with nothing and letting them fail. Right. And then saying, Oh, it looks like you need to understand this principle in order to run on the platform.

I don't know how you, I don't know that we consciously do it. It's just, there are some expectations that, um, new developers are doing pair programming with more experienced developers on the platform because it is different. Unfortunately, that always isn't the case. And, um, so we, you know, you have to, you, you, you have to gauge based on how they're asking the question, how informed they are and where, where to take it. Um, uh, whether to, you know, answer a question with a link to the center of excellence documentation or whether to, um, say, Hey, let's, let's, you know, can you share your screen? Let's go off on a team's chat and, you know, and let me see what you're, what you're seeing and, and, and that kind of thing. Um, it's, um, time is not, you know, time still our most limited resource, but we've realized over the past three years that time spent quality time spent with developers is probably more important than jumping from thing to thing really quickly as you do in operations often, you know, um, to be able to, um, because, because they'll, they'll get more out of it and they'll be, uh, you know, you're, you're putting time in now to save time much later on, I guess. Yeah. Okay. That's, that's another great nugget. I think, um, that, that sort of resonates with some other folks that we've talked to in terms of the balance of your time spent and spending more of that with developers. So, um, thank you. Right. The good thing about the platform is knock on wood is that it's available. It's not going to fall

over. It's not brittle or fragile. So, uh, back to the, the core, the core function that we do on a day to day is delivering new capabilities. If, if we have to spend some more time with, with, with developers delivering product on the existing capabilities that those other capabilities can usually slip, you know, a week or so, because it's just an understanding that we're going to constant, we we've demonstrated that we'll, we'll be constantly delivering capabilities. And so we're not tied to arbitrary hard dates. Yeah. Because, because, you know, we're delivering more and more apps at a much rapid, much more rapid pace than has ever been achieved at the company. I mean, we've, we're, we're, we're, it's not huge. We're up to 300, you know, different apps, not app instances, but apps. And that's, that's in three years. I mean, that's, there's nothing, nothing that we've ever done that's had that kind of scale. So there's the evolving culture is accepting that. Yeah. Well, and, and to your point before, where, instead of being focused on those delivering those objects, which is kind of like, it's a, I'm going to mess up saying, assembly line, well, it's the Sisyphean task. Oh yes. It never goes away. So you roll that bolt up the hill and you're just going to have to do it again tomorrow. That's right. I got another OS upgrade. They're going to need another VM in, you know, X number of years. Yeah. So if you've automated that, then suddenly it's like, oh, I have more time. Right. And, you know, getting started is probably where the most work is. And you, once you've covered, like kind of using just 80, 20 rules, once you've covered 80% of these are the objects that we've had to, we've had to deliver again and again and again. Now that's

automated. So we still have like the ever evolving remaining 20%, which is kind of your corner cases. But that also means that we have more time to invest with these developers to help them do, you know, be able to deploy onto the platform and be successful. And that is actually a better return on our time than making sure that we're constantly like getting more and more of those corner cases delivered, which to your point is like, you're, it's not that you're past the point of diminishing returns, but your, your overall return is just, okay, you've shifted the balance. And so much of the, the base object delivery and firefighting has now been kind of automated away. So without a doubt, you said that very eloquently. So I want to shift to kind of a couple more questions. Um, and you know, thinking about what are some of the things from your days on the infrastructure side, knowledge, skills, relationships that you've kind of brought with you and that, that continue to serve you well, right? Like those are, uh, yeah, the, the, as Marie Kondo would say, the things you want to bring into your future. Yeah. Um, what are, what are some of those things? Um, so, well, they're, they're actually, I don't know that there's anything that I, that I have done in the past that isn't useful to me in the future, in the present and on into the future. Um, as I, I said, in our, uh, previous conversation interview about networking, a firm handle on how networking works that not from a, you know, um, router, you know, switch perspective, but from a understanding how DNS works, understanding how HTTP works, understanding how, you know, connections

work and, you know, where firewalls can block you. Um, and what that looks like from a client side or from a server side. Um, that's, that's something that, um, I, I consider very, very foundational, um, the virtualization aspect of it, um, probably not nearly as important whatsoever. Um, I mean, we, we, we, we never touch VMS, uh, which is, you know, pretty amazing, um, to tell you the truth because we, we have like a third of all the VMs in the environment, in our environment, or maybe a quarter. And yet we never, ever have to deal with them, uh, which is, you know, a thing of beauty. It says a lot for what, what, what Bosch does, um, understanding, you know, uh, web servers, you know, that's something that, uh, and, and monitoring for that, for, from that, uh, respect, um, what, what are important things to monitor? What are key performance indicators? What are the, um, what are the things you need to poll versus what are the things you need to, um, just watch for events? Um, those, uh, have really helped in, um, in the first year of the platform to, to, um, on both the app side and the platform side to really tone down the, the, any kind of external heavy lifting that has to be done to monitor the platform. No, the platform provides metrics. Let's just look at those and let, and only, only put in extra

monitoring where, or write a script to check things out where it's really, really required, like where we can't get this information. Um, so the, the, the fact that, you know, built the monitoring platform back in, you know, 2000 and, uh, starting in 2001, that really helped, um, educate, uh, the other platform teams and the, and the developers. Like, how do you guys know that my app is up? Oh, well, we, we get events when it crashes, you know, there's logs that we stream and watch for events. So that's been very important because in the past we had to ping those things. You know, you had some synthetic transaction always constantly running against your app to make sure that it was up. Okay. Now, um, on the flip side, what are some of the new things that you've had to learn in your, your platform role, um, that, you know, you've kind of just added to your, your arsenal of skills and knowledge? Um, so, um, Bosch, uh, you know, Bosch is huge and we use it both in the platform and outside of the platform. Um, um, the way that containers are secured, the, the way that containers get, get out. So there's that networking component that I talked about as, as, um, needing to understand or providing value to understand, but how, how the containers actually leverage, um, that in Envoy and the go routers is, uh, you know, when, when you, when you're troubleshooting something, you need to know how that stuff works, where, where layers are, where the ASGs sit in the environment. And sometimes you forget those things and then you're rudely, rudely, um, uh, awakened

by, uh, the fact that, oh yeah, we have ASGs and we did, that is a new connection and we didn't account for that. And ASGs don't log when they fail and that kind of thing. But once again, you're finding that in dev versus in prod, which is good. Yeah. Um, learning a lot about, um, how modern applications are structured and built, um, you know, from the developer standpoint, um, you know, it's not, we work in scripting a lot in operations and infrastructure and it's top down. I have, you know, pre-described input inputs and outputs and modern apps aren't built like that really a lot of times at all. They're, you know, they're event driven and they're controllers. So learning about spring, um, not that I could write any of it, but it's very interesting. Learning Python is, uh, you know, that's, that's something that's very useful. I hadn't used that before. So. Okay. Any, uh, how are some of the ways that, that you've learned this or are there resources that you found valuable, um, you know, experiments or experiences that really pushed up your knowledge? Well, I mean, there are so many examples in the community of something that you need to accomplish. Um, I mean, I haven't, would none of us, none of us have gone to training for, you know, the platform. Um, the documentation for the most part is extremely good. Um, you have to read it. Um, and you have to grok it and we have a sandbox environment and you have to,

you know, you have to feel it viscerally. You have to experience how it's done. Um, so, um, once again, that's, that's one of the benefits of the platform is it allows you to fail fast. It allows you to try things and see how it works and you're not breaking anything and you're not causing anybody else any work in cleaning up after you, which is, you know, what is traditional in the old environment, uh, the, the, um, the non-platform environment, I shouldn't say the old environment. Um, it's so, um, it's, it's really self-discovery, you know, doing, doing the work yourself, finding, you know, being pointed at some resources and then giving yourself time to, to, to experience it viscerally, you know, you know, build it, run it, and then take it from there and giving, uh, you know, having the, having the organization allow you that time to learn how to do that stuff. Is there anything, if you were to go back and do it all again, is there anything you would do differently to make this transition? I think so. We started, we started conversations with Pivotal probably in maybe 2014, I'm thinking. And the, the reason we didn't do some adoption then, we always walked away saying that's really great. We don't have any use cases. And that was short sighted. Nobody wanted to be the guinea pig that would jump into, you know, that would say, I will make the financial, you know, the financial commitment to make, to, to try this thing out. No, no, no one of our organizations, no one of our

business units, no one of our, uh, application groups. And I think that was, that was short sighted. I think, um, being an early adopter helps and providing employees with some non-project time to explore those things is, um, is very much more important. And we're doing that now as an organization, we see the value in exploratory work that may, that may go nowhere, but at least you learn something and you learned whether or not it was going to be useful. So that was, that was, I would probably adopt sooner. Okay. Long-winded answer to a very short question. A very short answer. We needed all the color and texture. Okay. Okay. And then kind of, you know, I guess a related question is what advice would you have for folks who are, you know, currently in more infrastructure centric roles, maybe they're a VI admin or vSphere pro, um, or, or maybe they're more on the networking side. Networking, hosting. They all have, I mean, you're doing it, all of it. What, what kind of advice would you give to them if they're kind of, you know, they're interested in all, you know, they, they, they hear the DevOps buzz, they, they're curious about it. What, what should they be doing? There, there is so much free training available out there, um, from VMware and the hands-on labs, um, from the Kubernetes, uh, uh, uh, environment. Um, there, there is no, uh, lack of, of information to improve your skills and to understand how, how the new world, the new internet is working. Um, so I would, I would be, uh, telling people to, to, I would, I would be recommending, not telling people

to, you know, ask your management, Hey, can I have four hours a week, you know, to study this thing, um, um, or do it on, you know, in your free time, because, um, that's, that's how hands-on is how you're going to learn this stuff. You can learn a lot in books, but you, until you've, you know, press the button and deployed something, um, it's, it's eye-opening the power that, that you can grant, you can give to your customers and eventually, you know, the, the capabilities that you provide to whatever businesses you're in. Yeah. Okay. That's, uh, that is a great starting point. Um, and so with that, uh, I, I just want to thank you for your time and insight. It's been really interesting to, to kind of hear your, your journey. And I hope this is valuable for lots of folks out there who are dipping their toes into the, to the platform side and what they're, they want to do next and in their career and also what they're delivering to their businesses. So thank you. Thank you.

Tanzu Talk · 🍕 Get more pizza.