3 ms·

Yes, I have no argument with you that it is quite slick. It seems the benefit still does not outweigh the cost though. I can't even imagine running into a criti

Yes, I have no argument with you that it is quite slick. It seems the benefit still does not outweigh the cost though. I can't even imagine running into a critical issue with paying customers demanding answers from me while I am subjected to Google's customer service. Plus there's no way to failover from App Engine to some other platform if your app is locked into the "App Engine Way". The only thing I would consider using App Engine for at this point would be a school project or something.

Roedou 13y ago
It's an incredibly quick way of getting something out there. If agility matters, I've not found anything that beats it. You might not want your service running on there as you scale, but it's enough to get a few thousand users onboarded as a proof of concept.
- michaelt 13y ago
  Some parts of app engine are very much designed to be really scalable and geographically redundant. Take sharded counters, for example [1], if you want to count something that happens more than 5 times a second. If you want a proof of concept and you're not concerned about getting the scalability, why not run on a single server? [1] https://developers.google.com/appengine/articles/sharding_counters https://developers.google.com/appengine/articles/sharding_co...
dragonwriter 13y ago
> Plus there's no way to failover from App Engine to some other platform if your app is locked into the "App Engine Way". Well, except that there is an open-source alternative implementation of App Engine that you can run anywhere you want. [1] Which kind of ruins the whole "no way to failover from App Engine to some other platform" argument, even for apps built the "App Engine Way". [1] http://www.appscale.com/ http://www.appscale.com/
- elithrar 13y ago
  > Well, except that there is an open-source alternative implementation of App Engine that you can run anywhere you want. To be fair, AppScale is a separate entity and therefore there's no guarantee that they will keep up with GAE API's, API bugs, and/or quirks. These are obviously things out of their control, but I'm saying this because there's still no guarantee of a 1:1 replacement if you need to move away.

Roedou 13y ago

It's an incredibly quick way of getting something out there. If agility matters, I've not found anything that beats it. You might not want your service running on there as you scale, but it's enough to get a few thousand users onboarded as a proof of concept.

michaelt 13y ago
Some parts of app engine are very much designed to be really scalable and geographically redundant. Take sharded counters, for example [1], if you want to count something that happens more than 5 times a second. If you want a proof of concept and you're not concerned about getting the scalability, why not run on a single server? [1] https://developers.google.com/appengine/articles/sharding_counters https://developers.google.com/appengine/articles/sharding_co...

dragonwriter 13y ago

> Plus there's no way to failover from App Engine to some other platform if your app is locked into the "App Engine Way". Well, except that there is an open-source alternative implementation of App Engine that you can run anywhere you want. [1] Which kind of ruins the whole "no way to failover from App Engine to some other platform" argument, even for apps built the "App Engine Way". [1] http://www.appscale.com/ http://www.appscale.com/

elithrar 13y ago
> Well, except that there is an open-source alternative implementation of App Engine that you can run anywhere you want. To be fair, AppScale is a separate entity and therefore there's no guarantee that they will keep up with GAE API's, API bugs, and/or quirks. These are obviously things out of their control, but I'm saying this because there's still no guarantee of a 1:1 replacement if you need to move away.