Understanding the Google Cloud Migration Approach (RaMP)
Transcript
(dramatic music) >> 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 a familiar Face, Bobby Allen, Outbound Product Management at Google Cloud.
Bobby, welcome back. >> Thank you, thank you. >> And Stephen Orban, 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, we always appreciate spending time with you. So yeah, Steven Orban and 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 programs, starting the data exchange, and running their marketplace and ISV partnerships. Prior to that, I was the CIO at Dow Jones for a couple years, leading a "large scale digital transformation" as everybody calls it now, we didn't have that buzzword yet, (Keith laughing) so we called it something else then.
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 a hundred million dollars 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. (Stephen laughing) You're bringing all of that pain forward and sharing, so when you're in conversation with customers you can have that shared journey, knowing what it's like to have in mind a theory 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 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. >> Yeah. >> 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?
These would be kind of what we do at 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, there's a reason, Stephen, 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. So 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 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, you know, responsible, secure, resilient basis is super important, so the tools are a super important aspect of the work.
But 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. And I've talked to more than a thousand 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.
" And as you said, being kind of both on the customer side and the vendor side, I would summarize it as, experience is the most brutal of life teachers. (Keith chuckling) >> Yes. >> You know, I've learned the hard way that overlooking some of the people and process changes is really what ends up getting in customers' way. So 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.
So 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's 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. >> Yeah. >> And how we can take a Windows workloads, and basically containerize it. " 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 ISS app.
>> Yeah. >> Where has the standard and the technology moved almost a year later? >> So first, Keith, let me just kind of acknowledge a little bit of the elephant in the room. Windows Containers is probably as polarizing as Ohio State person Michigan. (Keith laughing) You don't land on both sides of the issue, (Stephen laughing) and I'm a Michigan guy, so go blue, so you know what 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's 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. >> Okay. No, yeah. >> And so IT administrators tried 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, Stephen's 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 a 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 your beach body.
>> Yeah, correct. >> I love that. I love that analogy. And we'll come back to your real estate analogy. But Stephen, I want to, you know, kind of go back to you and piggyback on what Bobby was saying. 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 the application, because they understand the application, they understand, they're closer to the business.
So talk to me about this RAMP 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, experience 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? 10 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 at 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 like 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 a thousand extra developer years a year, per year, on an ongoing basis, that they could then free up to run their next a hundred 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 know, 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 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.
I mean, we talked to customers who have people who have been operating mainframes for, you know, three decades in some cases. You know, 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. >> Yeah. >> And a lot of these roles are evolving in the cloud model. " 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 up 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? It 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, 10% 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 in all migrations, which is great governance. Meeting with the customer, whether it's driven by one of our SI partners who's following our approach, or has done, you know, 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, 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, now that I'm onboarding so many apps into the public cloud, how do I now evolve all five of those areas for my changing objectives and new business capabilities that I've gained, and that new look at operations. We might have 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, and 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 Sorora, our buddy, I think all three of us had moved recently.
>> Yeah. >> And what's interesting to me is, as leaders who talk to companies a lot about disruption, I think we need to notice disruption in our own lives. So I did, there were three hours of 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, and 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 practice is 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're going. >> That's a good idea, yeah. >> And a lot of us in the cloud, Keith, are knocking down load bearing walls without understanding what we're trying to put back.
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 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 upfront before you start knocking down walls, and it'll lead to hopefully a happier application portfolio, definitely a happier marriage. I'm not sleeping on the couch, (Stephen laughing) the kitchen is done, I think my wife is happy. So, hopefully it worked out. >> Yeah so, to recap this, we've done, as the CTO advisor, I've done tens of thousands of workload migrations. And I think the temptation is, to both Steven and Bobby's point, the temptation is to just go. It's, 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 IDC survey said 63% of respondents spend more on the public cloud than they planned. That number, on the surface, can be a bad thing, could be a good thing. But to Richard's point, if you had that first part of the RAMP plan, that executive business case, maybe 63% spending more on a public cloud, only 20% of those responders are actually angry at that fact. Maybe there's that much more business value, but you have to have a plan.
com. If you add a /google-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 guests, questions, you can always DM me on social media, @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 'em are not sweating, but okay, I'll take that feedback as well.
You can leave that if you're watching this on YouTube, comment section's below. Talk to you next CTO Advisor Studio, hopefully from another great location.
