Once you have any type of meaningful infrastructure you’re already not going to migrate without major pain between data migrations, networking, security and compliance audits, retraining, etc.
And if you are only using one of the major cloud providers as a glorified colo, you have the worse of both worlds - you’re paying more for infrastructure and your TCO is no lower because you’re still babysitting infrastructure.
Even almighty Amazon took a decade to move off of Oracle. Concentrating on avoiding being tied to Oracle early on instead of building a business would have been silly.
Trying to avoid “vendor lock in” when you’re still trying to grow your business, when your focus should be trying to acquire customers, and raise revenue and profit is the ultimate premature optimization.
I also haven't seen the reverse, the multi-cloud people who later on drop a cloud provider because of some reason, going "omg, thank goodness we didn't let ourselves be locked in to one, this saved so much time/money/effort".
it depends on your core business. Don't be "vendor locked-in" for any core business competencies. But do get "vendor locked-in" for non-core competencies. If you're core competency is merely just white-labelling another business's offering, then obviously it's a bad practise. But for things that are easily commoditized - like CRM and payroll, why not be "vendor locked-in", and save the cost of development, and enjoy the lower scaling cost?
If the price per seat is 5.00 dollar per person and next month it could be 5000 because they require you to pay surge pricing getting locked on could kill your business quickly.
Do any cloud providers have surge pricing? (I've not read to many SLAs myself.)
AWS has never raised the price for a service since it existed.
I can still launch old instance types which are no longer listed. Same with SimpleDB still works.
It basically a fixed cost imposed by the cloud providers.
I.e. when the economy contract, and yet AWS/Azure profits are growing, this is the pain of vendor locking.
How many companies that were on such thin margins between surviving and going out of business that cutting infrastructure spending by 10 or 20% was going to make a difference in them being able to survive?
Which is, vendor locking did not show itself, because the economy was good.
Any large company depends on literally dozens of vendors that they have tied their business process into where it would be a major pain to switch.
I know in the health care industry, a lot of health systems are so tightly tied into their EMR/EHR, leaving a something like AWS would be a breeze.
Smaller companies often run leaner. Except maybe for big airlines that spent their surpluses on stock buybacks and executive pay increases.
There was something in the last month where somebody closed their company because such a mistake took them through many months worth of bootstrapping budget.
I don't know if that counts as regretting the lock-in, but I guess they regretted something about their cloud provider.
Did that for a web startup. Tens of services, 200 instances.
Estimated 1-2 weeks to move to another cloud provider (Google/Azure) and be back online for customers.
100-200 VMs - especially if they are all based on the same few image is easy.
I am considering a disaster recovery scenario. Like AWS banned the account or all the resources were deleted. There is nothing to do but to start over from scratch, every single employee is onboard to help and get their bits of services back working. Audits is not a rebuild step, it's something to arrange much later.
In general, if you build apps with open source runtimes, use open source dbs, and avoid the proprietary data services cloud providers really stick you to, you can move around pretty easily. And you still reap most of the benefits.
The real problem with the special AWS services is you end up having to hire AWS ops people or expensive consultants to architect around them and run them for you. So it's proprietary AND eating up salaries.
But stuff like SQS and (to a lesser extent) Lambda is really hard to replace because it's thoroughly baked into an application architecture.
As an example, we (fly.io) have a tool that'll hoist a Fargate app into our infrastructure and let you run it all over the world. We even have people tunneling back into their VPCs to access other AWS services. But that only works because we're both somewhat standard, Fargate takes a Docker image and runs it, Fly takes a Docker image and runs it, the app inside doesn't care about either of us.
Have you actually costed out how much a large migration would take?
As far as using Lambda for an API, you can literally add three or four lines of code and use “proxy integration” to deploy your entire Node/Express, Python/Flask/Django, C#/WebAPI app on lambda and without changing any code, deploy it anywhere else as you would any other API.
Here is a Node Express example.
And, most of what you're talking about doesn't really affect margins for a SaaS. Every AWS service hits margins, one time migration costs and even R&D time to build products does not. The marginal cost of using AWS underneath interesting features is very high.
Every dollar you spend on R&D or migrations you have to consider whether that dollar could be better invested somewhere else and whether it adds business value to have the expertise in house or to outsource it.
Dropbox and Backblaze for instance decided that storage was a core competency. Dropbox moved away from AWS and backblaze knew from day one not to get on it.
On the other hand Netflix went the other way and is now AWS’s largest customer.
Here is the sum total of how much “work” you have to do.
const awsServerlessExpress = require('aws-serverless-express')
const app =require('./app')
const server = awsServerlessExpress.createServer(app)
exports.handler = (event, context) => { awsServerlessExpress.proxy(server, event, context) }If you build the app around e.g. Lambda and DynamoDB, in contrast, you're going to have a harder time both because you need to restructure the code but also verify that what you switched to doesn't have key differences in how things operate.
Dynamo is tough. At the same time, it's really really good.
A cheap VPS provider or a colo do not give you storage and networking. There is no cheap and no open source solutions to do any of that.
It's impossible to use a cloud provider without using any of their managed services; if you are using EC2 or a similar IaaS as if it were just a basic VPS, you'd probably be better off (cost for the use) with a basic VPS, but you'd also probably be better off with Amazon LightSail, which more closely approximates a basic VPS service.
What more is EC2 than a virtual machine? Sure you have it tied into IAM that's tied into firewalls and whatnot, but that's doesn't make it radically different from a VPS.
We build an open source solution[1] to deploy autonomous Kubernetes clusters into on-prem or air-gapped environments but it's also useful for limiting cloud lock-in (even has its own "IAM" built in). Of course, you have to also limit your use of proprietary services (which definitely has its trade-offs) but might be worth poking around if you believe reducing lock-in is worth it.