Application Modernization at Scale with SADA CTO Miles Ward

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 another episode of the CTO advisor podcast. Obviously that is the intro now, you're listening to another episode of the CTO advisor podcast. These are starting to come out in some pretty good frequency. We have a good base. But today's podcast is a nice one that kind of you ever, you know, someone says, hey, everything's peer reviewed while our project with Google cloud is not necessarily peer reviewed. I think this is the closest thing we're going to get to it.

We have Miles Ward, CTO of SEDA on the other end of the virtual mic. That's me. Miles, welcome to the podcast. Okay. Thank you for having me on. It's fun. So Miles, quick overview, who's SEDA and what have you folks done? Sure. SEDA is Google cloud's five years in a row back to back partner of the year. We are their largest GCP focused implementation and resale partner. Got about a thousand completed customer facing professional services projects covering some thousands probably over 3,300 distinct workload types in the migration of billions of dollars of infrastructure onto GCP.

We are committed to helping Google deliver two and a half billion bucks worth over the next just three years. We're ahead of track on that. And we're a team of about 800 strong as of just this last Monday. So working to tackle all the different parts of the market, help people find value in it. So SEDA is a major piece of whenever I'm researching migrations to Google cloud, SEDA comes up like almost nine times out of 10, if not 10 times out of 10.

You folks know what you're doing. I love this concept of 3,300 unique workload types. Can you break that down for me a little bit? At scratch on the surface, right? Go to the AWS marketplace, there's 10,000 listings in it. Go to the Azure one, there's about 20,000, right? So even if we just did it on the deployments that are possible out of those marketplaces of commercial software, you'd blow that number all apart. I'm a material percentage of global Google cloud usage today.

But even with a team of hundreds, we only get an exposure to I'll call it pretty big slice of what's out being built. But we're talking the full gamut of infrastructure and infrastructure management, modernization, operational control, application development, application platform tools, application monitoring, observability, all of the work in data, data posting, data platforming, data warehousing, data science, data analytics, all the work that hangs off of the back of that and machine learning and optimized automatic routing and intelligence, got all sorts of work downstream from that in security and credential management.

And identity and access management, it's a vast platform. And customers, they need help with every part of it. Yeah, this falls thoroughly in this series that I used to run called T-H-I-S, oh, T-S-I-H. This stuff is hard. It is massive. And when we think of the IT services that a typical enterprise shop, when we're thinking Fortune 500, Fortune 2000 run, and if we did everything that we did as a service, then multiply that by the 2000, you know, Fortune 500s, maybe we'll get to kind of the surface area of what is cloud.

So when we announced that we're doing this sponsored content or project research with Google, a lot of the reaction was, you know, you guys are just scratching the surface. And I'm like, no, we're more like a pimple on the ocean. But there's value in that. What I wanted this conversation to be is one, you know, I kind of present to you where, you know, what we're doing and we kind of go back and forth about where the value is at and then where the, you know, this kind of the point out, well, you know what, this is the equivalent that worked on my laptop and now I'm going to go and do it in real life.

I have a data center, you know, it's a, you know, in the pre-recording we talked about, you know, it's the devil that I know. I know where that red exclamation on one of my vSphere hosts. I know exactly why it's there. I remember when I incurred the technical debt to do it, that doesn't necessarily apply to somebody else's VM actually as your deployment or something that they're running in AWS from 10 years ago. I wrote a piece that if you built something in AWS 10 years ago, that's now technical debt.

Like it's time to be refreshed. I mean, I worked, I don't know if you've followed up, I worked as a part of the Obama campaign in 2012, drew this architecture diagram that we splashed on across six or sorry, 360 foot screens at reInvent. And that diagram, we thought we were as efficient as could be delivered on AWS at the time. Two years later, I presented in South Africa and literally half of the diagram could be deleted. It was now stuff that just got handled at the platform layer.

com. Now that's built into DNS. You don't have to do that. It's just part of the cloud providers platform. You don't need those machines. You don't need this code for them. You don't need the scripting. You don't need operational oversight of them. That's deleted. So cloud and GCP has gone way further than that. You used to have to vacuum your tables in Redshift like it's 1997. BigQuery does that automatically along with operation of the entire platform.

One of our big customers, you want to talk about specific use cases, Newstar has been an incredible partner. They're on the data centers that you talked about. They're on an AWS architecture running Hadoop themselves. They looked at a migration onto BigQuery. We were able to prove that it would be financially advantaged. That was the critical lever for them. They needed to know they were going to save money and they did. But the product's also 11 times faster as a result.

And they've got customers that stay because it's awesome now instead of feeling like they have to look around. So there's manifold benefits of this move. Developer experience, operations team risk, the growth and viability of the platform, as well as putting money back in the bank. So you just gave us a lot of Herald numbers, you know, the 800 folks that your team has and that's grown from, what was it, 150 three years ago? Yeah, 132 or something when I started. Yeah, it's vast.

And then the 3,300 different unique use cases. We've talked about the scale of what cloud providers are providing as a service for just making your applications super efficient. And one of the things that we're kind of looking at is if you're a Fortune 2000 or even if you're just a shop that has a bunch of apps, let's say you have a shop that you have a thousand applications and you've gone on somewhat of a cloud journey, you're building new stuff in the public cloud, you're leveraging the public cloud for what it is, and you're challenged with migrating the existing landscape of applications into the public cloud, you have this kind of problem not being able to outrun technical debt.

You have a thousand apps and there's a thousand different ways to modernize those applications in the public cloud, and by the time you're done, you're kind of starting the process all over again to, you know, chasing this optimization circle. So what we set out to do is to say the team at Google said, hey, we have these tools that can automate and to automate the discovery of your application and its ability to be moved to GCP services. If you've done data center lifts and shifts in the past, this ain't it, this ain't one of them.

Like this is completely different than anything that I've done in the past. I've migrated tens of thousands of workloads in my career, and at some point they all look the same, like I'm doing a P2V, something may be a C, I can put them in big buckets and say I know pretty much where this app is going to break. So the temptation is to say that we can do that with application modernization as we move to the public, from the public cloud into, I mean, as we move from the private data center into the public cloud, where can vendors like Google help us and where do we have to go out and get folks like SADA to help get us the rest of the way there?

Sure. I think Google, you can take it from Doug Cutting, that's the founder of the Hadoop project. He said Google lives in the future and is sending us messages. The reality is they've got problems that all, literally all of Google's customers have not run into yet. There are a couple of customers of AWS that are bigger than AWS. There are no customers of Google Cloud that are bigger than Google. And the reality is that's bigger in terms of the amount of data processed, bigger in terms of the number of customers that have to be served around the world.

Remember, you're talking nine SaaS products that serve over a billion users, several of them two billion users worldwide. You find me a SaaS vendor or a company that wants their IT to behave like a SaaS that is serving billions of internal customers. And we'll have a fun conversation about scale. So the reality is they are already rabidly building the technology to make it so that those problems become tractable, become so tractable that most of the developers don't have to spend all that much time fighting with them.

So I built Google Cloud's pricing calculator. It was a total pain in the neck. Somebody's got to be able to figure out what this stuff costs. I did no operations on that product calculator ever. It ran in App Engine and I have no idea what computers it runs on, which data centers it's in, how the BGP routing works to make it so that the connectivity stays online. No, I have no view. All I knew was that all of a sudden one day the cost of that App Engine project quadrupled.

And I was like, huh, what's going on? It went from 14 bucks to 40 something bucks. What's happening? So I looked at it and it turns out other developers at Google were using the price list that was built into the calculator to populate some of their own APIs and running hundreds of thousands of requests per second against that platform. So it wasn't broken. Not broken. Doing exactly what it's supposed to do. Scaling based on viable demand. So I talked to customer after customer after customer that are going, yeah, I don't I don't know, like, I don't think we can kind of work that way.

And maybe they're right. Maybe they need to have virtual machines because their vendors have given them licensed software that isn't certified for containers yet. Maybe they need to manage their own container environment because they have super, super ookie load balancing rules or other kinds of data dominion, you know, flow control kind of problems. The reality is that the cloud providers are incredible at this kind of stuff and they are spending tens of billions of dollars in R&D getting more incredible at this kind of stuff.

And if you're not slipstreaming behind that investment, you are leaving it on the table for your competitors. And the current study, this is straight out of Dell. They say the revenue growth for companies that have described themselves as principally on cloud is 54 percent faster than the companies who are not. Are you with me? Is there any of your customers that would not like just a slightly larger amount of revenue? I think I think it's a critical spot where using these technologies in the right way unlocks unreasonable business value.

So I don't think there's any question about that. There's this agility that you just can't get the the the load balancing example that you gave me. Like if I if I never have to manage another load balancer again in my life, I'll be ecstatic. Like that's not a value add for anything that I want to do or can do. I think the skepticism is centered around I my thing is a snowflake. I don't mean a snowflake as in, you know, I have this licensing issue, etc.

But we we spent 20 years perfecting this app to run on prem. Sure. I just don't think it can be moved. And I'm not talking about an app that's particularly complicated. It's a LAMP stack app. This app that's, you know, running LAMP stack. And if I was to build it in the public cloud today, a new other than, you know, kind of the process challenges around the app is customized nitty gritty for my environment. It wouldn't take me as long to develop it, but I can't migrating it is harder than developing it a new.

I just don't have the horses to do it. I don't have the technical resources to do it. I have to migrate this app versus well, and I'll say migrating in a different term. I have to modernize this app. Sure. Versus migrating the app. I know I don't want to put it in VMs. Yeah. You use that example. And I think it's a great one. You take follow the process that hundreds of other customers, thousands of customers in the broader Google ecosystem have followed.

Decompose that application. You've said the four letters that it's built out of. So one thing you're going to want to have is somebody else to take care of all four of those parts. So one of those parts is Linux. It'd be great if somebody else took care of Linux for you, right? So if you run on top of a containerized infrastructure, you are outsourcing operating system management at the infrastructure layer to the cloud provider. If you run it on GKE, you're no longer fighting with the L.

A is Apache. You're probably not going to want to run on Apache anymore because it's like 2022. So you might want something, you know, maybe a little more modern and fast that, but fine. You have a web serving layer. You can stick that in cloud run. Now you really are literally not in charge of that layer. M is the MySQL part, right? You're trying to figure out how to run a database. You don't have to do that anymore.

Google has cloud SQL. If you've got MySQL running, there's a great partner of ours that built MariaDB is the fork of the MySQL SQL project. They can run them in SkySQL. You want to transcend all that. Go to Spanner, be my guest. The thing's spectacular. If you're done with that, the last bit, a little bit of dynamic code, PHP, you can write that as a function if you want. Maybe you'd use Python because some people had a different flavor of the P.

Uh, you can run that in any of the serverless in function environments, whether that's cloud functions, cloud run, do it in app engine, doesn't matter. In each of those areas, you've just shed an enormous layer of responsibility that frankly, very, very few companies would describe it as the point of their differentiation, the place where they're best in the world. I know of no banks that say we are the best bank in the world because we're way better at running Python than everybody else.

Yeah. My deployment is just so right. We have, we have the slippery slickest MySQL manager, and that's why revenue at our bank is going up. No, that's not why the reason the revenue is going up is you being able to crank out new capabilities, new products, new behaviors, right? You look at the most innovative businesses in the world, the change rate inside of them is insane. So you look at the Dora principles. I helped, uh, super, super, uh, impressed by the hard work from Nicole for his grand jazz humble.

Uh, their description in the most recent, uh, state of the union is it's thousands of times faster companies that are building in a modern way, shipping features, thousands of more releases than companies that are not. So it it's existential, right? The, the numbers we have from Goldman are that half of the fortune 500 is going to change in the next little bit, right? Most of the companies that are going to be on there are going to be, we've seen some disruption already in a 400.

That's yeah. Everybody's looking at their 401k going, you're already, you're right. Like, so it's, uh, it's definitely a spot where you're seeing the, the positive and the, and the D you know, the destructive construction of these kinds of transformations. So mouse talk to me, last question. Talk to me about the hard. So as we were thinking about application modernization, taking my on-premises landscape and moving that to the public cloud, Google's and all the cloud providers are building some amazing tools around that to help with, you know, recognizing those patterns saying, Hey, this is a lamp stack stack.

The, this, the, these binaries to run in, uh, Kubernetes and a, in a container. Uh, everyone has a, my SQL, everyone has a web server. Everyone has some type of, of, of, of serverless code that you can run your, your scripting in. On paper, this seems pretty straightforward. But yet, it's not happening at the scale that I think it should. Yeah. I mean, if we go into any of these companies, you say you got a bunch of people with free time.

They're hanging out, just like chilling, ready to do. So they're like, no, no, everybody is time constrained. Everybody has, you know, got a hundred new things they got to learn. I read all day, every day. I got to keep on top of what's, what's possible in the platform. So the, you know, just like I can move from one house to another, I'm capable of like shoving things into boxes and putting labels on them, but when I call the moving company, it just happens.

And they're typically better at it than I have. And they have all these specialized tools like trucks and dollies and better packing tape. My packing tape is crappy. And there's this great, those differentiators, they pay dividends, right? I get to spend time on useful stuff as opposed to the things that frankly, I'm not any better at than anybody else stuff and stuff into cardboard boxes. So that is true with cloud there. The reality is most companies aren't good at moving around.

If, if they could just focus on what they are good at delighting their customers, building what's next for them, they'd have a lot better time of it. And if they were in an environment, when they go to the new house, it has incredible automations. It's a smart home. You don't have to fight with any of the stuff, all your clothes get put away in the right place automatically. That, that is a double benefit. So SADA spends a lot of cycles, not just helping customers by hand.

We do that, right? I've got professional services teams and not just helping them by example. I ship a bunch of written documentation and materials to help people follow along with the way that we do this. But, but I think you're going to see us over time doing a lot to help, help companies learn from each other, building the community of practice where the talented folks stay here, working hard on these kinds of problems where we help companies take advantage of what, what's possible in this space.

So there's, there is a lot where, you know, in terms of it being hard, right. I, you know, I was looking just yesterday at this project plan for another of our customers. And I mean, it's one of those Gantt charts, right? Like this person does that and that person does this, and this one's a dependency on that one. It's a macro scale migration. It's got 1100 steps. This stuff's not uncomplicated. It's, you have to go through the new ones.

The, the, the scale has, scale is undefeated. That's right. Scale breaks everything. And I really appreciate you coming in and giving us some perspective on scale, migration, app development, scale, where the problems exist. These tools are maturing and it's becoming, uh, less complicated. However, that doesn't mean that it's not complicated and that you don't have people and resource issues or process problems or regulatory issues or data gravity problems, all these things that make our jobs hard exist, whether you're talking about on-premises resources, public cloud, Kubernetes, LAMP stack, really doesn't matter, this stuff is complicated because it involves people process in technology.

That's right. For those that want to, uh, find out more about SADA, how do they find you? com, not super complicated. I'm on Twitter. It's Myles Ward. You can follow SADA too. We're at SADA. Uh, we're going to have our big event is coming up in September. That's SADA Impact. It'll be me giving keynotes and doing all sorts of crazy stuff. You're, uh, it's pretty hard not to find us on the internet. Is it in person?

Yeah. Yeah. We're going to do it. We're going to do a hybrid. I think it'll probably be 500 or so people in person. Nice. Looking forward to the content coming out of that. If you want to find more about the CTO advisor, you can find us on the web. com. Watch out for that Google work. We are wrapping up the content itself, and we're going to have a landing page for the research. It is a good starting point to begin to understand how do you go about this?

And when do you engage a SI such as SADA? It'll be fun. Talk to you next, the CTO advisor podcast.