Open Source Implementation of Google App Engine(github.com)
github.com
Open Source Implementation of Google App Engine
http://github.com/AppScale/appscale
8 comments
It generally isn't clear (or discoverable) which release(s) of AppScale correspond to (compatibility with) which release(s) of GAE. Is there a changelog or roadmap document I missed?
It is all on the release notes: https://github.com/AppScale/appscale/blob/master/RELEASE
We currently support 1.8.0 GAE features but we do add patches that are a part of more current GAE releases if they are bug fixes.
We currently support 1.8.0 GAE features but we do add patches that are a part of more current GAE releases if they are bug fixes.
I'm having a real hard time finding where the GAE 1.8.0 compatibility is mentioned in that document.
Most recent explicit mention of version compatibility seems to be:
AppScale version 1.6.5 was released December 19, 2012.
Bugs fixed in this release:
- Update Java AppServer to 1.7.3
- Update Python AppServer to 1.7.3
But even aside from that, are you really saying that your compatibility with GAE's releases is lagging by more than a year? The 1.8.0 version of the SDK was released in May 2013.
Most recent explicit mention of version compatibility seems to be:
AppScale version 1.6.5 was released December 19, 2012.
Bugs fixed in this release:
- Update Java AppServer to 1.7.3
- Update Python AppServer to 1.7.3
But even aside from that, are you really saying that your compatibility with GAE's releases is lagging by more than a year? The 1.8.0 version of the SDK was released in May 2013.
For a one-man shop like me, GAE has been a godsend in many ways. I've also deployed toy apps to AWS and Heroku, Azure and OpenShift just to give them a spin, but I'm certainly no expert, and I don't doubt that some or all of these are "better" than GAE, but they all take more time and effort. On none of these other services was I comfortable that I'd set things up properly to suddenly scale. What if your big break comes and you get written up in the NYT or make the front page of HN? All is for naught if 100,000 visitors show up one day instead of 100 and you can't handle it. GAE relieves me of this particular anxiety.
AppScale relieves me of the fear that Google drops GAE or raises their prices too much, and having observed Google over the last 5 years, this is a real fear. I'm not sure how I feel about the fact that AppScale and Google are in cahoots on this.
There are other Google headaches as well. Support is very hard to come by, even with credit card in hand. Compared to Microsoft support it might as well be called nonexistent. And the Google account "system" is completely perplexing to me. My sites just use the old-fashioned username/password scheme, and I try to just ignore Google's because I don't understand it and neither do my customers.
The ease of administration trumps all of that for me though.
AppScale relieves me of the fear that Google drops GAE or raises their prices too much, and having observed Google over the last 5 years, this is a real fear. I'm not sure how I feel about the fact that AppScale and Google are in cahoots on this.
There are other Google headaches as well. Support is very hard to come by, even with credit card in hand. Compared to Microsoft support it might as well be called nonexistent. And the Google account "system" is completely perplexing to me. My sites just use the old-fashioned username/password scheme, and I try to just ignore Google's because I don't understand it and neither do my customers.
The ease of administration trumps all of that for me though.
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.
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.
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.
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
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.
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...
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.
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.
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.
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.
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...
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.
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.
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).
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?
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.
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.
Pretty much experienced the same thing and have since moved to using a standard LAMP stack on Amazon EC2.
Snapchat seems to run on app engine just fine.
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.
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.
Secret also runs on App Engine.
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).
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).
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.
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.
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.
App Engine recently got a new game changing feature called Managed VMS(Appengine on GCE instances, with all cool appengine features, gce pricing and no limits(filesystem support, sockets without limits, ...)
https://developers.google.com/appengine/docs/managed-vms/
https://developers.google.com/appengine/docs/managed-vms/
This project has been underway for a long time, so it's cool to see that they have support for the "Python, Java, PHP, and Go Google App Engine platforms."
I was surprised to see that the project was sponsored by Google.
AppScale is Google's answer to App Engine lock-in concerns, so it probably benefits them more than it hurts them.
I've used GAE on some projects in the recent past, and am working on the use of AppScale for a few purposes:
1. Remove infrastructure lock-in 2. Portability 3. Support for hybrid cloud
I like the concept of a GAE/Appscale platform implementation for my teams, as it allows them to focus on our core value, instead of implementing the well-known use cases. With the addition of being able to stand it up on any cloud infrastructure end-point is phenomenal.
1. Remove infrastructure lock-in 2. Portability 3. Support for hybrid cloud
I like the concept of a GAE/Appscale platform implementation for my teams, as it allows them to focus on our core value, instead of implementing the well-known use cases. With the addition of being able to stand it up on any cloud infrastructure end-point is phenomenal.
What do they mean they are sponsored by Google and IBM? Is Google giving them money or advise? Is this a research project at first?
We were initially funded by Google with a grant to start the project back in 2009 at UC Santa Barbara. Follow on funding came from IBM research, and then larger grants from the NSF and NIH. In 2012 the project spun out of the university and was commercialized. AppScale Systems is now a Cloud Technology Partner with Google.
Looks like they have commercial support as well http://appscale.com
I am one of those people who find GAE a joy to use especially for projects like intranet sites. Obviously, GAE is not one size fits all. It doesn't even try to be one. Although you might find it hard to know whether GAE is the right tool/platform as for the size of the product is immense (Google Cloud Platform). Heck, you might have missed what you truly need.
I was given a chance to work with AppScale on a project and all I can say is that Google is lucky that they're there. AppScale and GAE truly complement each other. And only those who've used both products will get that.
I am sad for those who are swayed to the FUD in this thread, they truly miss a lot. Not all people want to do devops. Not everyone wants to spend time brainstorming what the optimal stack to use. Some just want to code, build fast, and that's what AE/AS offers.
I was given a chance to work with AppScale on a project and all I can say is that Google is lucky that they're there. AppScale and GAE truly complement each other. And only those who've used both products will get that.
I am sad for those who are swayed to the FUD in this thread, they truly miss a lot. Not all people want to do devops. Not everyone wants to spend time brainstorming what the optimal stack to use. Some just want to code, build fast, and that's what AE/AS offers.
We have many customers using AppScale in production. Some migrated away from GAE for very specific reasons. Privacy (particularly in Europe), lock-in, control, performance and cost are the typical reasons...in that order. Many, however, come to AppScale because they love the GAE development model and want the independence to run their application wherever is best for their business; without the restrictions, quotas and performance irregularities.
The brilliance of GAE is the development model. The notion of concentrating on the business logic, the problem you are trying to solve, rather than working with stacks of software is the innovation. Our customers, and GAE's, are typically not tech companies. They do not have a deep bench of experienced developers. They are fashion and electronics retailers, global non-profits, SaaS companies trying to rapidly prototype and create MVP's. They want to innovate quickly and fail fast as they develop their business model. This is where the GAE model shines. It's fast. Business today must move at the speed of need, and the App Engine model, whether GAE or AppScale, is a tool that facilitates this.
AppScale is a complement to GAE. If want to run in AWS, SoftLayer, Azure or Digital Ocean, no problem. You can also run your app behind the firewall on OpenStack, Eucalyptus, CloudStack, Mothership1 or simply on top of KVM or VMware. AppScale is easy to install and deploy from GitHub. GAE needs to worry about running 4.5M active applications (up from 3M last year) but AppScale only needs to worry about one application, yours.
We understand that GAE did not make many fans in the early days. That has changed and their 50% growth in active apps over last year is evidence. Add AppScale to the picture and you get to continue using the awesome development model but you have the complete flexibility to run where you choose and maintain complete granular control over your app.
So, I will make a bold offer. Check out AppScale and give it a test drive. I would love to hear your feedback. If you need some extra love, our engineers will help over our IRC channel at freenode, #appscale
It is our goal to be the open source private PaaS of choice for forward-thinking developers and companies. We would love your support.