> Due to a change in how they report data usage, our monthly costs for Firebase, a SaaS provided by Google, has increased from $25 a month to what is now moving towards the $2,000 mark — with no changes to our actual data use. This change was made without warning.
>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.)
Perhaps this is the "exception that proves the rule"? That situation was unusual enough that one of the Firebase founders reached out and gave them a bunch of credits and helped them work through the issue.
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.
> Is it better to put that work in up front for the 0.01% chance you'll need it? I think not.
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.)
> I would happily accept that problem if skipping the extra work enhances my chance of becoming a big enterprise in the first place.
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.)
Vendor lock-in at the level of Google, Microsoft or Amazon is not the same as becoming overly reliant on a single small factory down the road providing a critical sensor.
That's a cost increase of $23,700 per year. Certainly not trivial (especially for a startup), but that's 1/5 of the cost of a junior engineer in a low cost-of-living market.
But the all-in cost in terms of administrators, managers, healthcare, mentoring and employment taxes raises that quite a bit, probably closer to the 120k number than the 60k number.
> The question should be how much you can save by not tying an anchor you don't control the weight of around your neck in the first place.
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".
Did you even read the comment? A change in firebase pricing increased the cost by almost an order of magnitude. I don't know how it affected the upper tiers but if you imagine a larger startup with much higher traffic, an unexpected price increase like that could break the company.
ref https://news.ycombinator.com/item?id=14356409
Vendor lock-in can make or break startups if you're not careful enough.