You know what grinds Corey’s gears? MultiCloud, more specifically about how companies talk about MultiCloud. Everything from workloads to getting behind one cloud provider to the future. How should we actually talk about MultiCloud? This week Corey offers his perspective. Corey offers (rants about?) some options on how we should, can, and eventually will make best use of our cloud providers.
Episode Show Notes & Transcript
Corey: This episode is sponsored in part by our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they’re calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you’ve come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you’re using Elasticsearch, consider not running Elasticsearch. They’re also available now in the AWS marketplace if you’d prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Klarna, Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.
Corey: You know what really grinds my gears? Well, lots of things, but in this case, let’s talk about multi-cloud. Not my typical rant about multi-cloud not ever being a good best practice—because it’s not—but rather how companies talk about multi-cloud. HashiCorp just did a whole survey on how multi-cloud is the future, and at no point during that entire process did they define the term. So, you wind up with a whole bunch of people responding, each one talking about different things.
Are we talking about multiple clouds and we have a workload that flows between them? Are we talking about, “Well, we have some workloads on one cloud provider and a different set of workloads on other cloud providers?” Did they break it down as far as SaaS companies go of, “Yeah, we have an application and we’d like to run it all on one cloud, but it’s data-heavy and we have to put it where our customers are, so of course we’re on multiple cloud providers.” And then you wind up with the stories that other companies talk about, where you have a bunch of folks where their sole contribution to the ecosystem is, “Ah, you get a single pane of glass between different cloud providers.”
You know who wants that? No one. The only people who really care about those things are the folks who used to sell those items and realized that if this dries up and blows away, they have nothing left to sell you. There’s also a lot of cloud providers who are deep into the whole multi-cloud is the way and the light and the future because they know if you go all-in on a single cloud provider, it will certainly not be them. And then you have the folks who say, “Go in on one cloud provider and don’t worry about it. It’ll be fine. If you need to migrate down the road, you can do that.”
And I believe that that’s generally the way that you should approach things, but it gets really annoying and condescending when AWS tells that story because from their perspective, yeah, just go all-in and use Dynamo as your data store for everything even though there’s really no equivalent on other cloud providers. Or, “Yeah, go ahead and just tie all of your data warehousing to some of the more intricate and non-replicable parts of S3.” And so on and so forth. And it just feels like they’re pushing a lock-in narrative in many respects. I like having the idea of a strategic Exodus, where if I have to move a thing down the road, I don’t have to reinvent the data model.
And a classic example of what I would avoid in that case is something like Google Spanner—or Google Cloud Spanner, or whatever the one they sell us is—because yeah, it’s great, and it’s awesome. And you wind up with, effectively, what looks like an ACID-compliant SQL database that spans globally. But there’s nothing else quite like that, so if I have to migrate off, it’s not just a matter of changing APIs, I have to re-architect my entire application to be aware of the fact that I can’t really have that architecture anymore, just from a data flow perspective. And looking at this across the board, I find that this is also a bit esoteric because generally speaking, the people who are talking the most about multi-cloud and wanting to avoid lock-in, are treating the cloud like it’s fundamentally an extension of their own crappy data center where they run a bunch of VMs and that’s it.
They say they want to be multi-cloud, but they’re only ever building for one cloud, and everything that they’re building on top of it is just reinventing baseline primitives. “Oh, we don’t trust their load balancers. We’re going to run our own with Nginx or HAProxy.” Great. While you’re doing that, your competitors are getting further ahead.
You’re not even really in the cloud: you basically did the lift part of it, declined to shift, declared victory, and really the only problem you solve for is you suck at dealing with hard drive failure, so you used to deal with outages in your data center and now your cloud provider handles it for you at a premium that’s eye-wateringly high.
Corey: I really love installing, upgrading, and fixing security agents in my cloud estate. Why do I say that? Because I sell things for a company that deploys an agent. There’s no other reason. Because let’s face it; agents can be a real headache. Well, Orca Security now gives you a single tool to detect basically every risk in your cloud environment that’s as easy to install and maintain as a smartphone app. It is agentless—or my intro would have gotten me in trouble here—but it can still see deep into your AWS workloads while guaranteeing 100% coverage. With Orca Security there are no overlooked assets, no DevOps headaches—and believe me, you will hear from those people if you cause them headaches—and no performance hits on live environment. Connect your first cloud account in minutes and see for yourself at orca dot security. That’s orca—as in whale—dot security as in that thing your company claims to care about but doesn’t until right after it really should have.
Corey: Look, I don’t mean to be sitting here saying that this is how every company operates because it’s not. But we see a lot of multi-cloud narrative out there, and what’s most obnoxious about all of it is that it’s coming from companies that are strong enough to stand on their own. And by pushing this narrative, it’s increasingly getting to a point where if you’re not in a multi-cloud environment, you start to think, “Maybe I’m doing something wrong.” You’re not. There’s no value to this.
Remember, you have a business that you’re trying to run, in theory. Or for those of us who are still learning things, yeah, we want to learn a cloud provider before we learn all the cloud providers, let’s not kid ourselves. Pick one, go all-in on for the time being, and don’t worry about what the rest of the industry is doing. We’re not trying to collect them all. There is no Gartner Magic Quadrant for Pokemons and I don’t think the cloud providers should be one of them.
I know I’ve talked about this stuff before, but people keep making the same fundamental errors and it’s time for me to rant on it just a smidgen more than I have already.
Thank you for listening, as always to Fridays From the Field on the AWS Morning Brief. And as always, I’m Chief Cloud Economist Corey Quinn, imploring you to continue to make good choices.
Announcer: This has been a HumblePod production. Stay humble.