
Open Source Implementation of Google App Engine - debugdan
http://github.com/AppScale/appscale
======
woodyr
Wow, I love the conversation. I am the CEO of AppScale, so my perspective will
be biased. Spoiler alert.

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.

~~~
webmaven
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?

~~~
nlake44
It is all on the release notes:
[https://github.com/AppScale/appscale/blob/master/RELEASE](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.

~~~
webmaven
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.

------
pekk
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
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.

~~~
wots_taters
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](https://developers.google.com/appengine/articles/auth)

~~~
abritishguy
You can open sockets.

------
Goranek
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/)

------
jchrisa
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."

------
arrowgunz
I was surprised to see that the project was sponsored by Google.

~~~
wmf
AppScale is Google's answer to App Engine lock-in concerns, so it probably
benefits them more than it hurts them.

~~~
gmarootian
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.

------
yeukhon
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?

~~~
nlake44
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.

------
debugdan
Looks like they have commercial support as well
[http://appscale.com](http://appscale.com)

------
yowmamasita
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.

