If you don't know already, the primary use of AppScale is to try to salvage legacy App Engine applications from Google's awkward, under-supported, exorbitantly priced and now moribund App Engine hosting. I'm not writing this to attack AppScale, as it's providing a valuable service to App Engine users, but I don't want anyone to be harmed by the decision to build on App Engine.
Think carefully before you build new projects on App Engine APIs. The idea that you will get more affordable scaling than other services without system administration is a complete fantasy. By the time you're deploying AppScale the fantasy is obvious because you are now doing all the normal work of scaling and normal system administration, and also the work of dealing with App Engine's flaws. But if you are green enough to get taken in by the fantasy once, then it probably won't be dispelled until after you've already lost months to years wishing you had chosen something else.
First you pay a heavy cost in extra development time to work around App Engine's idiosyncratic APIs, bizarre restrictions and quotas. Then you pay fees which are exorbitant by comparison with what you will get almost anywhere else. Then you may discover that support for the runtime you are using is lagging in a way that doubles your bills, and will never be fixed (and App Engine will never again have close to the interest and staffing it once had). How does it sound to rewrite in another language? Then you will discover and have to work around frequent service outages using the limited tools provided. All this with Google's famed lack of support - unless your spend is extremely high, which means you're losing even more money for having chosen App Engine. And let's just hope Google doesn't double, triple or quadruple monthly bills again.
If you run into any of these problems (and you will), you're stuck and your only real option is to move platforms, which means most of your code will have to be rewritten. AppScale is a final resort; there is no other option. If that doesn't work well for you, notably if the overhead of AppScale itself costs you too much, then you are still going to have to rewrite most of your code. If you don't already have a lot of App Engine code you can't replace, it isn't smart to plan to run a huge AppScale deployment.
If you think you will be doing a large deployment then you should look at technologies which were developed in the open from the beginning and which still have a lot of active momentum. Or just use normal Linux boxes and worry about scaling issues as you need to, like everyone else. Just don't get locked into weird vendor-specific APIs like App Engine.
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.
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.
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.
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.
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.
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.
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).
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.
Think carefully before you build new projects on App Engine APIs. The idea that you will get more affordable scaling than other services without system administration is a complete fantasy. By the time you're deploying AppScale the fantasy is obvious because you are now doing all the normal work of scaling and normal system administration, and also the work of dealing with App Engine's flaws. But if you are green enough to get taken in by the fantasy once, then it probably won't be dispelled until after you've already lost months to years wishing you had chosen something else.
First you pay a heavy cost in extra development time to work around App Engine's idiosyncratic APIs, bizarre restrictions and quotas. Then you pay fees which are exorbitant by comparison with what you will get almost anywhere else. Then you may discover that support for the runtime you are using is lagging in a way that doubles your bills, and will never be fixed (and App Engine will never again have close to the interest and staffing it once had). How does it sound to rewrite in another language? Then you will discover and have to work around frequent service outages using the limited tools provided. All this with Google's famed lack of support - unless your spend is extremely high, which means you're losing even more money for having chosen App Engine. And let's just hope Google doesn't double, triple or quadruple monthly bills again.
If you run into any of these problems (and you will), you're stuck and your only real option is to move platforms, which means most of your code will have to be rewritten. AppScale is a final resort; there is no other option. If that doesn't work well for you, notably if the overhead of AppScale itself costs you too much, then you are still going to have to rewrite most of your code. If you don't already have a lot of App Engine code you can't replace, it isn't smart to plan to run a huge AppScale deployment.
If you think you will be doing a large deployment then you should look at technologies which were developed in the open from the beginning and which still have a lot of active momentum. Or just use normal Linux boxes and worry about scaling issues as you need to, like everyone else. Just don't get locked into weird vendor-specific APIs like App Engine.