Hacker News new | ask | show | jobs
by pekk 4044 days ago
It was Google, not the users, which set the old pricing model which people optimized for when they wrote their apps. Many apps which had to be shut down were already doing "right" things like caching, using task queues, and economizing on datastore accesses. It was Google, not the users, which designed App Engine so that porting away would essentially require a rewrite. It was not the users but Google which neglected certain popular language runtimes so that they were no longer cost-effective after the price hikes. And it was Google, not the users, which kept the issue opaque so there was no warning of how big the price hikes were going to be. If certain users found that they could sustain a double or triple bill, that doesn't mean it is the fault of the other users that they were forced to mothball their apps.

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.

1 comments

I don't think they are blaming the customers, and if you read posts from back then, I think they take a similar tone: they didn't get the pricing model right, and in order to make App Engine a real sustainable product with an SLA, they needed to update the pricing.

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.