2. Should you go for multi-cloud or go all-in on AWS?
In this episode Eoin and Luciano talk about whether you should go all in and build multi-cloud applications or stick to one cloud provider. But first of all we try to define what multi-cloud means for us and how it is different from hybrid-cloud and cloud-agnostic deployments. We also discuss the perils of cloud-agnostic and why you should rather consider having “only” a migration strategy.
In this episode we mentioned the following resources:
Hello and welcome to another episode of AWS Bites, the weekly show where we answer questions about AWS in about five minutes. My name is Eoin Shanaghy and I'm joined by Luciano Mammino. Today the question is, should you go for multi-cloud or go all in on AWS? Maybe the best place to start there is what is multi-cloud? Maybe that is not clear. What is multi-cloud?
Let's start by defining what is multi-cloud. And I guess I'm going to try to provide my definition of it. I'm sure that's arguable. I'd say that multiple services across multiple clouds is kind of the way. I'd like to see multi-cloud. So for instance, you have developed an API and this API runs on AWS. Then maybe you have other services like, I don't know, databases. Even other APIs running in another cloud provider and so on.
I would say that there are other things that might be confused with multi-cloud and I wouldn't include them into this definition. For instance, hybrid cloud. So you have some stuff in AWS and some stuff on premise. I would argue that that's not really multi-cloud, even though some people might say the opposite. And also cloud agnostic is kind of interesting and related, but not really multi-cloud. So basically when you build maybe with containers or Kubernetes, when you build software that can potentially run across multiple clouds. So that doesn't necessarily make it multi-cloud. It's just you have the option, but you are not necessarily deploying it straight away to different clouds. Would you agree with this definition? So do you want to add something there?
No, I think this is good. Multi-cloud agnostic is definitely something we hear a surprising amount about. And I still fail to understand why it seems to be popular with a lot of people, but I'm curious to hear what drives people towards this. I think multi-cloud seems like a healthy thing. I think it's something that we see more and more of. I think we even see AWS recognizing that multi-cloud is a thing when they're launching services like EKS Anywhere and ECS Anywhere, which allow you to run some of your workload on-prem or in other clouds using their services, which is a bit of a departure for them.
But I think it's an acceptance that for any company of any significant size, you'll end up with multiple cloud vendors in the picture somehow. Like if AWS shop for a lot of your core workloads, but a lot of enterprises have an investment. Microsoft for AD, SharePoint, Dynamics, maybe some SQL server. So the reality of it is that even companies through acquisition, they're going to end up with multiple estates across multiple clouds.
So the question becomes, what do you deploy into what cloud? How can you be clear about that strategy? And not necessarily saying that we need to build everything so that it can run on multiple clouds, because that's a bit, I think that's a really dangerous fallacy, something people really need to be careful of because you have the potential there to waste a massive amount of engineering time in trying to be agnostic and building something that's generic enough to run on multiple clouds. Because you're already losing the benefits that each specific cloud provider gives you in their differentiating features. Is that fair? Absolutely.
For instance, one thing that I've seen is if we want to stick to the example of serverless, that even though on the surface, if you compare, for instance, Lambda with the serverless functions you get in Azure, they look quite similar. But then when you go a little bit deeper, the running model, it's so different that it becomes harder to kind of find a way to generalize your code so that it can run well on both models. So I wouldn't definitely encourage people to do that because it might be very tricky to get it right. And as you said, you're also going to lose some of the benefits because you're basically going to try to find that subset that works for both, but it's definitely a subset. So you're going to miss out the big picture. And yeah, on that topic, I'm curious to think, to discuss maybe with you, like what do you see as other issues that might arise from trying to be multi-cloud?
So I think where a lot of people come from with multi-cloud is from a fear that there's a risk there that at some unknown point in the future, some unknown event is going to occur, which will cause them to have to migrate away. And I think for any business, you can probably try and quantify that risk and be realistic about it. When you do the maths on that, you'll figure out that the likelihood of the event occurring is pretty low.
And the cost of switching, if you look at that and compare it to the cost you have to invest upfront in trying to be cloud agnostic, it's probably going to lead you to the decision that look, it's better off to be more agile and rapid in your product development now and just be more intentional about what you might do in the unlikely event that you will have to search away from your chosen cloud vendor completely.
And even if that event occurs, you're going to have time to do it. So I think being realistic about it, you can say, look, our focus typically is on, for the majority of enterprises and startups, it's about time to market and getting product into customers hands so you can iterate on it quickly. If you're spending, I would say 60% of your engineering effort trying to be cloud agnostic and building layers of abstraction for some event that might never happen, you're really throwing out your opportunity to be agile and get to market quickly.
So I think sometimes a lot of that is guided by maybe a misguided sense that there is a risk there, which really isn't going to happen. And I think once you accept that you're all in on a cloud vendor for any given workload, it suddenly takes away a huge amount of cognitive load that your developers, architects, and product managers have to think about, and you can really start going much faster. Have you come across a couple of cases where you've seen, I mean, one of the worst things for me is when you see a startup that's been getting some funding to build a product and they're investing it all in deploying Kubernetes clusters on three different clouds because they have some misconception that they're going to have to support them at some point in the future. Have you seen that?
I have seen that happening, but I've seen also the opposite where you have large enough companies that are more motivated by financial reasons in terms of, I don't know, are we going to lose leverage if we are logged in to AWS rather than another cloud? And that's maybe their motivation for trying to be more cloud agnostic so that they can maybe try to get discounts or, I don't know, get more things from the cloud provider.
And I don't know, that's kind of understandable, even though I think it's still not worth the investment personally. Most of the time, I think you're going to waste resources and time that you can spend, for instance, in terms of build more feature, make the product more optimized for the use cases that your customers have, rather than just making the software layer and the architecture layer so generic that it can work everywhere. And then one final remark I would like to make is probably that in general, I don't think I'm advocating for that needs to be only one cloud. I think the competition is really good and it's good to be aware of different clouds and what kind of features do they have and how similar services compare across multiple cloud vendors. Because I think we'll need that competition going forward because that's definitely going to help us to have better services across all the offering that you can get from cloud providers.
Again, don't pick your favorites and just stick to that without looking at the others. Keep looking at the other cloud providers and support them if you think they are doing something better than your favorite cloud provider. So yeah, competition is good, but don't over engineer your software and architecture just to be multi-cloud.
That's great. Okay, well, on that note, I think that's all we have today, but thank you very much again for listening and let us know what you think in the comments. Tell us what you'd like us to talk about in future episodes. Follow us and subscribe on YouTube and all your favorite podcast platforms and we'll see you in the next episode.
Use the arrow keys to move between transcript segments, Home or End to jump to the first or last segment, and Enter to seek in the video.
Help us to make this transcription better! If you find an error, please submit a PR with your corrections.