3 ms·

Your comment surprises me. App Engine 2 has nothing compared to App Engine 1. At a previous job we relied on App Engine 1's, task queues, user management, NDB,

Your comment surprises me. App Engine 2 has nothing compared to App Engine 1. At a previous job we relied on App Engine 1's, task queues, user management, NDB, blobstore, memcached, image resizing, and I hope I'm not forgetting anything. We had to change our code to use, cloud tasks, our own user management, a new NDB(more on that later), GCS, Redis and no resizing. This took around 2 years! on NDB, the issue was that it had a major overhaul and needed _a lot_ of work. we started updating when it was in beta, i.e. stable logic with an unstable API. But I found some major issues with it, a couple with transactions; one instance was, when using the cache, transactional deletes don't work(!). I do need to give a shoutout to the NDB dev team here who relentlessly debugged everything I posted. That was good support. Point being, as a developer this took away a lot of trust from me for GCP. And I thought how well this behavior aligns with Google's product killing yolo energy. Hopefully this new initiative will prevent my children from suffering from the same divine test of patience.

dangoor 5y ago
I agree that App Engine 2 is a totally different beast with very different features and that the migration path is challenging. I just think that by unbundling the services is a win overall... our application looks more like a normal Go webapp and could be placed atop Cloud Run or GKE if we wanted it there. Could even move it to another cloud if that particular app doesn't use datastore. Probably the biggest thorn in our side with App Engine 2 is that they now have "VPC connectors" between our web servers and Cloud Memorystore, so our caches haven't been scaling as well as they did with App Engine 1's memcache. But Google does listen to feedback on such things and has been working with us on scaling the VPCs. They've supported App Engine 1st gen for more than 10 years and I think they'll have an easier time with support and migrations to newer tech with the unbundled App Engine 2.
- nocommandline 5y ago
  >> I just think that by unbundling the services is a win overall... our application looks more like a normal Go webapp<< That is a valid use case but it's just one of the use cases for GAE. There is a use case for folks who wanted a pure serverless which means they were willing to be 'locked in' in exchange for not having to figure out or setup a bunch of servers/services and doing the integration. It was powerful for some folks to not have to worry about search, memcache, users, etc. You just drop an API link and you now have access to all of the above services. At the end of the day, maybe Google decided that the number of folks with your own use case far outweighed those with the other use case that I described.

dangoor 5y ago

I agree that App Engine 2 is a totally different beast with very different features and that the migration path is challenging. I just think that by unbundling the services is a win overall... our application looks more like a normal Go webapp and could be placed atop Cloud Run or GKE if we wanted it there. Could even move it to another cloud if that particular app doesn't use datastore. Probably the biggest thorn in our side with App Engine 2 is that they now have "VPC connectors" between our web servers and Cloud Memorystore, so our caches haven't been scaling as well as they did with App Engine 1's memcache. But Google does listen to feedback on such things and has been working with us on scaling the VPCs. They've supported App Engine 1st gen for more than 10 years and I think they'll have an easier time with support and migrations to newer tech with the unbundled App Engine 2.

nocommandline 5y ago
>> I just think that by unbundling the services is a win overall... our application looks more like a normal Go webapp<< That is a valid use case but it's just one of the use cases for GAE. There is a use case for folks who wanted a pure serverless which means they were willing to be 'locked in' in exchange for not having to figure out or setup a bunch of servers/services and doing the integration. It was powerful for some folks to not have to worry about search, memcache, users, etc. You just drop an API link and you now have access to all of the above services. At the end of the day, maybe Google decided that the number of folks with your own use case far outweighed those with the other use case that I described.