Recently, Google announced shocking new pricing for appengine that has its users reeling. In short, the new pricing means:

• “Free” quotas have been drastically reduced
• Pricing of paid apps increased significantly
• SLA and operational support available for a premium

Google has provided a tool so customers can compare their current bills versus expected billis under the new pricing and customers report anywhere from 3x to 30x price increases, leaving many scrambling for alternatives.

Two of the most common complaints from customers are lack of notice and the uncertainty of the pricing (lack of control over costs).

In terms of cost control, the only way to know how much your costs are, is to ask Google, after you have already incurred those costs (and built and deployed your app). It’s impossible to map users or usage directly to cost. Google’s pricing scheme is as inscrutible as the worst telephone company billing.

The pricing was originally planned to take effect in September, which only gave customers a few weeks to react. Google has provided optimization guidelines for customers to try to reduce their costs, but given the short notice, customers simply do not have time to make major changes to their apps. Companies already had their development resources planned out. They aren’t sitting around waiting for Google to throw a wrench at them. And it’s not clear how much further optimization will really save you anyway since a lot of apps have already received cost-cutting optimizations.

To me, I think this goes a long way to confirm some of my concerns about Google as a cloud platform vendor and as an enterprise vendor in general. A lot of people think anything Google touches is golden (especially Google, just ask them), but I think this shows how they still just don’t get it when it comes to providing commercial grade services. I have asked before, regarding many Google products, whether Google was serious this time. This is the risk to me of doing any business with Google. All these other non-search products are simply “tests” for them. A few billion here, a few billion there, throw it out and see what sticks. The problem is, if you latch on to one of these products and then it becomes critical to your business, you just never know when Google might, on a whim, go in a different direction, hanging you out to dry.

And that appears to be how a lot of customers feel about this move by Google, such as expressed in this post on the mailing list:

App Engine is finished, here’s why

What has always been the biggest concern about App Engine? Lock-in. You’re at the mercy of Google. Sure there’s TyphoonAE etc… but really those are not alternatives.

What does Google go ahead and do? They do exactly what their critics said they would do and what us GAE adopters hoped like hell they would never do, screw us over.

App Engine is finished not because we’re all going to move off to EC2, but because people who are considering using App Engine will see exactly what has gone on here with the pricing, think about the lock-in argument against GAE, and decide not to use GAE. There will be a drop off in new apps, and eventually Google is going to see GAE isn’t really panning out and pull the 3 year plug.

Thankfully, I don’t operate any services on GAE with high costs, but even as it is, I feel ripped-off for my investment in AppEngine. I do run some services on it, some of which I would rather not have to shut down, so I might have to move those elsewhere. And there are some apps I will simply shut down because they are not worth the trouble to port elsewhere. Some of those apps were potentially interesting and gathering users – in that sense, I’m glad this move by Google is happening now, before these apps got big enough to have to now decide what to do with them.

What’s worse for me though, is simply all the time invested in learning AppEngine. What a waste of time that appears to have been. As one developer says:

The biggest complaint is that when my friends and peers objected to App Engine, its strange requirements and its potential lock in, they were right and I am a fucking naive idiot. And I really don’t like to be proven a naive idiot. I put my faith in Google’s engineers and they have utterly destroyed my credibility. THIS more than anything is the cost to me.

In case it’s not obvious yet, this is officially a rant.  But I will try to keep it short, an “Executive Summary” rant, if you will. In fact, that’s all I have energy for anyway.

Sling a stale slice of pizza, and you’re sure to hit a slew of twenty-somethings that will tell you what a “super cool” language Python is and what an “awesome” platform Google App Engine is. Perhaps they’re right.

I won’t go into the Python language here. I will, however, simply quote from the unpublished rants of a well-known and well-respected author I was recently re-reading:

I think they should have just named the language “Underscore”.. and the source files could have a “._” extension.

However, Python is not the worst of GAE’s problems, not by a long shot. In the name of executive summary brevity, I’ll jump right in.

1. “GQL” and the Datastore – I don’t know who Google is trying to kid here by hinting that the “datastore” is somehow like “SQL”. God help you, if you fall into that trap. It must drive any real RDBMS expert mad.
2. urlfetch – only works on port 80 or 443 and times out after a few seconds.
   
3. mail.send() – can’t send to more than a few addresses at a time, whether invoked once for all recipients, or using multiple invokations.
   

All the above should be prefaced in the GAE documentation, in huge red letters: DO NOT EXPECT THIS TO WORK because they don’t, at least not in practice to do anything real.

In theory, Google says a request can run for up to 10 seconds. In practice, it never will because it will hit quotas before that, or it will fail because of urlfetch timing out if it makes calls to web services (like Twitter API, Facebook API, or whatever) on the back end.

Without this basic functionality, there isn’t much a GAE app can actually do, especially if it gets popular.  Without these functions, your app can’t connect to anything. It’s like a computer without the Internet – not very useful. And the worst of it is, you don’t find out they don’t work, until you get to the point of trying to actually use them, which means you’ve already put in all the effort to learn the platform and write code for it.  I say, for now at least, don’t waste you’re time, unless you are really bored and like punishment.

If your app is small enough, and doesn’t do much more than generate slightly dynamic content using templates, it might work on GAE.  Otherwise, stick to a real platform. Paraphrasing the words of a co-developer:

I think we’re at an inflection point:  forge ahead with GAE culture, or spend that time scaling and fortifying the app somewhere else.  I mean, if our app really takes off, we are unequivocally screwed on GAE; run over by a truck.

Google App Engine has promise, if they can resolve these issues (and a number of others I’m leaving out). It comes down to whether Google will get serious or not and that’s not their style or history, so we’ll see. This cannot be just another “G” self-service, zero-support platform, if they ever want to support real companies deploying real applications and services.

At the end of the day, Google teases, one might even go so far as to say tricks us, into believing they are providing a platform of substance and merit, only to disappoint those of us who took them at their word.

See Also: Aral Balkan – Why Google App Engine is broken and what Google must do to fix it.