“Lock-in” comes because others depend on the benefit from your services, not because you’re completely in control."<p>- this is hopelessly naïve. Lock-in occurs when you no longer can generate the capex to resolve the opex drain that a vendor squeezing you has created. If any vendor realises that you can raise the capex to get off them then they will raise the opex demand to the point of financial viability to maximise their returns and to ensure future returns (because by doing this they underline their control)<p>Vendors can't help doing this, it's natural. Also it's their duty to their shareholders.<p>Our responsibility is to NEVER get into this situation.
There are some good arguments about the technical complexity of using multiple clouds. But the author seems to be naive about the power of competition, or more appropriately, the problems associated with having no competitive pressure on vendors. #1 priority of any business should be to have as few sole-source suppliers as possible.<p>It seems cleaner to go all-in on AWS/Azure/Google/Your Datacenter/something else. But the reality is, if you have a significant spend, and are dependent on one vendor, you are truly fucked. You won't get good terms, you won't get good pricing.<p>This industry goes through this cycle again and again. 30 years ago, people bet the business on Oracle/Informix/DB2/Sybase. Oracle is the king of that hill, and we all know the stories about how great they are to work with. 10 years ago we started with Office 365 and it's predecessor. Ask a big Office 365 customer how their subscription renewal process went.<p>Cloud is no different. Unless you can tell your AWS rep to go fuck himself and move workload elsewhere quickly, you are giving up valuable leverage.
I think many people coming up these days never really felt the effects of Vendor Lock-in. Everything is either an open enough standard or dominated so thoroughly by one player that there is no option anyway. I remember my printer not working, and saving my report that I wrote in MS Works on a floppy disk. I assumed that the computers at school would be able to read it. They had Word Perfect, and MS Word, I mean one was the <i>same</i> vendor, and it still didn't work. That was over 20 years ago, but I still cringe whenever I see someone using any kind of closed standard.<p>The idea of starting out with a single provider until you actually have things working is probably a good idea.
But, I'm surprised that more companies with a certain level of steady traffic don't run their own hardware and spillover to the cloud for spikes.
Multi-Cloud isn't a trap any more than any other practice is a trap. Any practice is a trap if it takes away from your core mission too much or requires resources you don't have. I call such things "engineering bikeshedding" -- solving <i>some other problem</i> instead of your core problem.<p>I think doing multi-cloud for something "normal" and mundane is probably over-engineering. If you want to avoid vendor lock-in just avoid using the most proprietary features of your cloud vendor, or use them in ways that would not be terribly hard to port later (e.g. it's not hard to swap something else out for S3). Yes your DC or cloud provider will have issues every once in a while, but in the grand scheme of things it won't matter unless your service is one that demands damn near 100% uptime as a strict requirement.<p>Multi-cloud makes sense when you need near-100% reliability. There are few things where reliability requirements are this stringent. It can also make sense when you need a great deal of geographic diversity or portability.
My company is was full on into GCP and after a year of terrible support management suddenly decides to go all in into Azure. We use every managed service from GCP including BigQuery which is nearly impossible to find a replacement of in Azure. Appengine needs to be converted to Azure Kubernetis Service. So its not a technical decision completely, just that company signed a bigger deal with Microsoft and wants to pay a single bill. Based on feedback from other teams company feels Azure support is way more professional when it comes to production outage. Now all of 3 years work sing Google services needs to be re-written in "cloud agnostic" way.
For those that avoid the "cloud-native" hype, this is one of the reasons you should -- while this article rails against multi-cloud, as other posters have noted, it's important for preventing lock-in and keeping competition alive and prices down between providers.<p>I'll go one step further in saying that it's an inevitable future. The likelihood that one cloud will have the best price, best components, best qualities for every use-case is just not very likely. People <i>will</i> trade complexity for price eventually, once the price gets big enough.<p>The good news is, kubernetes is fast appearing to be the winner of the race for a multi-cloud substrate. The bad news is, kubernetes is complex (IMO necessarily so), so it takes quite a bit of investment and mindful practice to learn.<p>I just thought of it, but you know what would be nice, if people started posting their AWS/cloud provider costs.
Multi-Cloud can be hard to do right and there are plenty of traps along the way. It sure doesn't make sense to go that way just for Disaster Recovery, unless you need to be prepared for the unlikely event that Amazon or Google will suddenly get wiped out of the planet.<p>That said, going Multi-Cloud is indeed unavoidable in a growing number of settings. So, instead of looking at it as a source of troubles, it can be leveraged as a way to extract the best features out of each provider, to avoid lock-in wherever it makes business sense and to minimize costs by distributing workloads accordingly. That introduces new issues regarding access control, cost analysis, auditing and governance which are best managed by a Multi-Cloud Management Platform.<p>If you're looking for such a tool check out <a href="https://mist.io" rel="nofollow">https://mist.io</a><p>It's an open source CMP that supports most popular public & private clouds, as well as Hypervisors and container hosts. It takes care of provisioning, monitoring, RBAC, cost analysis and automation/orchestration. It can also be used to deploy Kubernetes clusters on any supported cloud.<p>Disclaimer: I'm one of the founders.
This is a naive point of view. Cloud providers can and do raise prices when it aligns with their objectives. Especially Google has the history of doing this. Make a very strong product, offer it very cheap and then when all the competition has died, raise the prices. Google Maps is one recent example.
Excellent, excellent point. This is a drum I'm starting to beat more and more as companies start viewing multi-cloud as some sort of ridiculous best practice.
I’ve found virtually every vendor I deal with starts abusing their power until they receive an RFP that lets them know they’re in competition. The cloud salespeople I’ve met are no different.
Do people honestly do this? If they do, do they not take advantage of the platforms' services or do they rewrite all their code to the use each cloud's specific service (e.g. Kinesis vs Pub/Sub)? Or are they use using compute resource and running the services themselves? If it's the latter, isn't that as close you need to get to get to prevent vendor lock in? Deploy your code on any cloud and you're going...