Application Modernization at Google Scale

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

Hey, as you can tell by the b-roll, we're in beautiful New York City at the Google campus. It is a pretty cool spot. It's a speakeasy behind closed doors, one of the more interesting corporate spots. That's if you're watching this on video. If you're not watching it on video and this is a podcast, well, imagine a really cool speakeasy inside of a corporate office and you'll get a description of the Google office here in New York. One of three. So, joined with me is familiar face Bobby Allen, outbound product management at Google Cloud.

Bobby, welcome back. Thank you. Thank you. And Stephen O'Bain, who's relatively new to Google, VP of Migrations. Stephen, give us a little bit of your background. Yeah, happy to do that, Keith. Thanks for having us, first of all. It's a pleasure to be recording this with you. Always appreciate spending time with you. So, yeah, Stephen O'Bain, I joined Google eight months ago to help us build a world-class migration discipline to really help our customers who are interested in moving large-scale migrations.

So think dozens, hundreds, thousands of applications or multiple data centers at the same time at one time. And while I'm new to Google, I'm not new to the cloud. I spent the last eight years before this at AWS in a variety of roles, building their migration strategy and their migration program, starting the data exchange and running their marketplace and ISV partnerships. Prior to that, I was a CIO at Dow Jones for a couple of years, leading a large-scale digital transformation, as everybody calls it now.

We didn't have that buzzword yet, so we called it something else then. But it was a big talent transformation, hiring lots of engineers and product managers, and then a big, large move to the cloud as well. We moved 75% of our infrastructure to the cloud and went from just a couple software releases a year to hundreds a week by the time I left, and yielded about $100 million in savings doing that. So huge transformation. And then prior to that, I spent 11 years at Bloomberg, building a bunch of cloud-based analytics for financial services professionals and professional sports teams.

So we love having folks who work on the vendor side of the equation, who have years of customer side experience. You're bringing all of the, I want to say experience, but it's more like pain. You're bringing all of that pain forward and sharing. So when you're in a conversation with customers, you can have that shared journey, knowing what it's like to have in mind a theory of where you will, or vision of how you want to get to somewhere, and just knowing all of the non-technical issues that stop us from getting there, the technical and non-technical.

So this is going to be a follow-on conversation, and if you've followed the CTO Advisor for any period of time, you know we did a piece of sponsored research with Google in which we took their migration tools, the tools, projects that Bobby leads, so Bobby, don't take this personal. I know you and your team work really hard at it, and saying, what can we do with these migration tools? Can we take our landscape of applications and simply do an assessment and automated migration?

Vis-a-vis kind of what we did with data center migrations. Is it that easy? The answer to that question was no, it's not that easy. While the tools are great and they give us fabulous insights, they're the reason, Steven, you came aboard, is to get us beyond the tooling. Can you talk about RAMP and how we're using processes and people to implement the technologies that Bobby's teams are leading? Yeah, certainly. Happy to do that. You certainly can't discount the tooling.

Having automation to be able to assess what's in a large-scale IT environment across multiple data centers, if that's what the case, disposition different applications, understanding what the right way for them to move from a technical perspective so that it can be automated and done swiftly, and then running and operating them on a responsible, secure, resilient basis is super important. The tools are a super important aspect of the work. When you think about a big enterprise, or even a medium-sized enterprise, where they might have dozens, hundreds, thousands of applications that have been built over, in some cases, decades, if not more, those applications in that IT environment is run by people who, in many cases, have been used to doing their roles a particular way for a very long time.

I've talked to more than 1,000 enterprises over the course of the past decade about their move to the cloud, and they all say something like, I'd really like to be 75% of the way migrated over the course of the next three to five years, but I really need help evolving my culture with that actual technical move to the cloud. As you said, being kind of both on the customer side and the inventor side, I would summarize it as experience is the most brutal of life's teachers.

I've learned the hard way that overlooking some of the people and process changes is really what ends up getting in customers' way. What we're trying to do with RAMP, the Rapid Migration Program, is really take a lot of the migration programs and capabilities that Google has had long before I got here. We've had a number of different programs to help with various parts of a migration, but they were all loosely coupled. We're trying to take the best of all of those different programs, approaches, methodologies, and tools, and then make sure that we get them all together into one unified and holistic approach where we also land a number of best practices, which I think I'll talk about in maybe a subsequent question, into an engagement that we can bring to our customers and that we can enable our system integrator partners to use the best of our approaches in RAMP as well to bring to their customers to make sure that the customer is not just taking a look at their technology and how to migrate and, in many cases, modernize it along the way, but make sure that they have a good business case for it, that they're upskilling their teams, that they're organizing themselves in the right way, that they have really good goals set out, and that we can govern those migrations on a regular basis with them.

So let's talk about what worked really well with the assessment tools, Bobby. What surprised me was the ability for the assessment tools to even identify Windows workloads and how we can take a Windows workload and basically containerize it. I was not expecting that type of capability. I was mainly, you know, as I look at my portfolio and I have some LAMP stuff, I have some NGINX stuff, I was expecting it to be able to take the LAMP stuff and say, oh, here's how we can take this application and put the web server on a Google Cloud-based serverless platform.

We can take the code and run it in a container, kind of deconstructing the LAMP stack. And then, you know, just the MySQL stuff moving to a cloud-based Oracle database. It actually went one step above that and took my Windows IIS app and said, you can deconstruct this IIS app. Where has the standard in the technology moved almost a year later? So first, let me just kind of acknowledge a little bit of the elephant in the room. Windows containers is probably as polarizing as Ohio State versus Michigan.

You don't land on both sides of that issue. I'm a Michigan guy, so go blue, so you know which side I land on. But, again, Windows containers is very controversial in the enterprise. Having said that, to your point, if you are open to containerizing Windows, we have tooling that can absolutely do that, Linux as well. But I think the bigger principle is we've evolved the tooling because we needed to put the tooling closer to the people that are doing the applications.

A lot of our tooling before, Keith, was really aligned more to IT administrators. And the challenge is I've got a – my mother-in-law is a great cook. She makes the seafood salad that's amazing, but she's allergic to seafood. And it usually doesn't work out well when you can't taste what you're cooking. And so IT administrators trying to modernize applications they have no purview over really didn't work that well. So we've kind of taken the tooling and evolved it to push it down to the application developer level.

So on a development machine from an IDE, you can assess an application and containerize it and actually push it into a containerized cluster right there. So just, again, people that can taste the food, Keith, are going to make the food taste a lot better in the end. So that's part of what we've evolved. We've also partnered with – again, Steve is kind of my partner-in-crime because he's wrapped the other things around the governance, the decisioning – hopefully we'll come back later, too.

I've got a real estate story that I think will help tie this together. But we need more than the tooling. What I think we've found is that the average customer is not willing and able to change as much as they want, so we've got to put the support around them to help them achieve the outcomes that they're looking for. So, Bobby, I love your analogies, the most famous of which on our program is the whole going to the beach, eating chicken doesn't get you a beach body.

I love that. I love that analogy. And we'll come back to your real estate analogy. But, Stephen, I want to kind of go back to you and piggyback on what Bobby is saying. The product – the migration products have changed as a reaction to the market and seeing what's happening with people inside of organizations. Developers are going to be the best resource for modernizing their application because they understand the application, they understand they're closer to the business. So talk to me about this rent process for best practices for kind of gearing my entire organization from developers to architects to operations and security around the journey of modernizing my operations for the public cloud.

Yeah. Happy to do that. So, like I was sort of painting before, the intent of RAMP, our Rapid Migration Program, is to bring together the best of our tools, our approaches, our frameworks, and methodologies under the umbrella of one motion we can take with a customer or our system integrator partners can take with a customer. And in addition to those toolings, make sure we land at least these five best practices. I won't claim that this is an exhaustive list. However, I've worked on hundreds of the world's largest cloud migrations over the last decade.

And what I've learned, experienced being a very hard teacher, if one of these five things is missing, it's likely going to stall. The first is having a great business case and executive alignment on that business case. Why is the organization as a whole doing what they're doing? What's the North Star? Ten years ago, when there was really forward-leaning CTOs, I'd like to think I was one of those when we were moving Dow Jones years ago, a decade ago, total cost of ownership being at least a parity was enough, and there was just a gut feel that moving to the cloud was going to be better.

Today, I would say the modern enterprise is a lot more scrupulous, and they want a little bit more than just cost savings. So how do you quantify, and what's the reason, and how is that tying back to a board-level objective? One of my favorite business cases is a large telco company I worked with a couple years ago. They had 2,000 developers in this one business unit, and we had concluded, collectively, that they would be 50% more productive as a result of migrating their applications and then being in a position to run them on the public cloud.

Well, that yields 1,000 extra developer years a year per year on an ongoing basis that they could then free up to run their next 100 experiments or projects that they wanted to do. So I would say that was what their business case hinged on, that's one. The second is around having a training and enablement plan. You talked about the people and process having to evolve in unison. Well, the people, when you have folks who have, let's say, been in a network engineering, security operations, sysadmin, DBAs, who have been used to working in an on-prem environment in a particular way for 10, 20, 30 years.

We talk to customers who have people who have been operating mainframes for three decades in some cases. We haven't changed computer science fundamentals with the cloud, but we've made it much easier to build large-scale distributed systems really quickly. And a lot of these roles are evolving in the cloud model. So everybody can make it if they're willing to learn, but it's up to the leadership team to really put a path in place for all of their teams to understand, hey, this is how your role is going to change and evolve.

Here's the things that you're going to learn, and we're going to support you with this sort of training. I believe, personally, that every company already has the people they need to succeed with the cloud. They just have to train and enable them. The third is having a cloud center of excellence, a team of cloud experts, ideally from a diverse set of role profiles, so not just your developers, but your developers, your operations, your financial teams to run a FinOps practice as you move to a cloud-based, consumption-based model where it's not heavy upfront CapEx.

There's a different discipline that needs to be built around that, and having that centralized is usually good. An HR component to help with the training aspect. And then from a technical perspective, that CCOE, as I call it, the cloud center of excellence, which customers name it all sorts of things. We don't have to be religious about that. It's just sort of a nice way to describe it in the abstract. To really harvest the best practices, blueprints, learnings, maintain the landing zone where applications are going to land to make sure you have a consistent security footprint, having a team at the center really harvest those best practices and enable the other application and business unit teams as they move is super important for scale and leverage.

The fourth is having, at Google we call them OKRs, Objectives and Key Results. What are the quantifiable key results that we're trying to drive on a weekly, monthly, quarterly, annual basis that we can maniacally measure? What's the line in the sand? The ties to the business case, but it's much more specific. The landing zone will be set up by this date. This many applications will move by this date. Ten percent of my team will be trained by this date.

And really measuring that. And then that leads to the fifth and final thing that I think needs to be at all migrations, which is great governance. Working with the customer, whether it's driven by one of our SI partners who's following our approach or it's done, you know, in side by side with our account teams, meeting on a weekly basis, what's the progress against that OKR that we've set? Things are going to happen. Stuff's going to go sideways. We're going to, you know, learn new things as we go.

And the question is how quickly can we adapt to that and escalate issues as they come up. So RAMP is really all about taking all the different tools and approaches that we have, making sure that we're landing these five best practices on top of that into one approach where we can help a customer assess their environment, build the right foundation, set a plan for a migration at scale, and in some cases move thousands of applications in as quick a window as we can get them there.

Yeah, so Stephen, one follow-up conversation we'll love to have one day is kind of how that evolves over the course of a migration. , Bobby, I've talked to one of your associates, Nathan, about this, about how Google Cloud with developer workstations and now I'm developing applications in a different way and now I need a new developer experience. How do I change my organization or how do I allow my organization to change in not just the processes but the tooling to enable this new look?

So going back to you, Bobby, about tooling, I'm not even going to set you up with the question. I just want to hear the analogy. What's going on with real estate and Google Cloud? So we had to kind of do a sequel. So last time, I think, when you and I met with Richard Sirota, our buddy, I think all three of us had moved recently. And what's interesting to me as leaders who talk to companies a lot about disruption, I think we need to notice disruption in our own lives.

So there are three R's in real estate, in my opinion. You can refinance, you can relocate, or you can remodel. So I did the relocate a year ago, but I did the remodel this year. What's happened, because my wife's a real estate agent, we've moved a whole lot, eight houses since 2002, third major remodel since 2016. And so some of what happens to Stephen's point about best practices, you get smarter as you go along. And so the thing that we did for the first time, Keith, with this remodel that's super relevant for, I think, our audience is for the first time, we actually came up with a plan before we started knocking down stuff.

We sat down with the designer to come up with a clear vision of where we were going. And a lot of us in the cloud, Keith, are knocking down low, barren walls without understanding what we're trying to put back. It's not, I would argue, it's not an issue about skill sets, scarcity of materials, certainly not cloud provider resources, lack of clarity of vision about where we're going, and expectations is one of the biggest things. So here's what I would say to the audience.

It's not enough to have a vision about where you want to go. You've got to have an appetite or an assessment of your budget for disruption. Here's what we did differently this time, too. Because we were doing so much change, my wife actually recommended that we move out. So we moved into an Airbnb for part of the renovation because she understood the level of fatigue that happens when you're going through change. And again, hopefully I'm talking to someone in the audience who understands that.

How many things have stalled because we got tired of, you know, living in construction dust in our application portfolio? Like we need to think about the level of fatigue that our teams have and make sure that we've gathered our materials and got a clear plan before we start knocking things down. Because your team has to operate, right? We're working on a plane and flying it at the same time. So we have to think about how much change our team can handle so you don't leave the team behind.

I love Stephen's point. We're not trying to kill the existing team. We want to bring them with us into the future because they've got skills we want to leverage. So my recommendation for you all is, again, don't think about your appetite for change without thinking about your tolerance for disruption. Do the planning up front before you start knocking down walls and it will lead to hopefully a happier application portfolio, definitely a happier marriage. I'm not sleeping on the couch. The kitchen is done.

I think my wife is happy. So hopefully it worked out. Yeah. So to recap this, we've done, at the CTO, I've done tens of thousands of workload migrations. And I think the temptation is, to both Stephen and Bobby's point, the temptation is to just go. You know, I'm moving a LAMP stack application from a VM on-prem to one in the public cloud and then I get frustrated that I'm not seeing cost savings in the public cloud, at least not from my infrastructure bill.

There may be overall cost savings, but at the end of the day, you're measured on your individual spend. So how do I fix that problem? To both their point, there has to be a set plan about what value do you want to get out of the public cloud. If the bill is going to be higher, that can be okay. If I get a thousand more man hours out of the whole deal, no one's going to be mad at me that I'm spending 30%, 50% more on the cloud if I'm getting that much more productivity.

So having that solid business case and that plan about how you're going to do it. A CDC survey said 63% of respondents spend more on the public cloud than they planned. That number on surface can be a bad thing, could be a good thing. But to Richard's point, if you have that first part of the ramp plan, the executive business case, maybe 63% spending more on the public cloud, only 20% of those respondents are actually angry at that fact. Maybe that's that much more business value.

But you have to have a plan. com. If you add a forward slash Google dash cloud, you'll see the research that we did sponsored by Google last year. This podcast was not sponsored. If you want to ask me or one of my guest questions, you can always DM me on social media at ctoadvisor on most platforms, including Blue Sky, which I'm starting to like a lot. And I will relay the questions. If I didn't go hard enough on my two guests and you have opinions about Keith, this was a softball interview.

I don't think either one of them are not sweating, but okay, I'll take that feedback as well. You can leave that if you're watching this on YouTube, comment sessions below. Talk to you next CTO Advisor studio, hopefully from another great location.