“Lock-in” comes because others depend on the benefit from your services, not because you’re completely in control."
- 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)
Vendors can't help doing this, it's natural. Also it's their duty to their shareholders.
Our responsibility is to NEVER get into this situation.
Very unlikely to happen because of fees, but plausible if the customer is high-profile enough that news about the move damage the reputation of the service provider.
Usually the new provider will advertise the win in such a way it highlights their competitive advantages. This can be extremely painful for the company that lost the very high profile brand.
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.
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.
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.
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.
Don't forget that it's easy to get killed on bandwidth costs when you suck your data out of one cloud and into another. Also, you have to be big enough to justify the spending money on engineers to make you multi-cloud, as you'll be implementing many features yourself, which takes a bunch of time.
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 same 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.
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.
Open standards doesn’t magically solve compatibility issues for very complex software: I remember ODT files having their layout completely messed up when opening them with a different version of Open Office. And this was minor version changes, not major ones. I had way less problem with modern variant of MS Word. That being said, I’m all for open formats.
Open standards doesn’t magically solve compatibility issues for very complex software: I remember ODT files having their layout completely messed up when opening them with a different version of Open Office. And this was minor version changes, not major ones. I had way less problem with modern variant of MS Word. That being said, I’m all for open formats.
Absolutely. The major difference is that one is a technical challenge, and the other was a marketing decision.
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 some other problem instead of your core problem.
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.
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.
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 will trade complexity for price eventually, once the price gets big enough.
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.
I just thought of it, but you know what would be nice, if people started posting their AWS/cloud provider costs.
Don't worry, they're doing everything they can to lock down Kubernetes as well. EKS, GKE, AKS... and the managers look at this and go "it's a managed service, we don't need to pay an engineer, buy it!"
Of course, the whole "not needing engineers" bit is a lie of the highest magnitude, but the marketing was really well done.
Could you expand on this? what do you mean by locking it down? EKS, GKE, AKS, and OKS (Oracle has their own now) and IBM's CKE are all wins to me. While I personally don't think people should be trying to tune Kubernetes into heroku (IMO you should build a layer on top of kubernetes for that), people are trying and succeeding in making it way easier to run applications on it.
Dumb managers are gonna do dumb stuff no matter what, but judging by how the widespread use of AWS did not in fact mean hiring less developers, it just changed the kind you needed to hire. I feel like the job posting just changed from sysadmin to sysadmin (for actual in-company computer management) + devops (for tech-side server management)?
That said, I'm also kind of waiting for the other shoe to drop on Kubernetes, it just seems too good to be true (minus the complexity of learning it of course). Well, thinking about it, I use gmail so maybe I traded my privacy in small part for this.
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.
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.
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.
There, open source, that's the key point to avoid lock-in.
There is no problem with going with any single provider, as long as you "can" replicate any functionality you're using. You may never actually replicate it, but that ability is what makes me trust a provider... because even if they fail, I know it won't be too much of a problem.
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.
Readit News
- 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)
Vendors can't help doing this, it's natural. Also it's their duty to their shareholders.
Our responsibility is to NEVER get into this situation.
Can any single customer smaller than the US government get a policy change at Amazon by threatening to walk away?
Usually the new provider will advertise the win in such a way it highlights their competitive advantages. This can be extremely painful for the company that lost the very high profile brand.
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.
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.
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.
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.
Absolutely. The major difference is that one is a technical challenge, and the other was a marketing decision.
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.
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.
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 will trade complexity for price eventually, once the price gets big enough.
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.
I just thought of it, but you know what would be nice, if people started posting their AWS/cloud provider costs.
Of course, the whole "not needing engineers" bit is a lie of the highest magnitude, but the marketing was really well done.
Dumb managers are gonna do dumb stuff no matter what, but judging by how the widespread use of AWS did not in fact mean hiring less developers, it just changed the kind you needed to hire. I feel like the job posting just changed from sysadmin to sysadmin (for actual in-company computer management) + devops (for tech-side server management)?
That said, I'm also kind of waiting for the other shoe to drop on Kubernetes, it just seems too good to be true (minus the complexity of learning it of course). Well, thinking about it, I use gmail so maybe I traded my privacy in small part for this.
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.
If you're looking for such a tool check out https://mist.io
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.
Disclaimer: I'm one of the founders.
There is no problem with going with any single provider, as long as you "can" replicate any functionality you're using. You may never actually replicate it, but that ability is what makes me trust a provider... because even if they fail, I know it won't be too much of a problem.