1 00:00:00,000 --> 00:00:12,440 All right, folks, welcome back for another episode of Tanzu Talk. Today with me, I have 2 00:00:12,440 --> 00:00:18,660 Neville George. And the questions that I've got for Neville today, I'll let you introduce 3 00:00:18,660 --> 00:00:23,560 yourself a little bit here in a minute, are really around that journey from going from 4 00:00:23,560 --> 00:00:31,420 a vSphere admin background into whether you call it a DevOps engineer or a cloud engineer 5 00:00:31,420 --> 00:00:36,980 or a platform engineer. There's lots of different words out there floating around. But what does 6 00:00:36,980 --> 00:00:41,820 that look like? So I've got a bunch of questions. But first, let's just, Neville, please introduce 7 00:00:41,820 --> 00:00:47,740 yourself. Hi, Dormain. Thank you. And well, before I begin, I want to say I'm a big fan 8 00:00:47,740 --> 00:00:54,200 of, you know, the Tanzu podcast. And certainly you do a great job, as always, in bringing 9 00:00:54,200 --> 00:01:01,980 some of these conversations, which are critical for a lot of people to the Tanzu community. So 10 00:01:01,980 --> 00:01:08,620 thank you for that. And I'm super excited about this opportunity. I have one thing for you before 11 00:01:08,620 --> 00:01:15,820 we start, just to make it a little bit interesting. I will give you a phrase and, you know, I will tee 12 00:01:15,820 --> 00:01:22,620 it up for you. And, you know, when I tee it up for you, you would you would kind of respond by saying 13 00:01:22,620 --> 00:01:32,320 there is no team without tea. Okay. So remember that there is no team without tea. And I think, 14 00:01:32,400 --> 00:01:36,280 you know, as we go through the conversation, hopefully, you know, we will have a couple of 15 00:01:36,280 --> 00:01:40,460 places where I will tee it up for you and you're going to respond with. 16 00:01:41,660 --> 00:01:44,500 There's no team without tea. 17 00:01:44,880 --> 00:01:48,060 Okay, fantastic. I think we I think this is going to be great. 18 00:01:48,860 --> 00:01:52,540 Okay, so now this begs the question, Neville, are you a tea drinker? 19 00:01:53,600 --> 00:02:02,500 I switch between tea and coffee. So but there are situations where I exclusively go only for tea 20 00:02:02,500 --> 00:02:08,140 and we call it tea time. So hopefully, you know, this will all blend in together well for us. 21 00:02:09,140 --> 00:02:12,740 Okay, okay. As I take up my sips of tea. 22 00:02:14,260 --> 00:02:21,160 You could, you could, you could, absolutely. So as for me, I am Neville. I'm a people leader at 23 00:02:21,160 --> 00:02:29,860 Comcast and I have worked for Comcast for about 14 years. I believe the end of May will mark my 14th 24 00:02:29,860 --> 00:02:37,480 year anniversary working for Comcast. I lead a team of super talented individuals who manage modern 25 00:02:37,480 --> 00:02:43,720 platforms such as Cloud Foundry and Kubernetes at Comcast. But before I became a people leader, 26 00:02:43,720 --> 00:02:52,240 I was an individual contributor for about 12 of my 14 years at Comcast. Every time I say 12 years, 27 00:02:52,400 --> 00:02:57,940 you know, it now feels like it's like a really long time. But I also keep telling me that, 28 00:02:58,000 --> 00:03:03,500 you know, I hear that young at heart is a new trend. So you know, I am very positive about that. 29 00:03:04,500 --> 00:03:14,980 I've heard 50 is the new 30. So I'm just, you know, I'll be transparent. I'm looking forward to that. 30 00:03:15,620 --> 00:03:19,020 But I also really like that that's what I have to look forward to. 31 00:03:19,280 --> 00:03:22,260 Yeah, yeah. Anything to keep us young, right? 32 00:03:23,620 --> 00:03:32,400 Also, I would say, you know, in the 14 years of my working at Comcast, I've played about seven to eight 33 00:03:32,400 --> 00:03:36,920 different roles. And it certainly kept things interesting on the way. 34 00:03:38,240 --> 00:03:44,220 Yes. Yeah. Having that kind of those shifts within an enterprise, keep things interesting. 35 00:03:44,740 --> 00:03:54,000 Yeah, 12, 14 years. I mean, that is, that's geologic timescale in technology. And so in that time, 36 00:03:54,060 --> 00:04:00,640 I'm sure you've seen a lot come and go, which is kind of a good setup for our conversation today. 37 00:04:01,220 --> 00:04:07,720 And so we'll start with, you know, let's, your background, you were once upon a time, 38 00:04:07,720 --> 00:04:18,940 if I'm not mistaken, you were a vSphere admin. How did you get into that? Like, what kind of got you 39 00:04:18,940 --> 00:04:21,700 to that point? And how long were you in that mode? 40 00:04:24,260 --> 00:04:32,140 So I'll start with, so I mentioned eight roles, right? So I literally started off as an active 41 00:04:32,140 --> 00:04:37,660 directory specialist, though I was given the opportunity to do much, much more than that. 42 00:04:38,140 --> 00:04:44,280 And then, you know, I played a Microsoft lead in a couple of like, you know, responsive and 43 00:04:44,280 --> 00:04:51,160 proactive lead roles. I've certainly, you know, been an enterprise storage engineer, virtualization 44 00:04:51,160 --> 00:04:57,980 engineer, enterprise backup engineer, a platform engineer, and then now eventually, you know, 45 00:04:58,000 --> 00:05:08,980 a people leader. The longest stint in any of my eight roles has been as a VMware engineer for about 46 00:05:08,980 --> 00:05:17,200 like four years and as a platform engineer for five years. And it's funny, you know, since I started 47 00:05:17,200 --> 00:05:26,300 as a Windows admin, I still have a Windows laptop, though I also use, you know, an active Linux 48 00:05:26,300 --> 00:05:33,280 desktop that I heavily rely for many of the stuff that I do. One of my recent hires actually told 49 00:05:33,280 --> 00:05:38,200 me that, you know, when he heard me that, when he heard that I had a Windows laptop, he was about 50 00:05:38,200 --> 00:05:44,980 like, you know, not take the job. But they're also very forgiving since they understand, you know, 51 00:05:44,980 --> 00:05:51,020 now that I'm in a people manager role, you know, I need to create a lot of PowerPoint presentations, 52 00:05:51,180 --> 00:06:01,520 apparently, right. But, you know, how I got into the VMware role, I was a storage engineer. And 53 00:06:01,520 --> 00:06:06,600 essentially, you know, our organization was comprised of a larger umbrella of products such as 54 00:06:06,600 --> 00:06:15,280 virtualization, you know, storage, backups, automation, etc. And the biggest client of storage 55 00:06:15,280 --> 00:06:23,000 at that time was our vSphere environments. And when virtualization was just catching fire at Comcast, 56 00:06:23,380 --> 00:06:32,480 it was a natural progression for me. And as I interacted more with storage and VMware, I started feeling that 57 00:06:32,480 --> 00:06:41,220 I could get used to this. At Comcast, during that same time, and it still is, right, like we talk about 58 00:06:41,220 --> 00:06:48,560 fungibility of resources. It was and still is a big thing at Comcast, having the knowledge and ability 59 00:06:48,560 --> 00:06:57,520 to put on multiple hats and contribute. And specifically for me, between storage and VMware, like appeal, like appeal 60 00:06:57,520 --> 00:07:05,920 very much to me. And that is where it all began. I did that for about like four years and loved it till Greg 61 00:07:05,920 --> 00:07:15,040 brought platforms to Comcast, right. And I'll name drop a few people, I really like to focus on, you know, people who 62 00:07:15,040 --> 00:07:20,180 have helped and who have made changes and people that I work with, you know, it's super important for me. 63 00:07:20,880 --> 00:07:27,320 Yeah, I mean, I think that, of course, looking at the skills and the training and the background, 64 00:07:27,920 --> 00:07:35,720 like sometimes you, you want to create this logical journey of an individual based on, well, they studied 65 00:07:35,720 --> 00:07:41,780 this, and then they got their first job doing this. But the reality is these, these twists and turns along 66 00:07:41,780 --> 00:07:47,680 the way of a career path are much more driven by the people. I'm just, you know, you're making me think 67 00:07:47,680 --> 00:07:56,440 of my own trajectory, um, leaving finance and going to my first job at a, at an IT vendor. Uh, it was 68 00:07:56,440 --> 00:08:01,500 because I knew the hiring manager and, you know, he was looking for someone who could write about 69 00:08:01,500 --> 00:08:08,200 technology. And I was like, you know, I'm, I don't want to end my career in finance. So, um, it had 70 00:08:08,200 --> 00:08:15,700 much more to do with who I knew than what I was actually doing or, or had been preparing myself 71 00:08:15,700 --> 00:08:20,820 so much. So it'd make a great point there, but there's also something to be said that, you know, 72 00:08:20,820 --> 00:08:29,160 your, your point about going from storage to the, the VMware side, um, you know, that resonates in 73 00:08:29,160 --> 00:08:36,100 other ways. It makes sense because this reminds me of back in the day thinking about why did EMC 74 00:08:36,100 --> 00:08:43,040 buy VMware way, way back in, I think, 2004. And that, you know, I was working for the lead investment, 75 00:08:43,040 --> 00:08:49,280 uh, analyst at the time. And he would, he's, he kind of had always scratched his head a little bit 76 00:08:49,280 --> 00:08:55,280 about what, what was going on there. And then when V motion came out, but in order for V motion to work, 77 00:08:55,280 --> 00:09:01,420 you had to be connected to a San, um, suddenly the light bulb went off. It's like, Oh, now I get it. 78 00:09:01,420 --> 00:09:07,140 Now I get what this connection is between these two worlds. So it's interesting to see that come up 79 00:09:07,140 --> 00:09:17,460 again. Um, and, and also, right. Like I'm part of the Tanzu Vanguard's community and we have many, 80 00:09:17,460 --> 00:09:25,880 many, many, uh, technologists who have gone through similar situations in their lives over a period of 81 00:09:25,880 --> 00:09:31,500 time. They've switched different roles. They've put on multiple hats. They've, they've had to go 82 00:09:31,500 --> 00:09:39,060 through all of this, right? So I think they have a common story here that people, uh, love moving 83 00:09:39,060 --> 00:09:44,560 around and trying new things. Yeah, that makes sense. And, and thank you for bringing up the fact 84 00:09:44,560 --> 00:09:51,060 that you're part of the Tanzu vanguard. I, I failed to mention that at the beginning, but, um, yeah, 85 00:09:51,060 --> 00:09:57,160 that's absolutely a community for folks to take note of because it's, it's a lot of folks like many of 86 00:09:57,160 --> 00:10:04,680 our listeners who are working in and around the Tanzu ecosystem and community. Uh, but, uh, it's a 87 00:10:04,680 --> 00:10:11,660 special group that, that gets together regularly and, uh, and has really fun discussions and, and sort of 88 00:10:11,660 --> 00:10:20,360 interactions with the, the, the VMware Tanzu product team, um, and is willing to share out kind of a 89 00:10:20,360 --> 00:10:25,260 lot of these lessons learned like you are today. So thank you. All right. I want to get to my next 90 00:10:25,260 --> 00:10:32,000 question, which is sort of, you know, one way I like to paint the picture of a contrast of, you know, 91 00:10:32,000 --> 00:10:37,400 some kind of transition is to think about like a day in the life. So you mentioned you, you, 92 00:10:37,400 --> 00:10:45,360 you were loving, uh, kind of the working in the VMware, uh, sphere and the vSphere world for four 93 00:10:45,360 --> 00:10:52,460 plus years. And then Greg came along and, and brought you over to the platform team and tell us a little 94 00:10:52,460 --> 00:11:01,260 bit about what was a day in the life like when you were on the, the vSphere side. And then how did that 95 00:11:01,260 --> 00:11:08,300 change? What does a day in the life look like for you now? Or if you kind of rewind a couple of years 96 00:11:08,300 --> 00:11:13,540 back to when you were at least an individual contributor on the platform team, what, what was 97 00:11:13,540 --> 00:11:19,280 a day in the life like then? How, how did things change? Sure. Certainly, you know, there are 98 00:11:19,280 --> 00:11:26,880 similarities and, and differences. Um, as a VMware engineer, I would, I would say, I like to split my 99 00:11:26,880 --> 00:11:32,760 days into, you know, slots and I, and I like to name them and then, you know, each of them have breaks 100 00:11:32,760 --> 00:11:40,560 in between. Uh, so let's, let's call the first one as, as dial time, right? So the dial time is 101 00:11:40,560 --> 00:11:45,960 essentially, you know, when you get into the office and you essentially start the day looking at the 102 00:11:45,960 --> 00:11:54,260 dials that show the health of your infrastructure, right? So if I am a VMware engineer, I look at, 103 00:11:54,380 --> 00:12:02,560 is everything functional? Do I have problems in my environment? Are there items that, um, indicate 104 00:12:02,560 --> 00:12:09,920 a capacity issue that is coming up? Right. And based on looking at all the dials or like what we call 105 00:12:09,920 --> 00:12:16,680 the metrics and dashboards, et cetera, we would, uh, spawn off different action items throughout the day 106 00:12:16,680 --> 00:12:21,740 or, you know, into the week. So that's like, you know, the, the, what I call the dial time, 107 00:12:21,740 --> 00:12:28,520 right? So right after dial time comes like the break time, right? So during the break time, 108 00:12:28,520 --> 00:12:38,280 you are supposed to have tea with your team because there's no team without tea. 109 00:12:38,920 --> 00:12:44,620 Aha. Got it. Got it. I think, I think it's going to be great. That was the first test. 110 00:12:44,620 --> 00:12:53,040 Yes. Yes. Um, so the second portion of the day, uh, I call it the hustle and bustle time, 111 00:12:53,040 --> 00:12:58,860 right? This is where, you know, we are, we are working on, uh, satisfying customer requests. 112 00:12:59,400 --> 00:13:05,440 If we have projects, then are we delivering on the projects that we have committed to? Uh, we would 113 00:13:05,440 --> 00:13:11,180 follow up on, um, on all of them, making sure that they are on target, uh, a lot of team interactions, 114 00:13:11,180 --> 00:13:18,360 interactions with other, uh, teams, more specifically on the VMware side, you, you kind of like work with 115 00:13:18,360 --> 00:13:25,440 infrastructure teams, right? Maybe your data center operations, your, your vendors, et cetera. You know, 116 00:13:25,480 --> 00:13:30,260 that is where like all of that happened during what I call the hustle and bustle team. 117 00:13:30,260 --> 00:13:37,720 And that usually probably gets us to lunch and possibly, you know, I would say the, the, the 3 PM 118 00:13:37,720 --> 00:13:44,360 slump, right? But when you get to the 3 PM slump, you need to take a break again because, you know, 119 00:13:44,420 --> 00:13:50,740 it is time to have some tea with your team because there's no team without tea. 120 00:13:51,420 --> 00:13:57,100 Great. I think you're getting a hang of this. Uh, the last piece of it is what I call, um, 121 00:13:57,740 --> 00:14:03,660 introspection time, right now the hustle and bustle time and the introspection time kind of like, uh, 122 00:14:03,720 --> 00:14:07,680 blend a little bit, you know, together, right. You know, sometimes, you know, introspection on a 123 00:14:07,680 --> 00:14:12,640 daily basis, you know, can be a rough a little bit. Uh, but this is like, I would say the part of the 124 00:14:12,640 --> 00:14:21,700 day where, um, you know, you focus on improvements that you can make to your environment. What are the 125 00:14:21,700 --> 00:14:28,500 things that are taking maybe the longest time for us to do the biggest pain points? Can we deliver them 126 00:14:28,500 --> 00:14:35,340 faster? Um, maybe even, are we adopting new technologies, right? Are we showcasing ourselves 127 00:14:35,340 --> 00:14:39,980 and the value that, you know, we do? So that is the introspection time. And I think, you know, 128 00:14:39,980 --> 00:14:48,040 it is very important that we spend some time of our, our week to understand, are we doing the right 129 00:14:48,040 --> 00:14:53,980 things to ensure that, you know, we can, we can keep up with the demand of what we are doing, 130 00:14:53,980 --> 00:14:58,900 right? I would say that is like the life as a VMware engineer. 131 00:15:01,120 --> 00:15:07,540 As, as, as I transitioned to the cloud platform engineer, I think there are a lot of similarities, 132 00:15:07,540 --> 00:15:15,300 things that, you know, I could easily adapt with, right? The dial time, for example, still 100% true. 133 00:15:15,660 --> 00:15:21,420 Yeah. If you remove like the infrastructure and just put platform, if you, if you put this on a boat 134 00:15:21,420 --> 00:15:27,100 and if you removed all the infrastructure and put platform, it would easily fit, right? And you should 135 00:15:27,100 --> 00:15:33,600 be good to go because this is like the basics for any engineer. You need to come in and you should be able 136 00:15:33,600 --> 00:15:40,040 to smell the smoke before you actually see the fire. It is crucial. It is something that every engineer 137 00:15:40,040 --> 00:15:47,740 does. And, and it's like, just like innate for all of them. So dial time, you know, holds good. I think 138 00:15:47,740 --> 00:15:56,840 introspection time is also 100% true. You have to be asking yourself, are we going fast? Are we automating 139 00:15:56,840 --> 00:16:03,780 stuff? Are we disrupting ourselves? And are we being prepared for shifts in the industry? What is the 140 00:16:03,780 --> 00:16:11,220 value that I provide? So I would say dial time and introspection time is, is 100%, you know, the same, 141 00:16:11,480 --> 00:16:15,240 except your focus is on a platform as opposed to the infrastructure. 142 00:16:16,100 --> 00:16:22,060 Yeah. So the, the metrics you're looking at in dial time are going to be different instead of looking 143 00:16:22,060 --> 00:16:29,060 at maybe infrastructure metrics. Are you looking at, um, just the platform health metrics or are you also 144 00:16:29,060 --> 00:16:33,780 factoring in anything about the, the developer community that you're supporting? 145 00:16:34,700 --> 00:16:42,580 Yes. Yes. And I think this is where like, you know, I, I think the dials do look at platform and 146 00:16:42,580 --> 00:16:49,580 developer experience centric information. Right. Um, and, and that is where like the hustle and bustle time, 147 00:16:49,580 --> 00:16:54,020 you know, is where I want to kind of like focus where the main difference happens. Right. 148 00:16:54,020 --> 00:17:00,900 Okay. So, and a quick question for you, just to, to double click a little bit. I'm curious, 149 00:17:01,260 --> 00:17:06,620 what metrics do you look at for the developer experience that are kind of something you could, 150 00:17:06,720 --> 00:17:10,460 you, you, you could check on a daily basis in that dial time? 151 00:17:10,840 --> 00:17:21,360 Absolutely. Yes. Um, so, um, I, I, I, if you're an infrastructure admin, right, your calculation of a 152 00:17:21,360 --> 00:17:29,280 developer experience is can a person go to, you know, a portal or can they automatically get the 153 00:17:29,280 --> 00:17:34,480 resources that they need? Right. So there has to be something in the background that like constantly 154 00:17:34,480 --> 00:17:41,920 on a periodic basis goes and deploys a VM and says, yes, that was completed. Right. So I know that I 155 00:17:41,920 --> 00:17:47,880 have smoke tests, you know, on a constant periodic basis. And if suddenly, if it fails, I know that 156 00:17:47,880 --> 00:17:54,480 anybody who's going to go to the site may experience a failure, right? On the cloud platform side, 157 00:17:54,560 --> 00:18:01,300 it is exactly the same, except people are deploying applications to your platform. So you may want to 158 00:18:01,300 --> 00:18:08,980 create some kind of periodic process that deploys an app as an example into your environment and sees 159 00:18:08,980 --> 00:18:15,240 if it actually deployed successfully, is the URL available, right? That is a simple example, 160 00:18:15,240 --> 00:18:20,640 but there are many things that, you know, we can do on the cloud platform side. It may be related to, 161 00:18:20,840 --> 00:18:27,740 is there a service instance that a person can, like a DevOps team can get, right? Are we running out of 162 00:18:27,740 --> 00:18:32,880 IPs, you know, when we provision on demand instances? A whole slew of things, but the idea is the same. 163 00:18:33,260 --> 00:18:39,880 We want to make sure, like, people who are consuming our products can get what we say they can get, 164 00:18:40,320 --> 00:18:44,460 right? And being more proactive than reactive actually helps. 165 00:18:46,020 --> 00:18:52,400 Okay. That makes sense. All right. So let's come back to it. Tell us, tell us how the hustle and bustle time has changed. 166 00:18:53,560 --> 00:19:01,540 Yep. As a VMware admin, right? If it's not a CPU memory and a storage issue, essentially when some, 167 00:19:01,760 --> 00:19:10,820 some, let's say an application developer comes to you and says, I have a problem deploying Java on my operating system. 168 00:19:12,140 --> 00:19:18,680 I, myself, right? And, and as an, as a VMware admin, you know, if it's not related to CPU memory or storage, 169 00:19:18,680 --> 00:19:26,180 it's like usually, yeah, it's, it's actually your problem now. Uh, and, and it's not my problem. Uh, 170 00:19:26,180 --> 00:19:35,100 but as a cloud platform engineer, I think, you know, it's a constantly evolving technology and we need to work 171 00:19:35,100 --> 00:19:41,920 more closely with the DevOps teams than, you know, if you were a VMware engineer, right? 172 00:19:41,920 --> 00:19:50,560 That's like one big, um, difference that, you know, I've seen, uh, also when people use the platform, 173 00:19:50,780 --> 00:19:58,540 there are much more, uh, things that, you know, we will have to make sure, um, that DevOps teams are doing, 174 00:19:58,540 --> 00:20:08,600 right? Are they optimally using the platform? Are they distributing their application, uh, to multiple 175 00:20:08,600 --> 00:20:15,160 sites to be more resilient? Are they following, you know, the, the 12 factor authentication things, 176 00:20:15,160 --> 00:20:21,960 right? Very different. Are they having proper data flows? Are they having proper log flows? I think 177 00:20:21,960 --> 00:20:30,200 this is where the biggest difference comes, uh, in the VMware world, I think the interaction with the 178 00:20:30,200 --> 00:20:36,380 DevOps teams on their day-to-day work is actually a lot less, right? You, you give them, you know, 179 00:20:36,400 --> 00:20:41,280 the required resources and then, you know, they do the runtime, they do the install, they do the 180 00:20:41,280 --> 00:20:46,720 management, they do the security, all of that piece. Uh, but on the cloud platform side, 181 00:20:46,720 --> 00:20:55,240 it's a shared responsibility, I would say. And in terms of, um, I kind of like summarize it like 182 00:20:55,240 --> 00:21:02,400 if you are a VMware admin, I think you spend 80% of your time focusing on infrastructure and maybe 20% 183 00:21:02,400 --> 00:21:09,740 of your time with your customers, right? As in like DevOps teams, as a platform engineer, as a platform 184 00:21:09,740 --> 00:21:16,600 admin or an engineer, it's exactly the opposite. 80% of your time you spend with DevOps teams and 185 00:21:16,600 --> 00:21:24,500 your customers. And I think infrastructure is just, you know, 20% of the time. Um, I, and I think that 186 00:21:24,500 --> 00:21:31,740 is the biggest crux, you know, for me, I find like I, I am more close to the DevOps teams and I can 187 00:21:31,740 --> 00:21:40,840 actually see the value like much more directly. Um, I'll give you an example, right? Uh, when my kid 188 00:21:40,840 --> 00:21:47,320 asks me, uh, what do you do for work, uh, as a VMware admin, you know, I would, I would talk about, 189 00:21:47,440 --> 00:21:53,860 well, I have to set up all this infrastructure, et cetera. And, um, you know, I, I have to do a 190 00:21:53,860 --> 00:21:59,220 whole bunch of things, which again, you know, it's not really easy for, um, kids to understand, 191 00:21:59,300 --> 00:22:04,180 right? But as a cloud platform engineer, like when my kid asks me, I can actually tell you, I can 192 00:22:04,180 --> 00:22:10,340 actually show them examples. Like when we pick up, you know, my, my Comcast remote and, and, um, 193 00:22:10,760 --> 00:22:15,740 you know, pull something up and I say something on the speaker, right? Like, you know, we have, uh, 194 00:22:16,000 --> 00:22:22,200 we have, uh, voice remote. Right. Do it. Um, those calls actually run through my platform, 195 00:22:22,200 --> 00:22:27,060 right? It's something that they can see and they can feel. I can take my application. I can take my 196 00:22:27,060 --> 00:22:33,120 Xfinity account app and I say, well, if I type something here, it's going to respond with AI and, 197 00:22:33,220 --> 00:22:38,660 and all of these calls are going through a platform that your daddy manages. It's very easy when you can 198 00:22:38,660 --> 00:22:45,720 actually show some of that. So I feel like I can see the value much more closely than, you know, 199 00:22:45,740 --> 00:22:55,620 when I was a VMware admin. Interesting. Okay. Yeah. I think, um, that, that sounds like it's more 200 00:22:55,620 --> 00:23:02,140 satisfying, but I don't, I don't want to assume or ascribe that. Uh, although I suppose I just did. 201 00:23:02,940 --> 00:23:09,240 I love it. I love it. Cause I, you know, when I, when I talk to even my team or when I find that, 202 00:23:09,340 --> 00:23:15,540 like, Hey, we have a new, uh, DevOps team who's using our cloud platform. Uh, and, you know, we, 203 00:23:15,620 --> 00:23:22,060 we asked them like, what do you do on the platform? Uh, and, you know, we, we had, you know, a few of our, 204 00:23:22,060 --> 00:23:29,080 our, uh, teams would come and say, well, Hey, this is related to, you know, uh, knowing the location 205 00:23:29,080 --> 00:23:35,100 or, or in case there is, you know, an emergency, we want to know stuff. And that is like such an 206 00:23:35,100 --> 00:23:39,840 eye opener. One, I'd not know there was a team that would actually do this. And now they're actually 207 00:23:39,840 --> 00:23:46,200 using our platform and I can see the benefit. Right. Um, that is super satisfying for me. And I, 208 00:23:46,440 --> 00:23:50,840 and I highly encourage, you know, if you are a, if you're a cloud engineer, you know, 209 00:23:50,840 --> 00:23:55,860 talk to your customers and know what they're doing and it makes your life so much easy to just 210 00:23:55,860 --> 00:24:01,540 explain and, and, uh, you know, be so happy about, you know, being part of like that contribution 211 00:24:01,540 --> 00:24:08,700 to the company. Would it be, would it be going too far to say that you should, um, have tea with 212 00:24:08,700 --> 00:24:18,180 your developers? Oh yes. The other piece that is still true is the tea time with your team because 213 00:24:18,180 --> 00:24:25,960 there's no team without tea. That is correct. And that along with the dial time and the introspection 214 00:24:25,960 --> 00:24:35,600 time still say, stay the same. Indeed. Okay. Um, all right. So that was kind of, that was really 215 00:24:35,600 --> 00:24:40,880 helpful to sort of think about how the day has changed, um, beyond just like, okay, here's, 216 00:24:41,040 --> 00:24:46,340 here's the routines and the rituals and some of the work. If you think about what are some of the 217 00:24:46,340 --> 00:24:54,520 things that have from your, from your vSphere and VMware admin days, what are the things that you've 218 00:24:54,520 --> 00:25:00,440 brought with you, whether there it's knowledge or skills or relationships, what sort of served you 219 00:25:00,440 --> 00:25:06,240 really well, not just then, but into this new role as a platform engineer? 220 00:25:08,520 --> 00:25:16,260 Uh, a lot of things for sure, you know, have helped. Um, and as much as, you know, there are two 221 00:25:16,260 --> 00:25:25,060 different titles, um, you just go back to, you know, I, I look at it as basics. If you have done it in 222 00:25:25,060 --> 00:25:30,900 one place, you will do it the same way, you know, in the other place as well. I can go through a few 223 00:25:30,900 --> 00:25:38,560 things just to give you a context of what are the things that I did as a VMware admin that still holds 224 00:25:38,560 --> 00:25:45,060 very much true when, when I'm like, you know, a cloud platform, um, engineer, right? Okay. 225 00:25:45,380 --> 00:25:53,560 Metrics and dashboard, right? If you created it for VMware, platforms are no different. The metrics 226 00:25:53,560 --> 00:25:59,200 that you have collected may be different, but the idea is the same. We just spoke about it. You need 227 00:25:59,200 --> 00:26:06,420 to know how well you are actually doing. If there is a problem, you need to know where it is 90% of 228 00:26:06,420 --> 00:26:11,320 the time. If you're going to be woken up in the middle of the night, you will just need to make sure 229 00:26:11,320 --> 00:26:17,480 you are looking at the right stuff. Right. And I say 90% because, you know, the 10% is always, 230 00:26:17,480 --> 00:26:24,140 um, like the ghost in the system, right? And you, and you will find it. And then you will be like, 231 00:26:24,220 --> 00:26:29,940 ah, this is another dashboard, you know, that I have to create. It is another metric that I have to be 232 00:26:29,940 --> 00:26:37,960 aware of, but still that 10%, you know, remains because it is a discovery phase. Um, but 90% of the 233 00:26:37,960 --> 00:26:43,900 time you have the data, you will look at the data. If you did it in VMware, platforms are no different. 234 00:26:44,120 --> 00:26:48,280 The metrics are different. They're the same. Yeah. Okay. That makes sense. 235 00:26:49,320 --> 00:26:56,820 Automation skills. If you have had automation skills, it don't matter whether it was like bash or 236 00:26:56,820 --> 00:27:02,340 Python, go, whatever it's useful. I don't think, you know, we will get into the merits of one language 237 00:27:02,340 --> 00:27:08,640 over the other. Um, as long as it makes your life easy. And if you have done automation, 238 00:27:09,240 --> 00:27:14,980 it is going to serve you well as the platform engineer. If you have used Ansible, you can adapt 239 00:27:14,980 --> 00:27:20,120 coming into the platform side because I think the mechanics are the same. The tooling might be 240 00:27:20,120 --> 00:27:27,560 different, but the mechanics are exactly the same. If you have used a CI CD tool like GoCD or Jenkins, 241 00:27:27,760 --> 00:27:35,540 it's 100% transferable to platforms. That is how, um, you know, developers work. It makes your life 242 00:27:35,540 --> 00:27:43,600 easy. It's much more relatable when, when you know some of these things. Okay. And then, oh, sorry, 243 00:27:43,680 --> 00:27:51,560 go ahead. No, go ahead. Well, you know, I, that jumps sort of to my next question, but it sounds like 244 00:27:51,560 --> 00:27:58,060 there's still more that, that kind of carries over. Absolutely. And, and I, I think there are a few 245 00:27:58,060 --> 00:28:02,580 things, right? Like, so it's very easy to look at the two titles and say they're completely separate. 246 00:28:02,580 --> 00:28:07,420 So we just spoke about like, you know, metrics and dashboard and the automation skills, um, 247 00:28:07,540 --> 00:28:14,900 configuration management, right? If you use GitHub, Bitpocket, like they, they, they're all super handy 248 00:28:14,900 --> 00:28:19,940 skills. As a matter of fact, this is very much, you know, useful because these are the tools that 249 00:28:19,940 --> 00:28:25,880 DevOps teams are using. And the more, you know, you are familiar with them, the more confident you are 250 00:28:25,880 --> 00:28:33,460 working with them and, and, and providing recommendations. Yeah. I mean, just to, to poke 251 00:28:33,460 --> 00:28:39,900 at the configuration, uh, management question, it also seems like, I mean, regardless of the specific 252 00:28:39,900 --> 00:28:46,440 tools, you mentioned a couple, but almost just like, I would imagine the principles of configuration 253 00:28:46,440 --> 00:28:53,580 management and, and, and sort of how you might track that separately from, um, other things, like, does 254 00:28:53,580 --> 00:29:01,240 that, is that also kind of applicable? Uh, yes, yes. And, and, you know, the idea is to make sure that, um, 255 00:29:01,300 --> 00:29:07,700 if you are on VMware, you know, you want to make sure you're applying a consistent profile to all your hosts. 256 00:29:07,700 --> 00:29:13,940 You have all the, all the configurations, you know, recorded in some fashion. If you're using VROPS 257 00:29:13,940 --> 00:29:21,980 orchestrator, um, you know, all of those things, you manage configuration so that you ensure consistency 258 00:29:21,980 --> 00:29:28,060 in the environment. The same idea on the platform and whether you're deploying an application, whether 259 00:29:28,060 --> 00:29:33,120 you're managing a platform, you want to make sure things are consistent, right? Whether you use like the 260 00:29:33,120 --> 00:29:39,600 mechanics, you know, and the tools may be different, but you know, the idea is exactly the same. So you 261 00:29:39,600 --> 00:29:45,320 can easily put, you know, like some of those things that you have done with the VMware side, you know, 262 00:29:45,320 --> 00:29:53,620 into the platform side. I think, I think learning itself is, is, is another, uh, big skill, right? 263 00:29:53,620 --> 00:30:00,000 And again, I don't want to focus on like the tools. It's just, um, innate things that you do 264 00:30:00,000 --> 00:30:06,360 because you are an admin of something and it, and it's your platforms, your baby. It's, it's your, 265 00:30:06,360 --> 00:30:13,120 uh, least your environment, right? Um, there is always something new to learn in VMware. They have new 266 00:30:13,120 --> 00:30:19,760 products, new features. It's a constant process of learning to keep up with the latest things. Um, it, 267 00:30:19,760 --> 00:30:25,440 it becomes like, if you've done this over a period of time, you do it just like you wake up and brush 268 00:30:25,440 --> 00:30:32,380 your teeth. It's as simple as that. On the platform side, it is exactly the same. What you learn may be 269 00:30:32,380 --> 00:30:40,340 different, but wanting to know, you know, having that thirst is, is super useful. Um, and not to forget 270 00:30:40,340 --> 00:30:48,060 the last piece that I have here is like people connections, right? This is the most crucial of 271 00:30:48,060 --> 00:30:55,580 skills that has served me, uh, across, you know, both the, the VMware side, as well as the platform 272 00:30:55,580 --> 00:31:01,020 side. In our day to day, I bet like most of our work gets done, you know, faster, not because of, 273 00:31:01,020 --> 00:31:07,340 you know, processes being efficient or automated or, or the fact that there is no red tape, but it, 274 00:31:07,340 --> 00:31:13,900 but it is because of the folks we talk to, you know, folks, we collaborate the folks where we help each 275 00:31:13,900 --> 00:31:21,420 other out, scratch each other's backs, um, put ourselves in someone else's shoes, being patient, 276 00:31:21,420 --> 00:31:27,340 listening, et cetera. You know, this will absolutely serve you well because now you are going to be 277 00:31:27,340 --> 00:31:34,060 working with a larger group of people, possibly, you know, spanning different countries. And, and it's 278 00:31:34,060 --> 00:31:39,820 very, very important to keep building those bridges. You know, when you, when you transition from a 279 00:31:39,820 --> 00:31:45,660 VMware admin into a cloud platform engineer. Yeah. That's, that's a, you know, there was 280 00:31:45,660 --> 00:31:49,900 something you said in there, like, you know, part of me is like, well, yes, of course the people 281 00:31:49,900 --> 00:31:54,940 connections, but you said something about, you know, things don't go faster because of some process 282 00:31:55,500 --> 00:32:01,260 improvement that goes faster because of, you know, just collaborating with people. And it makes me 283 00:32:01,260 --> 00:32:08,780 think about folks who like the, the sort of the big consultant sort of led process improvement 284 00:32:08,780 --> 00:32:14,860 engagement. That's kind of going through and looking into some extent, like, sure, it's good to sort of 285 00:32:14,860 --> 00:32:19,740 have a high level understanding of like, what is our process? Maybe there are some things broken, 286 00:32:19,740 --> 00:32:26,220 but I think there's also a risk, which you're, you're bringing to light with what you've described. 287 00:32:26,220 --> 00:32:31,900 There's also a risk of blaming the process and not then being willing to do the work. 288 00:32:31,900 --> 00:32:38,380 Uh, so, you know, sort of saying, ah, the process is broken. Um, but not then saying like, 289 00:32:38,380 --> 00:32:42,860 well, let me just pick up the phone and call that person. Let me set up some time to understand 290 00:32:43,580 --> 00:32:50,220 what they're trying to do, uh, so that we can kind of adjust how we're coming at this. And at the end 291 00:32:50,220 --> 00:32:55,420 of the day, that's actually how processes evolve. It's like, you can, you can bring in the big, 292 00:32:55,420 --> 00:33:02,460 expensive consultant or an individual can just take it upon themselves to reach out, reach across the 293 00:33:02,460 --> 00:33:09,500 aisle, if you will, and try to understand what someone else is dealing with. And so how can they 294 00:33:09,500 --> 00:33:15,820 work better together? Um, that that's a, that's a really great point. Um, that's just, you know, 295 00:33:15,820 --> 00:33:21,420 I think for everybody to take with them. Absolutely. There's nothing better than picking up the phone 296 00:33:21,420 --> 00:33:27,100 or having a call with somebody on Slack or, or whatever your mechanism might be. It solves it, 297 00:33:27,100 --> 00:33:32,620 the tones translate, you know, much better than an email or like an IM, right? 298 00:33:32,620 --> 00:33:39,180 Mm hmm. So, um, now let's kind of shift. This is the other side of that question, 299 00:33:39,740 --> 00:33:45,580 which is around what did you have to learn to become a cloud platform engineer? I mean, 300 00:33:45,580 --> 00:33:50,860 it's, you know, I think it was great that you called out just the process of learning and the 301 00:33:50,860 --> 00:33:56,860 habit and mindset of learning is something that you can carry from one, uh, one sort of role to the 302 00:33:56,860 --> 00:34:03,900 next. But what are those topics you, you touched on a number of specific say technologies, whether it's 303 00:34:03,900 --> 00:34:10,060 GitHub, Bitbucket, you know, CICD tooling. But what are the things that when you think about your own 304 00:34:10,060 --> 00:34:17,980 journey, what did you have to learn? Uh, what new skills, uh, knowledge did you have to pick up in 305 00:34:17,980 --> 00:34:24,700 your new role? Yeah, I, I became a cloud found cloud platform engineer because of cloud foundry. 306 00:34:24,700 --> 00:34:30,620 So I had to like learn cloud foundry, which itself is a big ecosystem and you know, how everything works 307 00:34:30,620 --> 00:34:39,100 within that piece, uh, closely related to cloud foundry is Bosch, uh, did a lot of that, uh, a bigger 308 00:34:39,100 --> 00:34:46,860 learning curve, uh, Docker, Kubernetes, uh, absolutely troubleshooting and advanced configurations of 309 00:34:46,860 --> 00:34:54,860 Linux. Very important. Uh, I think, I think a lot of open source tooling, uh, has, has really helped me. 310 00:34:54,860 --> 00:35:06,380 Um, influx, DBs, uh, Prometheus, Grafana, Telegraph, HA proxies, um, JQ. I love JQ. Uh, I, I think I'm an 311 00:35:06,380 --> 00:35:13,660 expert at it every time. Um, but then when I see Sergei writing a JQ one-liner, I'm blown, blown off, 312 00:35:13,660 --> 00:35:19,340 right? Like I, it's like, what, what have you written here? I have to like go and figure that out. Um, 313 00:35:19,340 --> 00:35:25,340 certainly, uh, public cloud, uh, cause you want to have your platforms portable across, you know, 314 00:35:25,340 --> 00:35:35,660 different clouds. So, uh, AWS, uh, latest, uh, movement is towards Azure. Um, and also that as my 315 00:35:35,660 --> 00:35:40,380 friend, like James says, you know, there are many ways to learn all of this and everyone learns very 316 00:35:40,380 --> 00:35:47,740 differently. I have learned all of these by doing, you know, watching videos, reading, et cetera. Um, 317 00:35:47,740 --> 00:35:52,540 and I, I mentioned this early on, you know, a lot of vanguards who have gone through very 318 00:35:52,540 --> 00:35:58,220 similar paths of progression. And as much as, you know, I, I rattled off, you know, a whole bunch of 319 00:35:58,220 --> 00:36:06,620 things, uh, I think it's impossible, impossible to be fully proficient and an expert in all of these 320 00:36:06,620 --> 00:36:14,780 technologies. It's just a continuous learning process. Uh, definitely need to need, need to make sure, 321 00:36:14,780 --> 00:36:20,940 you know, there's a lot more patience and a lot more empathy, I would say, um, very important to put 322 00:36:20,940 --> 00:36:27,180 yourself in, uh, other shoes, uh, as an individual, there are things that I learned, you know, that we 323 00:36:27,180 --> 00:36:35,580 all need help along the way. Yeah. There are many, many times when, you know, DevOps teams have helped me 324 00:36:35,580 --> 00:36:42,060 learn something new, uh, see things, you know, in a different light when I was wrong. And my teammates, 325 00:36:42,060 --> 00:36:46,140 you know, certainly, you know, have paired with me during days and nights, you know, when I was new, 326 00:36:46,140 --> 00:36:51,500 um, my leadership, uh, team, you know, for sure have allowed me, you know, a lot of bandwidth. 327 00:36:52,140 --> 00:36:59,580 Uh, I remember I started learning AWS, uh, and I had like execute a project and it took me six weeks. 328 00:36:59,820 --> 00:37:08,300 Um, and, and, and I remember going at every sprint and saying, I'm still working on it. And I also 329 00:37:08,300 --> 00:37:14,460 wondered why they hadn't fired me yet. Um, so certainly, you know, during those times, there 330 00:37:14,460 --> 00:37:19,660 were folks who had reached out to me and asked me, Hey, like, do you need some help? Uh, can we, 331 00:37:19,660 --> 00:37:26,300 you know, have a session together, you know, very important. And, um, they've given me positive 332 00:37:26,300 --> 00:37:31,420 feedback, constructive criticism when needed. Uh, and, and, and especially I would say, you know, 333 00:37:31,420 --> 00:37:39,740 my, my leaders have been, um, pushing me, you know, to avoid being satisfied with just average. 334 00:37:40,220 --> 00:37:45,980 Right. Um, so this is, this is, uh, you know, part of the learning process for everybody is that it's 335 00:37:45,980 --> 00:37:54,300 not an individual thing, right? It is a collection of, um, how your teammates, your managers, your 336 00:37:54,300 --> 00:37:59,740 leadership and your company as well. Like, you know, Comcast as a company encourages all of us to pursue 337 00:37:59,740 --> 00:38:06,300 things that interest us. Right. Even if it may be outside your organization, you have the bandwidth 338 00:38:06,300 --> 00:38:12,860 to go and be part of another team for six months, be part of projects for other teams. If you like to 339 00:38:12,860 --> 00:38:18,860 switch within the organization, there are a lot of things that everybody has to do. And, and all of 340 00:38:18,860 --> 00:38:26,700 these things definitely, you know, help. Yeah. I, you know, and it's, I think this is really valuable 341 00:38:26,700 --> 00:38:35,820 for a lot of folks out there who are, you know, vSphere admins and, and VMware infrastructure admins 342 00:38:35,820 --> 00:38:44,300 today and whether they, they currently aspire to working with, um, uh, sort of some of these other 343 00:38:44,300 --> 00:38:52,060 ecosystems of platform technologies, or these things are kind of coming at them. Um, anyways, 344 00:38:52,060 --> 00:38:59,020 with things like Kubernetes now getting baked into vSphere seven, um, you know, powered by, 345 00:38:59,020 --> 00:39:04,380 by TKG tongue, Tansu Kubernetes grid, you know, it's going to be a journey. So I think, 346 00:39:04,380 --> 00:39:11,260 you know, what you've shared today has been really, um, I think very helpful. I wasn't exactly sure what 347 00:39:11,260 --> 00:39:16,860 it was going to, what you were going to say in terms of how big of a leap, but I really like all 348 00:39:16,860 --> 00:39:24,700 all the things that have connected you through the work that you've done before as a VMware infrastructure 349 00:39:24,700 --> 00:39:32,860 admin into being a, a, a platform engineer. And that learning culture seems to be a really big, 350 00:39:32,860 --> 00:39:39,340 important part of that. I have one more question for you, which is that, you know, now you're five 351 00:39:39,340 --> 00:39:47,580 plus years in on the platform team, you're managing a team. Um, but if you were to go back and make that 352 00:39:47,580 --> 00:39:52,780 transition again, would you do anything differently? And what would that be? 353 00:39:52,780 --> 00:40:03,180 Absolutely. Um, there are like, if you are a VMware admin, right? I would say you have already mastered a 354 00:40:03,180 --> 00:40:09,580 very complex system that is used by millions of companies around the world. It connects to various 355 00:40:09,580 --> 00:40:16,620 system routers, networking, hardware, you name it. You've got technology, right? And you understand 356 00:40:16,620 --> 00:40:23,340 technology, technology comes easy for you and, and cloud form platforms is just another technology, 357 00:40:24,060 --> 00:40:30,700 right? Personally, for me, in retrospective, uh, I think back to when I started up, started my career 358 00:40:30,700 --> 00:40:37,180 off, uh, I wanted to learn everything, right? I have some engineer ones on my team today and I can see 359 00:40:37,180 --> 00:40:45,180 that curiosity to learn. And as I have switched many positions, you would think that, you know, change 360 00:40:45,180 --> 00:40:55,340 is normal for me. Um, and I've seen change and it's not normal. It's uneasy, but you have to go back 361 00:40:55,340 --> 00:41:01,500 and reflect on similar situations and know that you have like a support system. You're, uh, I like to 362 00:41:01,500 --> 00:41:07,580 call it the work family that you can rely on to get you there. Uh, for me, when I made the transition, 363 00:41:07,580 --> 00:41:14,940 uh, from VMware to cloud platform engineer, it was difficult. And I've always thought 364 00:41:14,940 --> 00:41:21,020 about this and I think it's because it chose me and I did not choose it. Like I knew that I wanted 365 00:41:21,020 --> 00:41:26,860 to do all the other stuff that I transitioned to, but cloud platforms just showed up and you know, 366 00:41:26,860 --> 00:41:34,140 it was like, okay, you're here. Right. Um, I, I have a story where I distinctly remember, um, I was 367 00:41:34,140 --> 00:41:40,380 adapting, you know, very slowly, uh, or I would say slower than usual, uh, to becoming a platform 368 00:41:40,380 --> 00:41:46,220 engineer. And we had only like three platform engineers, literally Tim, Sergei, and myself. 369 00:41:46,220 --> 00:41:51,420 And one day, you know, Tim and Sergei were off and I had to like be in the driver's seat during a huge 370 00:41:51,420 --> 00:41:59,100 outage. Um, and as I managed, I just managed to eek through the outage and, and have band-aid 371 00:41:59,100 --> 00:42:05,500 solutions. Right. And that was an eye opener for me and I knew I needed help. Right. So I would say that 372 00:42:05,500 --> 00:42:13,340 the biggest takeaway for me would be, um, leaning in, right. It's, it's difficult, it's uneasy, 373 00:42:13,340 --> 00:42:19,100 but you need to talk to your, you know, teammates, um, make sure you talk to management because, 374 00:42:19,100 --> 00:42:24,140 you know, we're all humans and we all need the help, the training, whatever is required to learn, 375 00:42:24,140 --> 00:42:31,020 you know, to get ourselves, you know, faster into, uh, get more easily adapted. I would say not 376 00:42:31,020 --> 00:42:38,540 faster, uh, but just knowing that you have, you're given the benefit, you have the backing of your 377 00:42:38,540 --> 00:42:44,860 leadership, I think is super helpful. And I would say that is one thing that I would lean and go going 378 00:42:44,860 --> 00:42:52,620 from like a V VMware admin, you know, into a cloud platform engineer. But I also think now that I've 379 00:42:52,620 --> 00:42:59,180 worked in this environment for about like five years, I think it's, I also see one of the things 380 00:42:59,180 --> 00:43:05,420 that I would have done as a vSphere admin differently, right? Like based on like all these 381 00:43:05,420 --> 00:43:11,420 learnings, I, I could have done this there, uh, or things that, you know, I, I kind of reflect on, 382 00:43:11,980 --> 00:43:17,340 um, you know, some of the things that I really love about what we do on the cloud, cloud platform side 383 00:43:17,340 --> 00:43:24,300 is that transparency, right? Like everything, all the metrics that we use to make decisions on the 384 00:43:24,300 --> 00:43:31,740 platform are available for our customers, right? I, I really think we could use, at least during my 385 00:43:31,740 --> 00:43:37,900 time, you know, we could have used some of that transparency, you know, in, uh, management of our 386 00:43:37,900 --> 00:43:45,900 VMware infrastructure, um, establishing trust, the way we communicate with our DevOps teams 387 00:43:45,900 --> 00:43:51,340 are really different when you come to the cloud, cloud platform side that I think, you know, we can 388 00:43:51,340 --> 00:43:56,700 absolutely, anybody who's done this before can look at it and say, yes, we can do that on the 389 00:43:56,700 --> 00:44:02,380 VMware side as well. So I've, I've kind of like walked both sides of the aisle and I can see things I would 390 00:44:02,380 --> 00:44:10,620 have done differently, you know, uh, fight to swap either way. Yeah. That's interesting to think, um, 391 00:44:10,620 --> 00:44:19,180 especially as you know, it, it might be too early to say, but are these, uh, are these roles going to start 392 00:44:19,180 --> 00:44:27,900 to blend and merge more? And, uh, in your case, it kind of took, there had to be a separate platform 393 00:44:27,900 --> 00:44:34,620 team, um, and you were brought over into it. It chose you, as you said. Um, and that kind of made 394 00:44:34,620 --> 00:44:44,060 this sort of hard, hard transition, but you know, maybe as the technologies become more broadly embedded 395 00:44:44,060 --> 00:44:52,620 and the practices, uh, start to just become better understood to your point, maybe there's things where 396 00:44:52,620 --> 00:45:01,100 the, the VMware, um, infrastructure teams can start to evolve towards that, that platform cloud engineer, 397 00:45:01,100 --> 00:45:08,620 uh, operating model, uh, without really changing teams. And that just sort of becomes part of their job. 398 00:45:08,620 --> 00:45:13,580 So it's, you know, I'm not going to put, you know, hard dollars against that. Cause it's, 399 00:45:13,580 --> 00:45:19,740 it's a bit speculative, but I would, I would put some money on it. Uh, if I, I would absolutely put 400 00:45:19,740 --> 00:45:25,180 some money on it. How many pounds of tea would you put against that? Uh, I, well, I, I cannot go out 401 00:45:25,180 --> 00:45:31,180 and have tea with my team. So I would say not anything, not, I would not put any kind of tea on it, 402 00:45:31,180 --> 00:45:38,220 but you know, technologies are merging, right? And, and I think the delineation of infrastructure 403 00:45:38,220 --> 00:45:44,860 and platforms, you know, are, are, is a certainly evolving thing. And, uh, you know, with certainly, 404 00:45:44,860 --> 00:45:50,940 you know, some of the Tanzu, uh, grid VMware, pivotal merger, et cetera, you know, you can, 405 00:45:50,940 --> 00:45:56,300 you can see that happening. And, you know, the most important thing, you know, if I had to tell 406 00:45:56,300 --> 00:46:03,020 somebody who was in either boat is to know that everybody has apprehension, right? Like everybody, 407 00:46:03,020 --> 00:46:10,060 you know, is fearful of change. Um, even for me who has seen a lot of it, it is difficult, 408 00:46:10,060 --> 00:46:16,140 right? But always trust that, you know, uh, everybody's there to help. Um, you know, 409 00:46:16,140 --> 00:46:21,660 you have done this for a long time. This is just another new technology that you are going to 410 00:46:21,660 --> 00:46:27,340 have as part of your skillset. You know, it's, uh, it's something that we all will have to work 411 00:46:27,340 --> 00:46:31,980 together. All right. Well, Neville, this has been fantastic. I think it should be required 412 00:46:31,980 --> 00:46:36,540 listening for, I mean, I'm biased of course, but I think it should be required listening for, 413 00:46:37,260 --> 00:46:45,260 for every, uh, vSphere admin out there. Um, and so I, I thank you for taking the time and sharing your 414 00:46:45,820 --> 00:46:50,780 experience and wisdom, uh, with the, the Tanzu talk community. 415 00:46:50,780 --> 00:46:56,300 Fantastic. Thank you. The pleasure is all mine, Dormain, and thanks for being a sport. Have some tea. 416 00:46:57,500 --> 00:47:07,740 Oh, I will do just that. All right. Have a great one.