Application Modernization with Google Cloud Platform
Transcript
(booms) (swoosh) >> Hey, it's Keith Townsend Principal, at the CTO Advisor Group. " You're right. We're in beautiful Mountain View, California. I wish I could give you a view of the pool that I'm going to jump in after. There's going to be a cool 106 degrees today, guys. I have with me, Bobby Allen and Richard Schroeder, right? Both of Google Cloud. Welcome to a sponsored "CTO Dose" here in beautiful Mountain View. >> Thanks Keith. Thank you for having us on the program.
>> Yeah. >> All right. >> It's great to chat with you. >> So that's going to be the nicest thing that I say to you guys. Yeah. The rest of the video, this is a sponsored "CTO Dose", but you know, we get it right after you guest on the CTO Advisor. We are doing a sponsored, proof of concept with Google. Where we're taking your migration tools and migrating a monolith application to the public cloud. We're in an era that, you know, mega software companies are getting gobbled by mega hardware companies.
Customers are kind of, in the state of confusion. " >> Yeah. >> The last time you tried to do that, you lifted and shifted to the public cloud. You broke everything, costs were out of this world. You couldn't quite tune in application performance. Why in the world would someone lift and shift their applications to Google cloud as a response to the overall market conditions? >> Yeah, man, some- one hand, you're doing the lift and shift because you have- exiting a data center.
And I see that. There's that ticking clock that says", I have to get out", or sometimes you're actually sold a little bit of a bill of goods in general, about, "Oh, the cloud's going to magically make my app more available. I'm going to ship more often. " The hard part is that once you get there, if you're just moving your network, architecture, your VMs, your processes, your same change review board, your same ops tools. You just have someone else's data center, that probably costs you a little more.
'Cause now it's running per minute and there's no, you know, it's all OPEX not CapEx. So if all I did was just run in someone else's data center, I'm not realizing the point of the cloud. " Like, can I actually improve some of the things that I was doing? And it's not just moving everything as it was. " Can I start to think of continuous delivery or better automation? Or can I start to make some improvements on the journey? As a- we don't want everything to be different, 'cause that would be nuts, but can it be common enough that you're not going to have to retrain everybody, but that it's worth moving.
You do see security benefits. You do see speed benefits. You do get your systems online faster when they go down. Like that's what we're trying to get to, is use some of what we've learned at Google over however many years of trying and failing, and trying and learning to actually build better systems. And we see whether it's a big bank, or it's a retailer or a startup, or a independent person. It feels a little bit different than maybe what they were doing the first time in the cloud.
>> I think Keith, the thing that I think about, just to build on what Richard said is, you know, typically when you take old behavior to a new location, you don't get the results that you were promised. So if it's summertime and I eat fried chicken at the beach that doesn't give me a beach body. (Richard laughing) >> And so I've got to put in the work ahead of time. And so my point about all this is fried chicken, cloud computing, let's kind of mass this all together again.
To Richard's point, there are reasons to lift and shift, to get out of a data center. But the problem is when you make that the final chapter, not the first chapter. >> Right. >> And so if you have a specific purpose you're trying to accomplish, great. You've exited that data center. You can turn that off. But that's got to be the start of your innovation, not the end of it. And so that's really a lot of what we're going to talk about.
>> So we all are either in the process of moving or just moved. And one of the primary reasons for me moving was to get bigger and better studio, to be able to create more content and create content faster. But, what I did was I took my studio and I lifted and shifted it. I took what I was doing in my old house, put it in the new house. And I had a plan for spreading out, kind of modernizing my operations.
And you know, two or three months in, I'm stuck. You know, I'm in production. Like, I have deliverables. I'm doing work for Google. I'm doing work for other vendors in the space and I'm creating content for the community. And it reminds me of this motion that most customers make. They get stuck. Where the intent was good. The intent was to lift and shift. I've heard what you both are saying before, is that this is, you know, a stop along the way, but it's not the final destination.
What I'm finding is customers are having- I got into a really spiritual debate at dinner the other night. Director IT said that he was going to migrate all his applications to the public cloud. He's looking at now the cost of lifting and shift-, lift and shift, and then migrate and doing refactory. And I told him, the problem isn't the cost. Like, it's doable. The problem is people. The same people I'm asking to do the lift and shift are the same people that I'm asking to modernize the app, which is the same people that I'm asking to do, new feature requests.
Problem I ran into in my house, new house is that I'm the same person who creates the content, is the same person that has to do the studio redevelopment, doesn't work. >> Richard: Yeah. >> How is Google helping us solve that problem? >> Yeah. I think the biggest thing Google wants you to do, is to have options. So we realize lift and shift is an option. We're not saying that that's going to be, necessarily, the right option for you, but what we're trying to give you, Keith, the data points to make a decision with real, real evidence and real data and real numbers.
So what does that look like? For example, If you're looking to exit your data center, you want to understand what modernization options look like. That might look like lifting and shifting to the cloud on your existing platform. That could look like lifting and shifting and changing platforms. That could look like going to containers. That could look like going to serverless. And so before you execute those moves, just like for any of us that have moved or are about to move, you get an estimate before the movers come and just start boxing up stuff and slapping it on a truck, right?
Because you don't want to have sticker shock. So I would argue it is a people problem and a price problem. And so we want to say, let's look at your existing footprint, show you what the options are, give you some math, give you some numbers and let you decide where's the juice worth to squeeze, Keith. Because the other thing that we haven't talked about is all apps are not created equal. I may not be willing to make the same investment in my money making customer facing app, as my password reset app.
I may want to take that all the way to containers or serverless, and the other app I just want to contain in a VM that's running more efficiently, off prem, in the cloud. >> So Bobby, I've known you for years. This is a familiar talk track coming from you. You know, you don't give an app with limited value unlimited resources, is one of the things that you've said in the past. >> Bobby: Yes. >> But as I think about Google's portfolio, Google cloud's portfolio, that doesn't seem like something that Google cloud helps me with.
Like how do- from a practical perspective, if I'm a CTO, CIO, I'm a cloud architect, and I want to do an assessment. I want to prioritize what gets re-platformed or refactored and what doesn't get refactored. What's the level of effort to do all of that. All I'm doing is looking, I'm getting on a long list, a long wait list to Centure, PWC, et cetera, to make that happen. >> Yeah. Yeah. We actually, have a- so one, I'm glad you attacked that head on, Keith, because I think people think of us as like the Star Trek guys.
Right? When I want to transport or I want to, you know, go into the future they'll come and talk to us, but we can help you with practical stuff right now. This calendar year and this time. And so, we actually have a fit assessment tool called MFIT, that will look at your estate and will tell you, Keith, what's possible. Is this something that has to stay on a VM? Can it go to containers? Can it go to serverless? And what I'm really excited about is, a lot of decision makers need a business case.
So don't just tell me, what's possible, give some numbers. So if you can imagine, run this assessment in hours or days, and then give me an idea, Bobby, of how much it's going to cost if I ran all of this in containers versus VMs. " >> So Google is commissioning us to do exactly that. And as of this video, we've done it. So, I'll share some of the process there. But I think, consistently, Richard- and this is why I wanted to interview you- is the problem that I've ran into in our data center or in our virtual infrastructure now, that now spans our data center and Google cloud, is day two.
So, I get pre day one, I get day one, I get the move. I don't know what I'm doing now. I'm just going to be honest. Like, the there's- I have stuff in, Containers, and Anthos, and I have stuff in Cloud Run. I don't know how to optimize it. I don't know how to observe it. I don't know what my governance model will be around employees and structure... Help me out. Like, I'm lost. >> Yeah. No, that's the, some of the hard part of that first round of lift and shift.
Is all we use almost heroics to get stuff into the new place then it's like, well, now what? Now, I get the hard part's running it for the next 10 years. Not the last 10 minutes of moving stuff. So yeah, that day two story. There's a couple ways we try to help. One is, there's things to give you suggestions. We have an Active Assist system that says, "Hey, we'll use AIML to say, you got way too many permissions enabled for these accounts right now.
" And you, we have some really interesting cost insights where I can look by cluster, by workload. And then by workload, I could actually see "Here's my recommendation to resize it. " But then, it is important that all these things use the same subsystem. So it's all the same ops platform. I don't care if I'm a Cloud Run, GKE, VMs, Right? SAP on Google Cloud, whatever. I can have the single observability dashboards alerting. Same with identity systems, same with kind of, pub, sub, and messaging.
So at least some of it trying to be, at least I'm not learning a different stack per run time. That would be oppressive. It would be tough to figure out. So some of it's commonality, some of it's AI led stuff. " 'Cause gosh if you set up the wrong structure of projects and accounts, it's hard to unwind later. So what's a good structure. And of course, partners come into play here as well. We have a lot of great regional SIs, it doesn't always have to be one of the Big Five coming in doing a big project.
They are great, but sometimes I want someone to come in here and just be like, man, enable 10 people on my team. Or help build my center of excellence, or help get me optimized 'cause I've been here for a month, not totally sure what's going on. So try to do some through automation, some through self-study, some through partners, and then make sure that you're, you know, doing health checks, even with our own product team and stuff. There is a benefit with the fact that we're a little smaller and hungrier.
That like our product folks are spending tons of time with customers. Engineers, there's probably a, you know, elephant in the room sometimes of the arrogant Google engineer. (Keith laughing) "Hey, like, you know, why are customers bothering us? " That's really not the vibe. The vibe instead is like, "Can we spend more time with people using this stuff? Can you show us, what's not working? Can you give us your friction log? " And so people like Bobby and I, and across the org, you know, we love spending customer time.
Can I watch you do this? Can you show me how you're doing it? Can we figure it out together and make it better? Because arguably the reason you work with us, is you want Google on your team. >> And it's not just using our products. >> Yeah, and I don't know if, you know, if we got special treatment or not, but you know, we have engineers that wrote our application in New Zealand. We have me normally in the Midwest of the US, and then we have the Google product team, Bobby, some of your team, in Israel.
And we're on the phone at midnight, just, you know, chopping away, trying to get this application migrated. >> Bobby: Yeah. >> And there was no limit or no reduction of interest in what we were doing. What was the app doing? >> Bobby: Yeah. >> And how do we plan on using it moving forward? You hit on a topic that's of great interest. Again, we're only doing a slice of what customers will do. We're migrating one app. If a customer needs to migrate thousands of apps, they need to expand out into the ecosystem.
>> Yes. >> The Big Four, >> Big Five, they can't accommodate all of that capacity. Talk to me about the partner ecosystem. Who's out there to help? Like, is Google so small-? And I don't want to say Google's small, like being in the position you are, second, third, or whatever, in the big three of cloud providers, it's still a massive space. >> Bobby: It is. >> I've talked to folks looking to resource up to like 600 people for a project.
How does Google's ecosystem compare to the competition's? >> Yeah. So there's a- So Google is investing in this ecosystem. Both in terms of professional services, but also in terms of partners, as Richard talked about before. So that's your big, you know, your big GSIs. Right? Think your Accentures, your Deloittes, people like that. But it's also kind of more the RSIs, the regional players, ThoughtWorks, SADA, 66degrees, people that you might not have heard of, but have great street cred, in terms of coming alongside and helping customers.
The thing that I like about them, Keith, so not only can they provide people, but they also can provide behavioral changes. And that's one of the things that we often miss when it comes to modernization. You've heard my mantra before, tech is the easy part of tech, Short version, long version. Tech is the easy part. People are the best part. Behavior is the hard part. Humility is the worst part. We invest in partners, Keith, who believe that technology is not the magic bullet.
So partners that will come alongside that can talk you about containers and dev tools and CICD and all that, but also cultural changes. How do you need to hire differently? How do you need to staff differently? What does it look like to improve the application? Not just what it runs on, so. We've got people. If you want to reach out to us, if you're someone that's listening to this, we have a steady kind of cadre of partners that we're investing in.
People that have good chops in hybrid cloud, multi-cloud, that understand our tools. But it also, Keith, will challenge us. That's what I really like about our partners. " And so just like with your team, you all gave us great feedback. We are hungry to listen to people that are not just going to be our Amen corner and sing kumbaya and give us high fives. But people that are going to say this is wrong. Why would you ever do it this way?
We want to listen to that, incorporate that feedback, and use it to make our products better for our customers. >> Yeah. " Instead, actually, the googly thing is, we're just learning constantly. >> Yes. >> Like that's our vibe more. >> Not that you have to do containers, and site reliability engineering, and these 15 things, you have to be this tall to use Google cloud. That is not the thing. It is though, Are you learning constantly? 'Cause if you have a fixed mindset, this doesn't work well.
>> Right. >> And so to your thing, I mean, that's what we're really trying to be, good listeners. We're trying to learn. Yeah, we have opinions. Of course. >> Yes. >> But challenge 'em. >> Come up with something better and we'll switch our mind. >> So I'm struggling. I got to be honest. I'm struggling apart and reconciling, kind of the, the reputation of Google, (Richard and Bobby laugh) and how you two are talking right now.
You know, in my mind is stuck, the quote from Corey Quinn, you know, Google cloud is the best technical cloud there, but their people are just arrogant. like it's And that's not coming off here. And I guess the question is. beyond just doing the work, Richard and Bobby, both of you are people leaders. Bobby, you talked about humility. Richard, you talking about the being hungry. As you scale the organization- Google cloud is growing at an amazing clip- how do you keep from becoming kind of that arrogant?
Like, "oh, you have to run SAP in a VM? That's just so yesterday. " >> Bobby: Yeah. >> You know, it's ongoing. I mean, there's a reason our team sends out an internal newsletter every week of customer stories and just different things, to make sure that- it can be- Look, if I'm just in the trenches as an engineer, building amazing software all the time, I might be four steps removed from that end user >> at certain times. >> Yep. >> And so you got to keep putting the customer first.
Right? I got to show them, Hey, here's what they're trying to use. That's why our team often uses the products themselves and gives feedback. like, Hey, you might have thought this was the right tool. You built this for you. Like everyone is not you. Everyone's not living in Kubernetes every day and understands this whole thing. You got to build it for us normal people, who are just trying to solve a problem. >> Yeah. >> With 50 other things too.
So some of it's just shining a light on the customer constantly, using the product constantly. Mirroring good behaviors and showing that like, Hey, we want to hit the road and talk to customers. >> Yeah. >> I brought our head of engineering on a trip to Australia a couple weeks ago, and we just visited customers for a week. It was awesome. And it was just to hear that story and get, bring it back. He's been now echoing all the stories over and over again to his team.
So you know what, look, there's a lot of smart people here. Everyone's got an ego, whether they say or not, Whether are you- What is it for? " I'm good with that. If it's, we know more than you. we don't- it's not the thing we want to tolerate. >> Yeah. Keith, I'll piggyback on that. There's some times where, even when you create something, things can be used to apply the technology in ways that we've never thought before. So I got to give you real quick food story.
Went back this past weekend- >> Keith: Hopefully fried chicken. >> to go- It's not fried chicken this time. It's a little healthier maybe, but. I went back to spend time with family and I've heard about air fryers. My daughter uses 'em all the time to make nuggets and all that. What I had not had though, Keith, was a croissant heated up in an air fryer. Whew. Let me tell you. I mean, it was like, it was crunchy, it was soft, it was warm.
It was moist at the same time, a croissant in an air fryer, Keith. And so our thing is, if you come up with a new application of something that we haven't thought of, why would we say to you, "You can't put a croissant in an air fryer"? It could be fire, just like that was. And so, I would encourage your people. Don't just do nuggets in the air fryer, look at croissants. >> Keith: Wow. Okay. >> But seriously, if you're using our technology in a different kind of way, we want to hear it.
Because sometimes there are applications that didn't come to mind for us. And there could be ways to extend the technology that work for you. You're the customer, right? Your audience is listening. We want to hear about those other applications that we may have missed, 'cause we can lean in on that and actually make that more valuable for you in the future. >> Cause it still goes back to learning mindset, right? >> Like it's- >> Absolutely. >> You know, we're still going to, be opinionated like you do choo- customers choose Google because they want Google opinions.
>> Yes. >> For the most part. Right? >> There's plenty of choices in the cloud. >> Yes. " You know. What- how do I learn these new practices? And yeah if they want to do something different or they learn, That's great. But there is something about, look, we're going to still come with opinions. But they're, you know, flexible. Right? Loosely held. >> Strong opinions, loosely held. >> Yes. >> so speaking of >> strong opinions, loosely held.
The last kind of, topic I want to end on is Kubernetes. But not Kubernetes in the sense of Google cloud is the best platform to run Kubernetes on. This culture thing that comes along with Kubernetes. I've talked to a lot of customers, Kubernetes is the right thing. Kubernetes, not so much the right thing. What happens when Kubernetes isn't the right thing for a customer? Like, so much of the Google cloud story seems to be Kubernetes. Like we're migrating our application to Anthos, but there's also Cloud Run.
When- I'm a customer that, I just have no roadmap for Kubernetes. That just not a thing. But in my mind, if I want to do Google cloud, I got to, I got to be doing Kubernetes. Is that true? Is it, kind of a myth? >> Yeah. It's a great point, Keith. And I'll say that it's not true. Because people associate Kubernetes obviously very strongly with Google, for obvious reasons because of how much we started, and contributed et cetera.
But we want to meet customers where they are. And so the reality is, Kubernetes may not be right for you just yet. Or it may be right for you for some apps and not for other ones here. Here's the point. Richard talked about this with something that we have called Active Assist. " What I want to say is, when it comes to Google cloud and a lot of the products we're talking about, it doesn't matter if it's the right choice.
If you pick the wrong thing, we'll fix it for you. If you land in the wrong run time, if you land in the wrong VM size, or the wrong flavor Kubernetes, or the wrong way to run a container, that recommendation engine that Richard talked about that runs in the background, will still proactively feed you things. Like, "You know what, Keith, you gave us this workload. We're going to do our best to take care of it. Keep you secure, run it well.
" Here's the ROI, the business case. We want to continue giving you that data. Right? To give you the other options, to be able to make the comparison. So Kubernetes may not be right for you right now. That's fine. We still want to take care of you and we'll treat you as a first class citizen. But then we'll also show this workload may be a good fit and then here's how to get there. So we are going to make sure that you're not just treated like the pariah that's out in the cold.
>> Yeah. I mean, look, we still think containers in cloud native are a great way to go. If you don't need Kubernetes and you can use Cloud Run, gosh, you should start there. Right? I mean, you should arguably start with the simplest abstraction and keep dropping down when you need it. Get down to VMs or bare metal, rock on. You're not going to run SAP in containers. It's fine. So yeah, no we've got preferences. >> Yeah.
>> But at the same time, >> I hope that a lot of this stuff becomes invisible over the years. Like, if you and I are hanging out here in four years, talking about Kubernetes, I think we kind of messed up. >> Yes. >> So I'd love to see, yes the container substrate has made it possible for us to say, build a function, move it to Kubernetes, move it to a VM with zero code changes. I can do that today. That's amazing.
It doesn't matter where I start. I can move. But that just becomes like invisible, cool parts of the platform. >> Yes. >> Versus like, do I have to care about damon sets and worker nodes and cubelets? Like, increasingly, fewer people should care about it. You just care about can I ship my code faster and is my system online more often. Cool. Mission accomplished. >> Yeah. >> So I lied. There is another question. There's one other place I'd like to go.
>> Bobby: Okay. >> Which is Google is famously known as the cloud that embraces hybrid infrastructure the most. We obviously use the hybrid infrastructure post to connect to the Google cloud, to do our project. But generally speaking, it's much easier to, I would imagine, to manage a cloud solution if it's all within the cloud. Where are you finding Google has a unique advantage in your approach of embracing hybrid? >> You know, I think upfront, like when we first did Athos, the reason it was unique was that it was software.
>> Yes. >> Because what was my world? >> My world was Outpost, Azure stack, powerful things, but life commitments. Like, you were buying a rack, (Bobby and Keith laughing) >> you were buying hardware. >> Like, You know, you were in here for five or eight years, whatever your term is. Versus like, Hey, I got a few nodes. Let me run a modern platform that still kind of has a cloud control plan. That's weird, all right, let's try that.
So it was a different story. And so I think what we've embraced when I've watched over these last couple years is, we're saying if you're going to do hybrid, you're going to do multi-cloud, Whether it's a good idea or not, you're doing it. >> Yes. >> Cause everyone's- >> spreading it around. Can I at least centralize my control planes, my management planes, even if my data planes' all over the place. My data's sitting in an S3 data lake, big query Omni works with that.
Because we've put the big query engine in Amazon, still common control plane, still using, managing it the same way. But your data plane's over here. Or my compute cluster's at the edge at a quick service restaurant. Okay. Doesn't make sense maybe to move that to the cloud, but can I at least manage it from the cloud? So I think we're seeing what we've been embracing, with Big Query, with GKE, and Anthos, with our build tools, with Looker, Big Lake, like all these products, is we'll recognize the fact that your data and your computes could maybe be spread out.
That's cool. Can we at least kind of secure and scale and manage things centrally from a cloud control plane. That's been unique. Like I think, look, everybody's doing stuff here in the cloud, now. I think some of it's following our lead >> in this one a little bit. >> Yes. >> 'Cause we kind of proved that this was a real opportunity here. So I'm excited about it. I think that cloud backing is what makes this different from some of the software vendors who've been doing hybrid in Multi-cloud.
Like, that's cool, but where do you offload observability stuff too? Like, I don't have a cloud to put that in. I just got to keep storing logs in my system, or management, or Dev Tools, or CICD. We get to leverage a Google network, a global control plane. So, I think our, just approach has been different. >> To say, can we centralize some of the core stuff without making you move all of your data here and not move all of your compute here?
>> That's been kind of different and a lot less threatening to somebody who's never going to move all their stuff to one cloud. That's cool. >> I think part of it too, Keith, is just philosophically. You know, I think some of the other players have kind of tried to do the Jedi mind trick. " (Richard laughing) >> It's like, this is not the "Mandalorian", right? We've said, yes, there are other clouds. And we want you to use our cloud.
We believe our cloud is viable. We are investing in it. We want to make it, you know, so that it's an absolute rockstar to run your applications. But if you do have a compelling reason to use another cloud, let's make it easy for you. Let's make it consistent. Let's make it so your engineers and architects don't have to learn, you know, whole new controls for how they manage things. We want to make it so that you have the flexibility to run with us because you want to, not that you're stuck with us because you can't go anywhere.
So we don't want to be the Pied piper of cloud where it's Hotel California. But we believe there's enough innovation there, There's enough forward thinking that you're going to find it compelling if you give it a shot. But there may be other things like on-prem that you're going to leverage or other clouds that'll compliment what you're doing in our cloud. And so, if that's the case, let's make it play together. >> And it's an easier entry point. Look, I think a lot of our customers are asking was our first cloud our next cloud.
Is the first cloud I chose five or eight years ago, is that the next one? Or did I choose- make a great choice in 2015? >> Right. And now like, all right, what's my data cloud, my innovation cloud, whatever. And so multi-cloud and hybrid, We get to be a little safer to play in with all that, without making you just switch it all up. >> Yeah. I do these things called CTO shorts. So call 'em. Longer than the tweet, shorter than a blog post.
And one of my thoughts was, day 3,063 or something. 663, whatever, 10 years works out to be. And if you would've been a startup 10 years ago and you built your stuff on AWS and you looked at the number of services that you built it on, that's now technically, technical debt. >> Bobby: That's technical debt. >> And you're looking to re platform today. And how difficult would it be to re platform to Kubernetes from that cloud central control panel model before, to something more abstracted today.
So as customers are thinking about not just today, but 10 years from now. know not what happens if I have to leave my cloud provider, but what if I need to modernize the cloud provider? And one of- that's one of the questions that we had when we modernized our app. okay, we moved it to containers, but what if we wanted to move it to serverless? What would that look like? And does the cloud provider make it a smooth transition for us?
We used many of the tools that Bobby and Richard talked about. com. Hopefully by the time you watch this, the landing page will be there. If not, keep checking back. If I did not go hard enough on Richard and Bobby, You're thinking, Keith, I really would've hammered them on this particular session. I have both of their email addresses now. And I do not have a problem asking follow on questions or even doing a follow on project. DMS are open @CTOadvisor on the Twitters.
Talk to you next CTO Dose.
