5 ms·

App Engine is a joke. It was an interesting and novel idea at the time but it is not something you want to pick up today (or last year, or the year before that,

App Engine is a joke. It was an interesting and novel idea at the time but it is not something you want to pick up today (or last year, or the year before that, or the one before that either). GAE is a massive lock-in with outdated software in a world where there's so many better, cheaper, non-lock-in alternatives, even within Google itself.

anysz 10y ago
Care to share these alternatives ?
- scrollaway 10y ago
  Um, AWS? :) Within Google, either of the GCEs (https://cloud.google.com/compute/ https://cloud.google.com/compute/ https://cloud.google.com/container-engine/ https://cloud.google.com/container-engine/) depending on your architecture.
  - hehheh 10y ago
    Those aren't really alternatives to GAE IMO unless you would also say that a laptop is an alternative. A real GAE alternative would be a hosted solution that doesn't require you to install an OS or even know what OS it's using.
    - scrollaway 10y ago
      Such alternatives would have the same massive downsides as GAE (outdated software by design, lock-in by design). I'm not saying "Don't use GAE because it's expensive/google/whatever". I'm saying "Don't use GAE or anything like it".
    - NetStrikeForce 10y ago
      I think both AWS and Azure have pretty strong PaaS services where you just deploy your [nodejs|python|php] app. Heroku also comes to mind...
      - jacques_chester 10y ago
        AWS has Elastic Beanstalk. Azure is still finding their own PaaS pathway. Cloud Foundry gives you the "just push" experience for both of these (as well as vSphere, OpenStack, GCP and more to come). It's open source, with the IP owned by an independent foundation. Disclosure: I work for Pivotal, we donate the majority of engineering on Cloud Foundry.
    - 010a 10y ago
      GKE/Kubernetes does fill that requirement; its not as simple as GAE, but its one step closer to bare metal.
  - boulos 10y ago
    As a nod to Kubernetes, we say GKE for Container Engine. Maybe we should add that acronym on that landing page...
themihai 10y ago
I can't agree more!
dragonwriter 10y ago
> App Engine is a joke. It was an interesting and novel idea at the time but it is not something you want to pick up today [...] in a world where there's so many better, cheaper, non-lock-in alternatives, even within Google itself. As I see it, at the time App Engine was introduced, there were a lot more comparable PaaS offerings (maybe not with the same languages support, but the style of PaaS that GAE is was more common.) Competition from GAE and Heroku (which originally was focused on a similar PaaS offering) seems to have driven most of the other alternatives to pivot to something else or fail entirely. Right now, there's very few close substitutes; there's lots of "alternatives" that require more infrastructure work (e.g., IaaS and similar offerings like GCE, GKE, EC2, etc.) or are off in the other direction ("severless" function hosting like Lambda or GCF.) And in some cases these might be better options than an GAE-style PaaS, but they aren't really direct substitutes, and they leave a space better served by GAE.
bduerst 10y ago
Wait, how? I've used it before for one-off web projects, but didn't think it was that bad.
- macNchz 10y ago
  Having inherited a large legacy codebase running on App Engine and powering a successful business, I see the biggest danger with App Engine as being the lock-in. We're on App Engine and we're not going anywhere, because it'd be too big of a project to move somewhere else. There's one open source project I know of that lets you run an App Engine project on another server (Appscale), but it's hard to know how useable it would be without the overhead of getting everything set up, and surely there are plenty of dark corners you'd encounter along the way. Since App Engine comes with a proprietary data store, ORM and task queue built in, skipping the Appscale compatibility thing and just porting a large application to run on another platform would be a herculean effort. The data store models and everywhere in the application code that they're queried would need to be re-written for a different ORM, all of the data would have to be migrated to a different store, and all the background tasks and methods that trigger them would need to be rebuilt. This would be thousands and thousands of lines of hand-edited code changes, before even thinking about how much time would need to be spent verifying all of the changes. At least with Heroku the magic is mostly around deploying and scaling the various pieces, rather than providing a lot of application level libraries that lock you into the platform. Porting to another platform likely would require a bunch of configuration management and some deployment scripts, but fairly limited changes to the application code itself.
  - jacques_chester 10y ago
    The easiest path off Heroku to self-hosted is probably Cloud Foundry: one of the inspirations was Heroku and several of the Cloud Foundry buildpacks are soft forks of Heroku's buildpacks. Generally we find that any buildpack written for Heroku will work with Cloud Foundry without modification. With a little extra engineering you can create a buildpack that will run in a fully disconnected environment. Disclosure: I work on the Cloud Foundry Buildpacks team on behalf of Pivotal.
  - 10y ago
robryk 10y ago
> (...) non-lock-in alternatives (...) There is an opensource reimplementation of App Engine's interface. That said, I have no clue about its completeness or buglessness. https://github.com/AppScale/appscale https://github.com/AppScale/appscale
boulos 10y ago
Do you feel the same way about App Engine Flexible Environment (neé Managed VMs)? That is, is your complaint that GAE Standard offers you all these services (like Memcache, Task Queues, Datastore) or that you hate the sandbox it's in? The GAE team has been (admittedly slowly) pushing the services that were GAE only into being fully-consumable "Cloud Platform" services (e.g., Cloud Datastore is the same Datastore that's been "part of" App Engine forever, but now accessible from anywhere). It's your choice to use Datastore, and I respect that you would chose to avoid it, but the basic PaaS idea of "here's some code, run it for me as a web endpoint" is still compelling even today. Disclosure: I work on Google Cloud.
- scrollaway 10y ago
  My impression of GAE is that on top of the core issues of the platform's (lock in by design, outdated by design), it is also very much unloved by Google and has received very few updates. I stayed away from it so I could be wrong. But to answer your question, I don't know anything about that Amazon service but I would feel the same way about similarly-designed competing product. IMHO, no informed person would ever pick proprietary, lock-in-heavy PAAS solutions.
  - boulos 10y ago
    But picking at that a bit, if I were to run a simple off-the-shelf Django setup against MySQL, I'd use GAE (if not Standard than certainly Flexible). My code wouldn't be any different than deploying it to a raw VM, so I'm not locked in and could deploy it on DO, AWS or anywhere else in a heartbeat. In the meantime, I don't have to deal with setting up load balancing, autoscaling, DNS per module, etc. so I get some real value from that. Is your concern the lock-in from the code standpoint, or operational "lock-in" that once you've got all this set up for you, you'd have to go replicate it to get out? If the latter, aren't you saying you're going to do that on Day 1 in the "avoid PaaS" case?
    - scrollaway 10y ago
      Why would you use GAE in this scenario, over, say, GCE or even AWS? And at a smaller scale, DO would be far cheaper.

anysz 10y ago

Care to share these alternatives ?

scrollaway 10y ago
Um, AWS? :) Within Google, either of the GCEs (https://cloud.google.com/compute/ https://cloud.google.com/compute/ https://cloud.google.com/container-engine/ https://cloud.google.com/container-engine/) depending on your architecture.
- hehheh 10y ago
  Those aren't really alternatives to GAE IMO unless you would also say that a laptop is an alternative. A real GAE alternative would be a hosted solution that doesn't require you to install an OS or even know what OS it's using.
  - scrollaway 10y ago
    Such alternatives would have the same massive downsides as GAE (outdated software by design, lock-in by design). I'm not saying "Don't use GAE because it's expensive/google/whatever". I'm saying "Don't use GAE or anything like it".
  - NetStrikeForce 10y ago
    I think both AWS and Azure have pretty strong PaaS services where you just deploy your [nodejs|python|php] app. Heroku also comes to mind...
    - jacques_chester 10y ago
      AWS has Elastic Beanstalk. Azure is still finding their own PaaS pathway. Cloud Foundry gives you the "just push" experience for both of these (as well as vSphere, OpenStack, GCP and more to come). It's open source, with the IP owned by an independent foundation. Disclosure: I work for Pivotal, we donate the majority of engineering on Cloud Foundry.
  - 010a 10y ago
    GKE/Kubernetes does fill that requirement; its not as simple as GAE, but its one step closer to bare metal.
- boulos 10y ago
  As a nod to Kubernetes, we say GKE for Container Engine. Maybe we should add that acronym on that landing page...

themihai 10y ago

I can't agree more!

dragonwriter 10y ago

> App Engine is a joke. It was an interesting and novel idea at the time but it is not something you want to pick up today [...] in a world where there's so many better, cheaper, non-lock-in alternatives, even within Google itself. As I see it, at the time App Engine was introduced, there were a lot more comparable PaaS offerings (maybe not with the same languages support, but the style of PaaS that GAE is was more common.) Competition from GAE and Heroku (which originally was focused on a similar PaaS offering) seems to have driven most of the other alternatives to pivot to something else or fail entirely. Right now, there's very few close substitutes; there's lots of "alternatives" that require more infrastructure work (e.g., IaaS and similar offerings like GCE, GKE, EC2, etc.) or are off in the other direction ("severless" function hosting like Lambda or GCF.) And in some cases these might be better options than an GAE-style PaaS, but they aren't really direct substitutes, and they leave a space better served by GAE.

bduerst 10y ago

Wait, how? I've used it before for one-off web projects, but didn't think it was that bad.

macNchz 10y ago
Having inherited a large legacy codebase running on App Engine and powering a successful business, I see the biggest danger with App Engine as being the lock-in. We're on App Engine and we're not going anywhere, because it'd be too big of a project to move somewhere else. There's one open source project I know of that lets you run an App Engine project on another server (Appscale), but it's hard to know how useable it would be without the overhead of getting everything set up, and surely there are plenty of dark corners you'd encounter along the way. Since App Engine comes with a proprietary data store, ORM and task queue built in, skipping the Appscale compatibility thing and just porting a large application to run on another platform would be a herculean effort. The data store models and everywhere in the application code that they're queried would need to be re-written for a different ORM, all of the data would have to be migrated to a different store, and all the background tasks and methods that trigger them would need to be rebuilt. This would be thousands and thousands of lines of hand-edited code changes, before even thinking about how much time would need to be spent verifying all of the changes. At least with Heroku the magic is mostly around deploying and scaling the various pieces, rather than providing a lot of application level libraries that lock you into the platform. Porting to another platform likely would require a bunch of configuration management and some deployment scripts, but fairly limited changes to the application code itself.
- jacques_chester 10y ago
  The easiest path off Heroku to self-hosted is probably Cloud Foundry: one of the inspirations was Heroku and several of the Cloud Foundry buildpacks are soft forks of Heroku's buildpacks. Generally we find that any buildpack written for Heroku will work with Cloud Foundry without modification. With a little extra engineering you can create a buildpack that will run in a fully disconnected environment. Disclosure: I work on the Cloud Foundry Buildpacks team on behalf of Pivotal.
- 10y ago

robryk 10y ago

> (...) non-lock-in alternatives (...) There is an opensource reimplementation of App Engine's interface. That said, I have no clue about its completeness or buglessness. https://github.com/AppScale/appscale https://github.com/AppScale/appscale

boulos 10y ago

Do you feel the same way about App Engine Flexible Environment (neé Managed VMs)? That is, is your complaint that GAE Standard offers you all these services (like Memcache, Task Queues, Datastore) or that you hate the sandbox it's in? The GAE team has been (admittedly slowly) pushing the services that were GAE only into being fully-consumable "Cloud Platform" services (e.g., Cloud Datastore is the same Datastore that's been "part of" App Engine forever, but now accessible from anywhere). It's your choice to use Datastore, and I respect that you would chose to avoid it, but the basic PaaS idea of "here's some code, run it for me as a web endpoint" is still compelling even today. Disclosure: I work on Google Cloud.

scrollaway 10y ago
My impression of GAE is that on top of the core issues of the platform's (lock in by design, outdated by design), it is also very much unloved by Google and has received very few updates. I stayed away from it so I could be wrong. But to answer your question, I don't know anything about that Amazon service but I would feel the same way about similarly-designed competing product. IMHO, no informed person would ever pick proprietary, lock-in-heavy PAAS solutions.
- boulos 10y ago
  But picking at that a bit, if I were to run a simple off-the-shelf Django setup against MySQL, I'd use GAE (if not Standard than certainly Flexible). My code wouldn't be any different than deploying it to a raw VM, so I'm not locked in and could deploy it on DO, AWS or anywhere else in a heartbeat. In the meantime, I don't have to deal with setting up load balancing, autoscaling, DNS per module, etc. so I get some real value from that. Is your concern the lock-in from the code standpoint, or operational "lock-in" that once you've got all this set up for you, you'd have to go replicate it to get out? If the latter, aren't you saying you're going to do that on Day 1 in the "avoid PaaS" case?
  - scrollaway 10y ago
    Why would you use GAE in this scenario, over, say, GCE or even AWS? And at a smaller scale, DO would be far cheaper.