ref https://news.ycombinator.com/item?id=14356409
Vendor lock-in can make or break startups if you're not careful enough.
And it's often worse for bigger companies. Startups can often just rewrite their crap. You can't do that overnight with several years worth of legacy systems if they rely on vendor-specific features.
The odds may be low, but there are vendor lockin scenarios that sink a company fast. Having experienced that once you don't want that sense of powerlessness again.
The part where I agree with the sentiment in this chain is where people try to avoid this by putting in big abstraction layers of custom crap.
It's possible to use Law of Demeter principles to keep the vendor details of a lot of subsystems from leaking across your entire app. But that requires architectural skills that are de-emphasized in the Ship Every Week world we live in.
(I'm not implying causality there, or maybe the causality is in the other direction. These things are hard to learn and harder to teach and if you can't get one thing you try something else.)
There's certainly a continuum here. The most minimal risk mitigation strategy is simply to use your own domain (as opposed to the vendor's domain), and that requires nearly zero effort. Unfortunately the team in that article made that mistake, and they're pretty honest about admitting it.
Assuming you don't make rookie mistakes at the beginning, you always can move to another platform - it's just a question of how much work it will take. Is it better to put that work in up front for the 0.01% chance you'll need it? I think not.
The recent 12 x Google Maps API price hike is another such "exception that proves the rule" apparently.
Over a sufficiently long time horizon, the chance is much greater than 0.01% and the longer you go without doing the work, the more it costs to do the work.
Sure, it's more a problem that bites you when you've become a big enterprise, but it bites hard, and some of us work in big enterprises on systems that could reasonably be operational for generations going forward (and perhaps have been going backwards.)
And that's the right choice in some cases. But the added up-front effort can be a lot less than the added reengineering effort, and growing into a big enterprise doesn't mean you are immune to disruption by more agile startups.
And, of course, those who are already in big enterprises have different concerns (while premature adoption of the mitigations at issue can be engineering resume padding in startups, deferring it with the hope that it won't be a crisis until it's someone else's problem in exchange for short-term metrics can just as easily be management resume padding in enterprises.)
I don't think it's 100x or even 20x less work.
Depending on your perspective, that might also be a small amount, but let's not misrepresent the situation.
The anchor in the metaphor is using large tech conglomerate without being able to quickly pivot away from them at a moment's notice.
How much did it cost to engineer your product to not "tie an anchor"?
My guess is, you didn't "save" anything trying to build out several layers of abstraction to deal with a hypothetical risk of getting screwed by "large tech conglomerates".
Spoiler: Answer will be "no".
I've seen companies get far more burned by these homebrew monsters than I've ever seen them get burned by "vendor lock in".
If I see some custom framework it’s usually an instant facepalm.
- performance is a feature
- reliability is a feature
- security is a feature
- and lastly, cost-effectiveness is a feature
If the app is to be used through wide range of regions, you want geographically close datacenters for low latencies. If the app is to be used for mission-critical purposes, and contain sensitive data, you want high assurance and privacy[0]. And lastly, the cheaper the app is to run and maintain - and that includes not just the infrastructure bill, but also availability of engineers who know the platform well[1] - the better you can develop the same app within the given budget & time.
[0] there are some legal compliance requirements for handling medical data
[1] one of the reason Windows apps are rather cheap and plentiful - there's wide availability of engineers who know the platform well. Likewise for certain popular web stacks.
That's not a given. It's plenty common to have the most often used features (say, sub-pages, or key processes) optimized the best, with the rarely used ones lingering at low optimization. User behavior is non-linear; small changes around pivotal values can yield great results. Over-optimizing on the other hand yields diminishing returns. Making even just your home page snappy can greatly improve conversions (or whatever is your success metric).
Other than that you are right that a bit of optimization here or there can save a lot of costs. I distinctly remember certain popular phpBB forum that, while quickly growing the userbase, somehow managed to still improve performance on rather measly hardware - and without much horizontal scaling! - getting in return genuine praise from the users, and also keeping the cost & complexity in check.
Bad engineers care about vendor lock-in, because they want to pad their resumes with abstraction tools.
Good engineers care about vendor lock-in, because all cloud providers have limits you do not control. Your architecture can become insanely expensive or simply stop working if something you do grows beyond one of those limits. In those cases you can either re-architect the whole thing or simply switch vendors.
This is one of the hidden costs of "cloud" platforms everyone suffers from but no one talks about.
(Flashback to my ITIL instructor in 2008 talking about Service Catalogs and how they are meant to include even discontinued products. "Will Microsoft support Windows 3.1 for you today? YES! Bring money.")
> If we grow so large that we hit the limits of whst AWS can handle, I think we will have enough investor money flowing in to be able to afford rearchitecting.
Apparently you think you're in danger of that happening, so what makes you think you can buy time with money?
That's literally what you said in the post I quoted.
> As if some how that same business could build out a data center that could scale better than AWS or Azure.
You're the only one straw-manning this with on-prem. The whole context of the discussion is around being able to move between cloud providers. Why are you bringing a point into the discussion nobody else thinks relevant?
You can easily grow so large that you hit a limit of what a given cloud provider will allow (e.g. API calls or IOPS) at a price that fits into your budget for a task, even if you're not actually especially large.
My response was that what are the chances that a company will grow large enough that it will outgrow the resources of a cloud provider?
And there are really only three cloud providers worth discussing - AWS, Azure and Google. Besides Google (and if you based your business around then you get what you deserve) what cloud provider has raised prices on a whim? Which provider’s cost are so out of line with the other that it is worth the switching costs? Besides, if you’re that large, you’re paying negotiated prices not published prices.
In fact one post was specifically about building out specialized infrastructure at a colo.
https://news.ycombinator.com/item?id=19731913
If you’re so large and you are going through the costs and risks to move off of a cloud provider, why put yourself in the same position again by migrating to another provider?
You naively assume that hosting something at AWS or Azure means all of their resources are at your disposal and subject to reasonable pricing. That is not the case. Cloud services are not designed for you. They are designed to make money for whomever actually owns them. They have their own architecture, assumptions and target use cases.
In reality, the chances that a large company will eventually hit some limitation of AWS or Azure are nearly 100%. The only question is whether it will be something that can be worked around.
One problem with "the cloud" is that a lot of the limits are no-obvious, and if your use case significantly deviates from whatever the provider had in mind, there might not be an incremental solution.
Another problem is that linear resource pricing is not always sustainable if you're experiencing exponential growth.
So if I’m “naively” assuming that you should be able to cite a real world case where a company needed more resources than AWS or Azure is willing to provide.
“Reasonable pricing” for any supplier that a company uses is a price where the company can pay their suppliers, do something to add value, and make a profit.
Cloud services are not designed for you. They are designed to make money for whomever actually owns them. They have their own architecture, assumptions and use cases.
Guess what? All of the suppliers you use for your business are in business to make money. And if your use case doesn’t fit within their managed services offerings, your escape hatch is to bring up a VM and install whatever you need on it.
In reality, the chances that a large company will eventually hit some limitation of AWS or Azure are nearly 100%
Where are the case studies?
The problem with "the cloud" is that a lot of the limits are no-obvious, and if your use case significantly deviates from whatever the provider had in mind, there might not be an incremental solution.
Every time I log on to AWS, and go to the support page, I see our account based limits. The non account specific limits are publicized. Which specific limits are you referring to?
As far as working around unknown limits of off the shelf managed services - that’s why companies hire programmers.
Another problem is that linear resource pricing is not always sustainable if you're experiencing exponential growth.
And if your marginal revenue is not exceeding your marginal costs, that says more about your business model than anything else.
https://firstround.com/review/the-three-infrastructure-mista...
It makes it easy to do things like user identity. Authentication. Queueing. Email. Notifications. Seamless databases. These are all lightweight services that can save you a lot of time, but only if you’re using AWS. The magic (for Amazon) is that they deter people from migrating despite mounting costs for storage and bandwidth.
All of those lightweight services have publicly accessible endpoints that can be used in conjunction with self managed infrastructure either over the public internet, a VPN or a direct connect.
But, your contention that you quoted was that AWS/Azure “wasn’t willing to provide it”. Yet you posted an article where the cost of providing it wasn’t conducive to their business model.
Then I could always post about a little streaming service you might have heard of called Netflix that has all of its infrastructure besides its caching servers (that are colocated at ISPs) on AWS and the reason they decided to move to AWS.
https://www.se-radio.net/2014/12/episode-216-adrian-cockcrof...
But really what does it say about a company that is growing fast unprofitably? Were they profitable when they were spending $20K a month?
For FaaS in particular, if designed and factored correctly, I think the cost to move clouds can be minimized without building multi cloud capability upfront.
You have evaluate the probability of a risk occurring, and its impact to your business. Small-time service providers get bought out and close shop left and right.
Think of it like a backup, only instead of a hard disk failure you are insuring against a vendor’s market power.
Yes, I worked at a place where both of those things were true.
Switching some services out to a service (in this case, Azure functions) saved my company like $10k/mo, too.
In the end it's about taking calculated risks, and concentrating on where your effort and capital are most effective.
Virtually nobody thinks of the Fail Whale as a real risk now a day.
This company builds a team vacation tracker. As long as it's reliable, their customers could not give a rat's ass whether it runs in AWS, Google, or Joebob's House Of Ill Compute. Every engineer hour spent creating abstraction layers and docker containers and whiz-bang multiplatform plumbing is an hour that could have been spent working on something your users actually care about.
Switching clouds is a cost optimization. You have to be an enormous company (or in a resource-intensive domain) before this is more productive than building features. It means you've moved out of the growth phase and into the "how do I milk what I've got" phase.
Vendor lock-in is something that engineers care about because they like playing with tech. It's cool switching platforms or databases or whatnot because it really feels like hard, sophisticated work! But it doesn't move the needle.