6 ms·
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
by pekk 12y ago
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.
- hrjet 12y agoSeconded. 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.
- btian 12y agoLet me guess - bad product-market fit?
- hrjet 12y agoDidn't have time / resources to find out. GAE consumed a lot of my time (until I realized it).
- wots_taters 12y agoThirded. 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 https://developers.google.com/appengine/articles/auth