3 ms·

It's actually not that hard to get out of, unless you rely on their scaling - in which case any system is hard to get out of. We did some contingency planning

It's actually not that hard to get out of, unless you rely on their scaling - in which case any system is hard to get out of. We did some contingency planning a while back, which included moving a low volume service to a LAPP (Linux/Apache/Python/PostgreSQL) stack to see how difficult is was. The biggest job was re-writing the NDB API calls, but it was not difficult. For me, knowing the world's best sysadmins are looking after our services is worth a lot. I've heard a couple of talks by Google's system relability engineers, and they are fanatical. Visible evidence of this is the brutally honest post mortem they produce every time there is a significant outage, including the vitally important "what we're going to do to stop this ever happening again" section. This focus works - GAE is way more reliable than AWS or Azure. So YMMV, but GAE is well worth it for us.

duiker101 9y ago
I have a Java Application on it but I have never found a straight forward way of exporting the data from the Datastore. Any ideas?
- foxylad 9y ago
  You are being down-voted because the whole point of almost all GAE apps is to return data from the datastore, albeit usually in nicely formatted HTML for browsers. You simply need to provide a handler that returns your data in whatever chunks or format you want.
thefounder 9y ago
It's not the scalling that locks you on GAE. It's about the proprietary services. I have 32 micro services, all depending by datastore, task queues etc. The only contigency plan that someone could implement is to do not use GAE in the first place. Almost 70% of the app code is really just about different ways to index/store and return data. Rewriting all the datastore ops is just like rewriting the whole application. With GAE you get stuck and there is little you can do! I had to choose between moving to their "flex" version or just dumping all the code and start over. Starting over is not an option so I'm still on GAE paying the flex prices. Now I pay regardless if the microservices are running or not. If it would be that simple to just move it all to an open source stack you can be sure I would do that.
- foxylad 9y ago
  For a platform to provide scaling, it pretty much has to provide proprietary services if those services are to scale as well. AWS proves this point, with their proprietary elastic block store, elasticache, SQS, SMS, etc). I don't know Azure at all, but I'd be very surprised if it's scalable services weren't proprietary too. So I hold that it is the scaling that locks you into GAE, but only to the extent that you desire scaling. Scaling gives you redundancy and reliability too, don't forget. > GAE -> easy to get in...very hard to get out! If your codebase is really 70% datastore API calls, I'd strongly suggest writing your own wrapper so you can change datastore by updating a few primitives. But in any case, GAE is no harder to get out of than any other scalable platform. > and expensive... We run three services with millions of users, for about 250 USD per month. Given a single dedicated server starts at $75 USD per month, and that we'd need at least four servers for redundancy and scaling, and that we'd need to hire a system architect/administrator for say ten hours a month to maintain them, I think GAE is excellent value. > and risky... You don't say why you think GAE is risky. In terms of uptime, our experience is that it is an order of magnitude more reliable than AWS or Azure. The other risk people sometimes suggest is that Google will discontinue the platform, but Google seems strongly committed to Appengine and Appengine has a three year deprecation policy for any part of the service. > it's not worth it We obviously disagree on this point. I would accept "it's not worth it if you will never need scaling and are happy to do your own system admin for free".

duiker101 9y ago

I have a Java Application on it but I have never found a straight forward way of exporting the data from the Datastore. Any ideas?

foxylad 9y ago
You are being down-voted because the whole point of almost all GAE apps is to return data from the datastore, albeit usually in nicely formatted HTML for browsers. You simply need to provide a handler that returns your data in whatever chunks or format you want.

thefounder 9y ago

It's not the scalling that locks you on GAE. It's about the proprietary services. I have 32 micro services, all depending by datastore, task queues etc. The only contigency plan that someone could implement is to do not use GAE in the first place. Almost 70% of the app code is really just about different ways to index/store and return data. Rewriting all the datastore ops is just like rewriting the whole application. With GAE you get stuck and there is little you can do! I had to choose between moving to their "flex" version or just dumping all the code and start over. Starting over is not an option so I'm still on GAE paying the flex prices. Now I pay regardless if the microservices are running or not. If it would be that simple to just move it all to an open source stack you can be sure I would do that.

foxylad 9y ago
For a platform to provide scaling, it pretty much has to provide proprietary services if those services are to scale as well. AWS proves this point, with their proprietary elastic block store, elasticache, SQS, SMS, etc). I don't know Azure at all, but I'd be very surprised if it's scalable services weren't proprietary too. So I hold that it is the scaling that locks you into GAE, but only to the extent that you desire scaling. Scaling gives you redundancy and reliability too, don't forget. > GAE -> easy to get in...very hard to get out! If your codebase is really 70% datastore API calls, I'd strongly suggest writing your own wrapper so you can change datastore by updating a few primitives. But in any case, GAE is no harder to get out of than any other scalable platform. > and expensive... We run three services with millions of users, for about 250 USD per month. Given a single dedicated server starts at $75 USD per month, and that we'd need at least four servers for redundancy and scaling, and that we'd need to hire a system architect/administrator for say ten hours a month to maintain them, I think GAE is excellent value. > and risky... You don't say why you think GAE is risky. In terms of uptime, our experience is that it is an order of magnitude more reliable than AWS or Azure. The other risk people sometimes suggest is that Google will discontinue the platform, but Google seems strongly committed to Appengine and Appengine has a three year deprecation policy for any part of the service. > it's not worth it We obviously disagree on this point. I would accept "it's not worth it if you will never need scaling and are happy to do your own system admin for free".