Managing Workloads in the Multi-Cloud Computing Era – Billy Thompson, Akamai

This is Techstrong tv. Hey guys, thanks for the throw. We're here with Billy Thompson from Akamai and we're talking about the tensions that are currently exist between developers who, on the one hand wanna consume everything and anything they can find and the actual cost thereof and the motivations of the hyperscalers.

Billy, welcome the show. Thank you for having me, Mike. Why is all of this coming to a head now?

I mean, developers have been more or less spending money like drunken sailors for a long time and no one really thought too much about it. Of course, the economy has changed, but it seems like there's a lot more tension now between the developers and the hyperscalers over cost. What's going on?

Well, the tension is that the hyperscalers, I mean, put simply, they're not very cost effective and they're very vendor locking. And the more and more effort that goes into developing within that environment without considering portability, without considering your ability to leave, and the more and more of their abstractions that you get wrapped around 'em, the harder and more difficult it is to untangle from that at a different point in time. And what's bringing this to a head right now is the trend of multi-cloud and hybrid cloud being another one, which isn't a trend because it sounds cool, it's a trend because it makes sense because organizations and the developers within them, everybody alike, they're more and more seeing the benefits of maintaining portability and more cloud agnostic architectures and maximizing all of the options available to them to explore at any given time.

And they're seeing the greater degree of scale and availability and reproducibility that comes of that. So they're more and more insistent on maintaining control over their cloud environment versus their cloud provider controlling the outcomes of what they can and cannot do, which is really always the way it should be. Your cloud provider should be nothing more than just a vehicle you use to get somewhere, you know, something that suture needs for that point in time that helps you move around, but it should not be the driver that should be you.

Mm-hmm. And unfortunately, many organizations have come to find that the hard way over going in the legacy all-in cloud provider and their abstractions approach, they got stuck on an island, something happened and it was an unpleasant experience having to navigate that and figure out how to move forward and get past that. The pain of vendor lock-in and fear of running into that again is something that I've heard across the board.

SMBs and startups to mid-market and onward up to enterprises. Every band has organizations who feel pain from vendor lock-in and who've had these situations come up where they're then forced to figure out if they can tolerate that pain versus what is their ability to break free from that. And that ultimately led leads to, in many cases, some huge financial burden, especially when you consider the macro economic issues that are happening today.

Mm-hmm. How did we get here because we've been talking about the need for portability and avoiding vendor lock-in for decades. So what went wrong with the cloud that makes it harder to move those workloads?

I think it's that there's a lot of narrative out there that is actually insisting that doing things more portable and especially when it comes to multi-cloud, that it's harder or gonna be more operational overhead. And I've been making the argument for a while that I'm not really seeing that as being the case based on what I perceive happening in reality when I see organizations who are moving from vendor lockin to portability, right, from platform specific to cloud agnostic, what I'm really seeing are the same teams, the same engineers just taking different approaches and you have all the infrastructures code and config management, you have, you know, past like offerings like Kubernetes and so on that all kind of seem maybe a little scary or overwhelming to experiment at first. But what I see more and more again is that people that go and explore that because whatever the reason they're trying to leave their vendor lockin situation, like they've made the decision before, they're talking to my team and I've seen them make that evolution and I'm in pure disagreement that it's more work or something harder and more complex than what they're able to do, especially when you consider the amount of energy, the resources that have to go into learning all the proprietary of one particular provider, how many hours go into like getting AW S certified and so on, just to help you better use this tool so that you can actually be using it more efficiently to finally actually get your billing under control.

And so it seems like there's this overarching narrative that says you want to reduce complexity, you wanna get to market faster, easier, come to us, use all our manage services, use our abstractions. But what is actually happening there is, I think they're taking away the appearance of complexity in one area and just reintroducing it it somewhere else with it just being difficult to use the platform overall and never being able able to understand your billing resources and just difficulty navigating the amount of options that there are within that. Mm-hmm.

Are you seeing folks move workloads from one platform to another? And how much work does that actually entail? Well, it really depends on how many proprietary services they're using on the other platform.

So I've talked to customers who are very, very wrapped up in a specific environment, very specific managed services abstractions, and there can be a considerable amount of re-architecting and I've seen it take three months to two years and it's sometimes something that you really have to plan out in a series of stages. So what we'll typically recommend is look at what you can move now, because here's another common mistake I'll call it, is that people are feeling that just because they run some things in one provider or use some services there, that that also makes it simpler to run everything that they have there. And that's another thing that isn't always the case.

Say you are using a provider's managed, you know, machine learning tool or something like that, but then you have a spark cluster or something to process the data afterwards that can run just fine on a lower cost provider. And the amount of even just using the UI or using the Terraform provider, the amount that you have to navigate just to get those resources up and running, it's a lot faster and smoother on this other provider. So we wanna start by looking at what can you move today and what workloads make sense now.

So those could be, you know, to have in staging environments that could be a new practice being built out that could just be separating, you know, here's the data intensive workloads that will run just fine or maybe even better over here. And we can plan out a migration strategy and start with the one-to-ones. And then for the non one-to-ones, look at the open source solutions that provide same or similar functionality and sort of help them them build that into their testing methodology so they can have a process moving forward where they can work on swapping those out with the open source solutions.

And then once they get there, they have a fully portable architecture that they can either pack up and move anywhere they want or that they can even scale it out across providers for better disaster recovery availability and so on. So that's one scenario. But I've also talked to many clients that were just already on their own only using the core cloud infrastructure primitives, whether that was by accident, they just didn't seem to need any of the other resources or whether it's because they were consciously worried about getting stuck somewhere because of what they've seen happen in the past and what they've experienced before.

So when they're just built on core cloud infrastructure primitives, right. And it needs, and when I'm talking about that is the things that you will find on all of the cloud infrastructure providers, right? Your basics, compute, storage, networking will even go like load balancers, uh, block storage, s3, all of this you'll find on all the providers.

So these are all kind of resources that you can commoditize and swap out and being built on. Just those, those are the simplest migrations I've seen. Those are pretty seamless, pretty straightforward.

Yes, there are some minor coding changes and things like that. There's some different syntaxes and so on with our different APIs, but pretty minimal comparatively. Sorry.

Um, popular wisdom has it that if I add additional costs, I'm adding more consoles, more specialists, so the total cost of cloud computing will go up accordingly. Is there some way to avoid that kind of expense? Um, so I think the point is that you want to be looking at how you can always get the best cost to performance ratio.

And I think that's the big piece that's missing here. You can run workloads in the cloud in ways and on providers that are more cost efficient than say, using your own hardware, right? And managing the overhead of your own data center.

I think the bigger problem that's happening is that most of the industry thinks that cloud is spilled a W S G C P in AD Azure and that there hasn't been enough exploration of all the other options out there and how you can use, okay, I have this particular workload that needs this performance that I can only get on this provider, but this is ways in which I can save money or get better bandwidth deals here. And how you can split that up. I think it's more that there's just an overall lack of that and lack of that exploration because this can be a lot cost more effective.

And a lot of these managed services, they're not necessarily cheap either. In fact, you can get way more reduced costs from running your own self-hosted open source solutions. And if you're already doing things cloud native, if you're being declarative in infrastructure as code, this all fits in nicely together.

You're tying into the same processes you're already used to from a developer perspective. Is this conversation also what's kind of driving the rise of platform engineering? We're seeing more centralized IT operations get involved rather than just letting developers kind of provision workloads from wherever they feel like.

So are we seeing more adult supervision? I think it is. I think, I think that is part of it.

I will say that just because you're doing more self-service platform engineering and better implementing, you know, the greater umbrella of DevOps principles, you still have to keep portability in mind even when doing that, right? I mean, you can have a full everything is code approach that still wraps around proprietary services of a particular provider, but doing this does already kind of have that, that mechanism in place, right? Using your automation tool chains and so on to reproduce environments to replicate them in a way that's efficient and have more efficient testing and so on so that you, you have a path forward for getting out of that and getting your feature parody in another environment.

And yeah, I do think that platform engineering, that this is at least a big part of, you know, the boom of what we're calling platform engineering now You of course cannot walk down the street without somebody leaping out to talk to you about this great new AI thing that they have. Will AI kind save us from ourselves when it comes to cloud spending? That's an interesting thought and I'm gonna answer with probably not.

I think that, I think AI is, is great guidance, right? I think it's very helpful. You know, for example, um, if you want to use it to generate ideas or you know, maybe like a sample of what, like a Go Lang, you know, API server, you know, can be coded and so on.

But it's not perfect and it's never going to be, I don't really see it as something that replaces a lot of the work that we're all doing. I see it as just another tool that's actually always been there in different ways that we're just using more efficiently. And so I can't, searching really hard to figure out how it's gonna make our cloud spend more efficient.

I'm not really seeing it just yet, but I think that's, that's an interesting one to explore. We're also seeing a lot more diversity in terms of the types of applications deployed in the cloud. We not just old monoliths, but microservices based, we see serverless computing frameworks.

So is the dynamics of managing all of that also changing? Well, yes, but it's, uh, going back to the platform engineering and everything is code, right? This is enabling of that path forward.

So I mean, first and foremost, the days of monolithic applications are nearing, like that is something that's phasing out just like the whole concept of let's go all in on a provider and all of their abstractions, right? We're seeing more and more hybrid multi-cloud type of deployments because everyone's seeing the advantage of having that agility in this industry that's expanding, you know, advancing at an exponential rate and environments that are expanding faster and faster. So, no, it's, I wouldn't say so.

So what's your best advice to folks? What should they be doing? What's that one thing you see folks doing today that makes you shake your head and go, yeah, maybe wouldn't can be smarter than that?

I think that you should keep pursuing portability and you should always be thinking about having, uh, about having portability. Again, monolithic applications are another big pain point. Another thing that's holding back a lot of innovations, explore microservices and specifically modularity.

And then I think you'll find that this construct of portability and then having that modularity in microservices and then even the next layer beyond that event driven, you know, serverless functions and so on, you get really, really, really flexible and adaptable. And consider it in the same context of something like the agile approach to software development. One of the key benefits and characteristics of that is adaptability, being able to rapidly implement change and embrace change as to meet the ever-changing, you know, business and end user requirements.

So thinking about portability and how that enables adaptability with having modular event driven architectures. Because agility is gonna future-proof your success through this space that's growing really, really fast. And that's going to enable you to keep moving forward, to keep evolving at that rate and keeping tomorrow's cutting edge.

All right, folks, you heard in here modernize your applications using cloud native technologies and you'll be a lot happier cuz you're gonna wake up one morning and figure out, hey, I've got more control than ever. Billy, thanks for being on the show. All right, thanks for having me.

All right, back to you guys in the studio.