Platform Engineer: What’s Old is New Again

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to the first CTO Advisor new podcast of the year. I have a returning guest, Nathan Avery. Nathan, welcome back to the show. Thanks, it's good to be here. Yeah, yeah, it's been a while. What was I don't even remember the last topic. First, Nathan, you're product manager at Google, correct? Yeah, specifically, I'm an outbound product manager, so I'm a little more outward facing, I deal a little bit more with customers. But a lot of the same ideas, right?

We work with the engineers and the product team to try and enhance our products however we can. And we're not here talking about Google Cloud specifically or even AI. We're just talking pre-show banter, how everything has to be AI related. I'm sure we get some AI into this conversation because it is the elephant in the room. But we're talking platform engineering. You tweeted something the other day. I think you were the one that tweeted me the initial conversation that got me interested in.

But what happened to the good old fashion platform engineering where we packaged things in VMs and our whole CI, or more like CI, was focused around the packaged VM. Is what's old, new again? I'm starting to feel that way. You know, we have a tendency in tech to just relabel things, you know, and I feel fortunate enough to have been around long enough where I can start to spot this sort of thing. Now, there are, of course, to it so that there's a legit reason to rename it.

But. Yeah, so it is very similar, you know. And I think about this as we have customers making that cloud migration because there are still tons of people making a cloud migration and they're used to working with VMs and they know that workflow. They know that they can build a VM, get their app installed on it, you know, use whatever packaging tool that they're used to to, you know, build that VM template and then just stamp it out whenever they need. And for a while, you even work that into a CI workflow, you know, where you put your code in your repo and then it dumps it down onto the VM.

You know, I think you would package the VM and stamp it out. Yeah, you talked about this. This was kind of your early days, right? Your earlier days where you would create the scripts to package the VM. So if you're not familiar about how we used to do this in the olden days and the olden days were what, 15 years ago, I don't even know if it was that old. But yeah, it doesn't seem that old. But basically there's this concept developers are not going to take their code packages into a VM and then send the VM to ops to deploy.

Developers always, always just wanted to write code. It was the job of operations to then deploy the code, whatever that meant, whether we're talking about mainframes, VMs, bare metal. There needed to be a process to go from code to deployment. And this is a problem we've been chasing in the enterprise forever, right? Yeah, yeah. And to be fair, when we were dealing with strictly on-prem, there was a lot of stuff to know, right? I mean, you'd have to worry about how your networking configuration was set up.

Maybe developers never even had access to those machines. They may not have even known what those machines were, like in terms of course, our or anything, right? They just knew, hey, maybe I need a JDK on it or whatever other libraries they needed to make the code run. And we lived like that for a long time. And as an ops team, you know, again, with the VMs, we also had like vSwitches and templates and things like that. And we knew how to drop a VM into the network and give everyone access that they needed along with your storage, right?

And now we get to cloud and we have more options, right? Yeah, you can still work with VMs. But, you know, I was kind of thinking about this, like because that quick tangent. I want to see maybe it was Furrier who tweeted out that he thought that the Broadcom might take VMware, like VMware on AWS and remove that product, right? The product might go away. I was thinking, well, yeah, I don't know if you need to extend the VMware control plane anymore, like into the cloud.

It felt like a really cool idea back in, like, I don't know, 2010, but the control plane in the cloud now, they're pretty good, right? You don't necessarily need to do those things that you, you know, you're aware. And I don't know if this is a I don't know if this is actually a tangent. I think this becomes kind of the core question. Ironically, VMware just announced yesterday, the yesterday of this recording, that they are taking ARIA, their orchestration observation platform, and making that available basically via package software only, which seems counterintuitive.

But the point is ARIA and the management control plane can now basically orchestrate the things that you need to orchestrate. But I think there are some fundamental challenges with, I think VMware cloud on AWS or the VMware cloud in Google or Azure allowed you to have a consistent way to manage bare metal, because I think the the the point of all of these services, that if you need to run VMs, the best way to run VMs in the cloud is on bare metal. And then you have the you can oversubscribe the bare metal, et cetera.

So I think you can it'll take some work, but I think you can do this with our ARIA and the VMware control plane. And generally speaking, but going back up to kind of the the core of the conversation, which is CI CD, the friction has always been how do I consume that bare metal in an efficient way and make the code deployment as frictionless as possible for the developer? I don't know if it's I don't I can't say that it's become frictionless, frictionless for the operator.

Because I think we're the operator and both of us have operations background. I think the I think what's what's happening is more of just being asked of the operator. Does that make sense? But, you know, back then, you know, we had to do more low level work, you know, making sure to your point, the network was configured. VLANs were available. All this nonsense that we don't have to worry about in the area of cloud. But it seems like the surface area is just much bigger now.

Yeah, it really is, although I would say that we still have to worry about the networking and all of that stuff. I mean, ops folks will never get away from having to understand those core mechanics, right? You know, hey, how much storage are we provisioning, networking, et cetera. But. What it feels like we're being asked to do now is to provide additional layers of obfuscation for the developer so that, like I say, the developer can just worry about the code, right?

If I write my code, if I know my code can run, I'll put it in this, you know, magic bucket and then it will show up, you know, running state, you know, in the cloud somewhere. So ironically, that's always been the goal, right? Is that the developer puts the code in a bucket and then ops folks make it possible for the code to get into production. So this is actually not a conversation around developers, but a conversation around ops in the platform engineering.

And I think platform teams is not necessarily about developer experience anymore. And I know that was a lot of the buzz two years ago. I think so kind of is. Well, I think it's from developer experience in the sense of the goal has always been developed to be to just write code and they hit goal. And there's some magic process, whether that process is a bunch of engineers with wrenches going around and and, you know, choosing lawns and an EMC storage array or develop or creating abstractions.

And we're just, you know, provisioning object storage in the background, whatever that case is. The goal has always been for developers to simply write code and for operations to make that as invisible as possible. Oh, yeah. Yeah. And it's kind of wild how we get there. And, you know, the old days, you know, we were talking about scripting. Maybe you wrote a script to copy some files around from one machine to another, you know, wherever the code may have happened to been.

And we're kind of right back at that, or maybe we never really left it, I guess, is the point of this. You know, now what we have is a need to actually have more advanced scripting knowledge, you know, to build these developer portals and things like that. And, you know, it's interesting how everything kind of comes back. But other than that brief moment there where we had developers and Ops folks kind of working together, you know, and we had some, you know, maybe some devs would actually be on call and have to live that ops life for a little bit.

It feels like that's being. Potentially moved away, but I think we're just refining it a bit because I can still see DevOps teams working in this new world with developer portals. But those DevOps teams would probably be more more specific to an application that they manage themselves. Right. So I guess this has me asking the question as you're talking about kind of the how closely the developer is to like the application or set of applications. And we can talk about how speaking of tangent, we can talk about how an enterprise.

Developers don't map cleanly to environments, so they may support multiple architectures and applications because one app, their support is a cloud native app written in Python. It can be a cloud native app written in Python. And another app is a app that runs on prem, also written in Python. Yeah. So they they may have different, you know, go to production workflows for the apps. And the ideal platform teams is to make that simpler. And one of the things that we haven't talked about as you were talking about, why is this a problem or what problem we're trying to solve if at the end of the day we're.

Aiming to make sure the developers all they have to do, whether they're talking about on prem code or code in the cloud, that they write development, they write the app, write an update to the app, push it, and then there is a platform team that takes it. I think the the question to you is, what problem are we trying to solve for the developer and for the operations team as we continue to modify this and modernize the process? Yeah, so yeah, what's interesting is I don't know if we're really trying to solve a problem so much for the ops team or the dev so much as for the business itself, because what we're looking at doing is how do we increase velocity?

How do we get those features out there that are, you know, turn the tide and make my my online e-commerce store more effective? You know, how do I enhance and enhance the experience for my end users? Right. How do I delight my customers? That's really what every business wants to know. And so if we can get code from, you know, the thought to production in a like an A-B test situation, OK, well, now we can start to experiment more and we can start to see where we can in where we can make things better for folks.

I think that's really what it is. And so how do you do that? Well, you know, getting back to what are we solving for in terms of the developer and to a certain degree, the ops, how do we lower the cognitive load on them so that they don't have to worry about lungs and VLANs and do I have to create a new one or anything like that? You know, do I have a ratio of the DNS? No, it's developers can do the thing that they do, which is to write the code.

In fact, what we're starting to see now with a lot of the DevOps is. There's this idea of. You know, we used to do the shift left, right, where we're like, hey, you know what, if we give more info to the dev and it, for instance, were like security, then they'll be able to fix it there in code and then we'll have a clean deployment. Well, but that still puts cognitive load on the devs, right? Because now they have to not just worry about their code, but they have to worry about the security.

And, you know, my goodness, am I using a library that might complicate it or compromise? So you shift that down into the platform itself so that. Hopefully anything that like that can be detected earlier at a different level so that you can still keep your devs writing, writing the code, generating those functions and features that are going to benefit the business, and then we can say, oh, you know what? You know, I know it's around CI. Oh, hey, here's a here's something we need to fix and we can still have a fast feedback loop back to the developer that says we've noticed this error or we've noticed this library you're using, you know, should be a different version.

Let them make that change. Let them test it locally. They'll let them build it and, you know, their test environment and make sure everything's good and valid. And then you go live because ultimately, again, you want to go live with. You know, an environment is going to make folks happy, right? We still know that we have CISOs out there and, you know, security folks. And fortunately from DevSecOps, we started moving those security folks into the process. And so now we take as many of those practices as we can, build them into the process overall.

And again, it's for velocity. You know, you don't want that security guy at the end saying, whoa, stop. You know, I need to scan all this before you go live because it's been built into the process. Yeah. So you're hitting, I think, on the key point, this ability to go faster. And what's hindered us in the past is this feedback loop. You know, again, walking back from history, from bare metal servers to VMs into cloud, where the friction came in was when developers threw over the code, again, the goal had always been for developers to simply write code and deploy the code without, you know, needing to know low level or engage in low level system details.

The operators typically did all of that work. The challenge for the operators was creating a feedback loop and shorting that feedback loop. You know, in bare metal, the code would get written. And then two months later it would be deployed. I'm not exaggerating, you know. And that would be fast. Yeah, that would be fast. I'm being generous. VMs shorten that with correct configuration management and CI to a month, maybe even two weeks. Whereas the business to ask is, is that a CEO or CMO, some line of business looks at the website and says, hmm, I wonder what would happen if we changed the color of this widget to a different color?

And IT responded, well, we can do that and get an answer for you in three weeks. That's unacceptable in today's landscape. And what we needed to do, the problem that we're solving for is this shortening of feedback loop. And this is where modern CI, CD cloud native technologies have picking up the ability to get that feedback. So you get to talk to developers in your role. Do you talk to both infrastructure developers and business logic developers, or is it, you know, one or the other?

It's a mix. You know, you've had a lot of these conversations with customers, too, where sometimes you you never quite know who you're going to get in the room and, you know, because every organization is a little bit different. Sometimes, you know, sometimes their developers are very much involved in everything that happens, kind of not just from a code perspective, but also from, you know, a CI, CD perspective or infrastructure. Or sometimes they're just kind of, you know. They're not totally involved, they're kind of off on the side, and those decisions are left to an internal, you know, centrally controlled IT organization.

So there's a mix. So as they engage with you and your role as a PM, like what are their pain points today? Like the I think we have this notion because there's a lot of data no matter where you're at in your journey, you look at the data and the research and the marketing materials and people say, well, CI, CD is Sol. So where are the pain points for developer environments and CI, CD today? Oh, so, you know, that's that's a really interesting thing I've noticed in a lot of these platform discussions is everyone wants to build their their IDP, you know, their developer portal that then would make it easier to automate things.

But they've not actually taken the time to automate the things first, you know, that would be cool. You know, we've just kind of jumped over that. It's like, oh, wait a minute. Let's let's make sure your CI, CD is actually Sol. And a lot of folks are having to revisit that. And kind of like, you know, you were saying at the very start of this, you know, we'll get into a little bit of AI because. A lot of times the major pain points we hear from folks tend to be about speed, maybe the speed of the compiles, the speed of the bills, that sort of thing.

You may also hear about when something doesn't work. How do I find out what that was? How do I understand this error message in like plain English? Because there could be a million things that potentially could go wrong. And you have both your ops team and your developer team looking at these messages and interpreting them, you know, maybe with their own lens. Well, if we can use, you know, AI to look at that and help us do that, that interpretation and provide it because AI is great at summaries.

You know, maybe we can. Put more and better information in front of the folks, again, to speed up that that feedback loop and to keep the velocity moving as fast as we can. So that that is a good question around or a good point around automation. I've done enough automation projects to realize that people haven't even documented their process to be able to automate their process. So they kind of jump to that next level. And the promise of automation gets.

Delayed or not fulfilled because people haven't realized they haven't done the low level work yet to even leverage or create the automations is their opportunity for AI to help with kind of this this business analyst role and business discovery role and process discovery role to speed up the the the steps to automation. Um, yes, yes, there is. I. is magical, but it'll build all the stuff for you when really what it will help you do is to get to those ideas faster.

Right. You know, you can prompt it with a suggestion, you know, hey, what would be the best way for me to deploy this? This container, you know, and then you're like, hey, I mean, come back with go serverless or me come back with, hey, you know, use Cooper days. Those are sorts of things that. We think a I or at least I think I'm going to take just these are my own personal views where I can make the best case for a person to choose, you know, route A or route B, right, because a lot of times we're making up those designs that we're kicking through these ideas.

You can spend a lot of time in research and then maybe you're even trying to play through ideas and it gives you a dead end. Well, man, I'd love to be able to just sort of ask that as my assistant here, what they think about it and and go from there, you know, as well as like things, things like, hey, what's the what's the command for this? You know, some of you still have to do a lot of automation with commands and, you know, no one really remembers all the switches.

Yeah, and I think this is the overall trend of the industry, whether we're talking about AI driven tools or your product. Now, get you a chance to pitch what you manage at Google Cloud. But the idea is to have to, you know, you remember those interviews earlier in your career and someone actually. Well, what's the the what's the LS switch to sort, you know, your directory structure by, you know, by extensions or with, you know, some wildcard in and like, I don't know, there's something I would Google.

Why are you asking me this? You know, our team switch when in practice, I'll just Google it. And now we're getting to the point where, you know, this is something that I'll just ask the AI so that I can focus on my core value, which is the logic with that said, the last couple of minutes. Now, what product do you or products do you manage at Google Cloud? Now, OK, the group I'm in, the product group is a dev to prod.

So it's that getting the code into the the machine through their IDE. And that's cloud workstations and cloud workstations now has duet in it so that the. You know, again, there's an assistant right there to help the developers get through their code faster, help them create tests, all those sorts of things. And then it's also our CICD suite. So that's cloud build for CI cloud deploy for deployment artifact registry, which stores all of your containers and other artifacts and artifact analysis, which provides vulnerability scanning and information back about the safety of your tools.

You are sorry, the safety of what's been uploaded. So if folks want to learn more about these products, you know, Google Cloud's page is pretty robust, how do they how do they find out more? Oh, I guess you can look up CICD, you know, for Google products. You can also, you know, a lot of us are now on Twitter, including me. And it'll be Nathaniel underscore Avery. And if you go to mine, you'll see all the sort of things there.

We've started compiling more and more of our information also on YouTube. So you could go to Google Cloud Tech, the Google Cloud Tech channel on YouTube, and you'll find all sorts of videos, not just about our CICD products, but about other products as well within the Google Google Cloud infrastructure. And I think that's probably the best way to do it. com. There's not a lot of CTO Advisor stuff there yet, but I'm sure will be in the future. com at CTO Advisor.

Until then, talk to you next CTO Advisor podcast. Thanks. Thanks, Nate. Yeah, thank you.