Hacker News Reader

This isn't our experience when focusing the application logic towards the client-side whenever possible and I don't agree GAE is only for prototyping/small apps. We started on EC2, two instances over a load balancer. We had to go for 2 medium instances as smalls couldn't scale fast enough when the traffic spiked.

We had to create the logic to deploy the application simultaneously to all running instances and writing monitoring code to ensure everything was scaling properly (the load balancer triggers just weren't up to it). Daily traffic 2k users, cost 200USD a month. About 4 non-trivial outages in the 5 months we were on AWS.

With GAE we push to git, deploy done. No setting up deployment, no complex monitoring for scaling. Daily traffic 15k users, costs 30USD a month. 1 non-trivial outage in around 20 months now, with 100% uptime during 2013.

We have run a reasonable scale, reasonable traffic production grade application for at least 5 months on both, long enough to make an extensive comparison for our application. GAE isn't perfect, but the cost savings in terms of our developer time make the charge-for cost savings (200 vs 30) look like very small fry.

That's the part I don't get about the grandparent's post. I've never had problems with outages on App Engine. It went down during the massive outage where half of Google's services went down. Other than that it's rock solid, and features get put in slowly.

Wow. That's a lot of hate toward App Engine!

I've successfully used (and am using) App Engine for a few projects. For prototypers and small-scale users like me, it's been a God-send. I'm not a developer with 15+ years experience, I'm an aerospace/nuclear engineer who taught myself how to code webapps. Developing the application code and the front-end code was difficult enough... learning everything I needed to know to keep an app from accidentally falling down of my own stupidity on the sysadmin side would have been a bridge too far.

I'm NOT saying App Engine is right for every project, every application, etc. It is NOT right for every project/application. And some of the interesting/unique features of App Engine (like the datastore) have now been extracted so you can use them as standalone products. A couple of high-profile startups have been built on App Engine (Snapchat, for one). But to take the challenges that exist around large-scale applications on App Engine and condemning App Engine for every possible use is a little unfair.

In my experience, it's brilliant for prototyping and small applications. And if you're sensible in how you engineer it, saying under quotas isn't that difficult for a lot of small apps, too.

> In my experience, it's brilliant for prototyping and small applications.

It's one of the worst PAAS ever,there is nothing brilliant in app engine.Everything is limited, clunky,with a horrible SDK one has to download in order to use the stuff...

> learning everything I needed to know to keep an app from accidentally falling down of my own stupidity on the sysadmin side would have been a bridge too far.

I fail to see how AppEngine does replace a sysadmin more than any PAAS out there.In fact,it's the one of the most complicated plateform to deploy on.

Frankly I cant even begin to think why anyone would recommand Appengine to anybody. This is just a bad product.Just looking at its admin dashboard makes me cringe. It's expensive,limited,complicated and boy it loves vendor lockin.

>Frankly I cant even begin to think why anyone would recommand Appengine to anybody.

It's awesome for tiny things where the free quota is enough. I have about 15 small app engine web apps, most written in python/flask, that are mostly used either only by me or maybe by some of my friends. All small websites, web apps or tools with a few hundred loc each.

The datastore APIs are nice and simple if you don't need much, it's easy to deploy, no management, easy APIs for stuff like cron jobs etc. and completely free with no way to accidentally incur costs. I haven't found anything better for that.

AWS has most free tiers only for 1 year and if you accidentally go over the monthly free tier it costs you something. With heroku (or openshift) you need to set up and manage stuff like databases, memcache and many of the useful APIs appengine provides yourself.

While I can totally see many use cases where GAE is bad, for small free web apps its really nice and by far the best thing I'm aware of.

> In fact,it's the one of the most complicated plateform to deploy on.

Can you elaborate on that? I've been using the Python runtime for some light traffic websites for many years now (since it was beta) and deploying is as easy as anything else. It's true you can't just git push your app to production, nor can you pip install the SDK, but I automated those pieces in one afternoon.

> It's true you can't just git push your app to production

wait, I've never actually tried doing it, but can't you do exactly that now?[1] Is there some kind of catch with it?

[1] https://developers.google.com/cloud/devtools/repo/push-to-de...

I believe that was released pretty recently and is still in the 'preview' phase.

I've been using it for ages.

Only for Java, AFAIK.

No. For all rintones.

I recently started prototyping an application on App Engine and quickly realized I'd rather be on Amazon infrastructure instead. The vendor lock in is extremely bad, but more concerning to me is how complicated their pricing is. It seems like it's nearly impossible to estimate your costs until you have real traffic, and by then you are locked in.

Take their datastore pricing for example:

Read / Write 0.06 per 100,000 operations

but what actual constitutes a read/write depends entirely on the operation

Entity Get (per entity) 1 read

New Entity Put (per entity, regardless of entity size) 2 writes + 2 writes per indexed property value + 1 write per composite index value

Existing Entity Put (per entity) 1 write + 4 writes per modified indexed property value + 2 writes per modified composite index value

Entity Delete (per entity) 2 writes + 2 writes per indexed property value + 1 write per composite index value Query* 1 read + 1 read per entity retrieved

It seems like it can get expensive very quickly, and that's just the datastore operations, it doesn't include the datastore storage or anything else you are billed for like instance hours or traffic.

What vendor lock in?

You can download the data from the data store and import it into another database. Sure you would need to write some code to interact with the new data services, but had you not deployed to app engine in the first place you would have had to write that code anyway. All the other APIs are optional and if you are worried about vendor lock in then implement them yourself (again something which you would have to do if not on app engine).

If you are on App Engine though chances are you will use the other APIs like the Taasks API. If you run your own software stack instead you can move it wherever without rewriting any code. With App Engine you either rewrite your code or use app scale.

But you don't have to use those!

Disclaimer: I'm part of the AppScale team, so somewhat partial to this topic :) Thanks for the kind words on AppScale: I'm very proud to be the last resort after google.

You mentioned App Engine's flaws. I understood price, and the sandbox restrictions, but you seem to imply the API is lacking also. Could you elaborate a bit more on it? What do you think is missing or lacking? What would you like to have that's not there?

The API is actually Open Source, Apache 2.0 to be precise, that's how AppScale could get started implementing the App Engine model. So why do you think it's a vendor lock-in?

> The API is actually Open Source, Apache 2.0 to be precise, that's how AppScale could get started implementing the App Engine model. So why do you think it's a vendor lock-in?

Its not trivial to create your own GAE-like implementation of the API with supporting infrastructure, so prior to AppScale, you had no options if you went down the rabbit hole too far. Now there are two options, but I wouldn't say just open sourcing the API solves all the issues... its the stupendous capacity/availability etc behind the API that people want to leverage in the case of Google.

I personally can't see many other vendors stepping up to write their own implementations of the API, with the supporting infrastructure... its not like the "proprietary" API is good/beneficial, or makes life significantly easier - at least, I didn't find that. I'd certainly prefer the tradeoff of maintaining my own VM/s versus the experiences I had with GAE.

We run 45 server instances and handle ~20 requests per second on AppEngine. Like many others we run Jenkins to handle our build and deployment. Appengine is not perfect but we spend the majority of our time focused on delivering business logic software rather than backend / infrastructure / scaling solutions. This allows us to keep our team small and increases our revenue per employee. Our experience has been that many of the idiosyncrasies you deal when first starting with AppEngine make scaling far simpler down the track.

Only 20 requests/second with 45 instances? That's horrible performance.

I've had the exact opposite experience, and the experience you speak of is the one I had with Microsoft Azure PaaS.

The only discontinued runtime was Python 2.5, and admittedly because of the lack of threading support it's cost went due to the way billing was changed. Upgrading to Python 2.7 was a piece of cake, and enabling thread safety returned the expense to reasonable levels.

App Engine was built for massive scaling, and anything like that is going to have tradeoffs and idiosyncracies. There's always going to be tuning and optimisations. As long as my sysadmin is kept to a minimum, I don't care. I'll leave Google to deal with outages and scaling, since they are an order of magnitude better at it than I am.

If you want exorbitant pricing with a good dose of headfuckery, deploy to Heroku.

Snapchat seems to run on app engine just fine.

I have an app (written in go) that can serve 200 req/sec on the smallest instance.

App engine works very well for me. I like not having to ever think about scaling. If i was anal about penny pinching (and if I was out of the free tier) then I could stick it in conpute engine and still have access to the data store but would have to manage the scaling and instance starting myself - at a reduced cost).

Pretty much experienced the same thing and have since moved to using a standard LAMP stack on Amazon EC2.

Seconded. Every word of it.

I was a fan of AppEngine in the early days, and built a couple of small projects with it. There is a reason they remained small.

Thirded. I suspect part of it is some people go into GAE thinking they can get away with the front-end instances only, which are limited in what they can do (can't open any sockets/files, limited third party libs as a result, a few other things which irked me that don't spring to mind), versus the compute instances (which in my understanding are more like a traditional VM offering, but that's credit card territory, no prototyping there afaik).

One example is the authentication API being awkward, it seemed like you had to choose [1] either Google's authentication, Google App's authentication or OpenID (you can roll your own auth, its just not obvious from the scrappy admin console - I got the distinct impression they were rushing to bolt things in there w/o putting too much thought into it).

An app written for GAE is going to be pretty painful to port elsewhere as a result of the APIs you have to code to as a result of those limitations (well, now you can port to AppScale pretty easily I guess). The whole thing did feel like a lock-in attempt to me.

I also had to try and estimate the costs a client would face based on requests/minute and some other metrics, and it was tough; basically boils down to 'suck it and see' for a realistic estimate.

For prototypes/pure frontend apps/wikis/static content I'd probably still use it (with some defensive coding to make moving it easier if needed), but I found it pretty frustrating all around when you need to move outside their box.

1. https://developers.google.com/appengine/articles/auth

You can open sockets.

Let me guess - bad product-market fit?

Didn't have time / resources to find out. GAE consumed a lot of my time (until I realized it).

Secret also runs on App Engine.

I don't think they can change prices or discontinue the service the way you imply.

Historically, they have: http://www.informationweek.com/cloud/platform-as-a-service/g...?

That was supposed to be a one-time repricing and Google put in place some policies for pre-announcing future price changes or deprecations. http://googleappengine.blogspot.com/2012/04/app-engine-and-g...