App Engine was in preview when its price changed.
During those 3 years no warning was given that the pricing changes were going to be of such a magnitude.
As a result people had sufficient time and not enough warning to build entire businesses on an infrastructure that they later had to abandon.
That's unforgivable.
App Engine has always been a unique PAAS because its APIs were designed to try to force developers into better distributed app architectures. The non-relational DB with entity groups and limited queries, the 30s request limit, originally not offering long-running instances, the task queue, memcache as a service, all made for scalable apps.
But the costs unfortunately weren't designed the same way. Charging by CPU time, and having datastore access free was especially bad for a market where apps typically use very little CPU, but access data a lot.
A lot of blog posts came shorty after the price change that said after making the recommended changes to datastore calls, and enabling multithreading that they got their bill down and performance up significantly. Many apps were doing absolutely no caching, or logging every request to the datastore, because datastore was ridiculously cheap for small records. Some were doing what should have been batch work per-request because they didn't use task queues.
Since 2011, I think all price changes with Google Cloud have been price drops, some pretty big. Last year, App Engine prices were dropped 30%.
The users didn't decide any of these things, and are not to blame for them. What kind of service blames its customers for its own mistakes?
Google earned this distrust fair and square by suddenly forcing huge numbers of customers to rewrite all their existing code. Little price cuts don't matter: other services are already more cost-effective and are cutting their prices all the time, but even if there were price parity the risk attached to the lock-in just isn't worth it.
https://plus.google.com/110401818717224273095/posts/AA3sBWG9...
As for the unique API, of course some of it's unique, because there weren't any standard APIs for the unique parts. Datastore is based on Google's internal NoSQL store. There's are/were standard APIs for NoSQL. Same with Task Queues.
The "proprietary API" bit is overblown though, IMO. The Python version shipped with a somewhat tweaked, Django support, and has grown to support WSGI and standard Django. The Java version uses Servlets with some constraints. Memcache is pretty standard. You can pretty easily abstract away the proprietary bits to run on a standard stack, or use an open source implementation of the APIs.
http://googleappengine.blogspot.com/2011/10/app-engine-155-s...
The price increase also came with an SLA. Just to be clear, you're saying that businesses were entirely built atop a product with no SLA, and that's not the bigger problem?
Frankly, if your business is built entirely around a single 3rd party provider, and you are totally incapable of pivoting cloud providers at short notice... well then you are "doing it wrong".
Could you elaborate a little?
Netflix doesn't rely on a single provider for hardware, data centers, nor bandwidth. Sure they use EC2 for some things, but also have a great deal of hardware in data centers throughout the country, as well as custom hardware in ISP data centers, etc. I'd be shocked if there didn't use some of the other cloud provider offering too.
Netflix has no single point of failure.
Building your business around a single cloud provider creates a single point of failure.