That's the same, old vendor lock-in approach. It has happened with the servers, databases, network equipment etc. now it happens with cloud -- nothing unexpected, prepare to see more of these when cloud market stabilizes and clear leaders emerge. That's why I always prefer open solutions, that can be moved/migrated/replaced easily and advise others to do the same.
Eh, it looks like the service provider hadn't taken into account an oddball use case in the pricing / metering, and then suddenly did.
They certainly should have communicated that better and their tools / charts should have a way of showing the billable data, but it's a bit of a stretch to call it vendor lock-in. It's not like everyone on Firebase is complaining and the author admits they made major mistakes.
Just "communicating better" is not a reasonable response to making such a dramatic change in how much money you charge someone. If I tell you I'm going to punch you in the face, that doesn't make the punch acceptable behaviour.
Cloud services that pull this kind of bait and switch deserve to be ridiculed and lose lots of business over the negative PR. Cloud services that unintentionally pull this kind of bait and switch but then don't make it right or provide meaningful support deserve no special treatment.
From the GGP and some of your other comments here, it seems like you are arguing that communication is the main problem here rather than the change itself. Sorry if that was a misunderstanding.
But why do providers get a free pass when they do a major mistake (à la GitLab losing tons of not-backed-up data), but customers are required to accept whatever the provider throws at them? It seems pretty unfair to me.
Providers to some degree get a free pass when they do their best to fix their mistakes.
In Gitlab's case, their response was excellent and their total data loss was less than a day's work - and even that only for a full time manipulator of gitlab metadata (project managers? some parts of QA?): "Database data such as projects, issues, snippets, etc. created between January 31st 17:20 UTC and 23:30 UTC has been lost. Git repositories and Wikis were not removed as they are stored separately." ( https://about.gitlab.com/2017/02/10/postmortem-of-database-o... )
Considering that "[...] out of 5 backup/replication techniques deployed none are working reliably or set up in the first place." ( https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCx... ), this was a pretty amazing result, and about the best a response they could make. That, combined with their transparency, earns something of a pass (especially when data loss I care about is already limited by git's DVCS nature, even if they had obliterated the repository data.)
In Firelab's case, if no other action is taken, they've actively mislead their customer in failing to follow through on crediting their account, charged them an obscene and unsupported price hike, and gone incommunicado. That's like... an anti-pass.
Chances are they also knew when they fixed the bug that it would result in price hikes. They could have easily generated a report showing which customers would be impacted, allowing them to contact them ahead of time.
I don't think they should get a free pass, but I don't think they should be beholden forever to be under-metering traffic if they made a mistake and weren't counting part of it (as it seems to be the case here).
To that extent, they should have communicated this better, ideally 90 days out perhaps even with phone calls for customers whose bill will increase notably.
I'm not implying that this was made on purpose -- vendor lock-in might happen "naturally" as well, when company becomes big enough that they can start unilaterally change prices/conditions/services knowing that costumers will accept that (even grudgingly), because they have nowhere else to go or it is too expensive/complex. Google is the perfect example of this strategy. Smaller player or startup would probably go bankrupt very fast if acted with such disregard for their costumers.
So far I've seen only one customer notably affected, and (judging by the post) I doubt they'll be sticking around on Firebase. There are a lot of take-aways for this story, but I don't think "vendor lock-in" really fits.
