6 ms·
I think GCP is a very different beast from the rest of Google and that its approach to business has essentially nothing to do with the rest of Google's. I'd als
by dangoor 5y ago
I think GCP is a very different beast from the rest of Google and that its approach to business has essentially nothing to do with the rest of Google's. I'd also argue that GCP is different from Google Workspace (Google Docs/Sheets/Slides, etc.) is different from AdWords which in turn is different from anything Google offers direct to consumer. These businesses have different models and need to make different sorts of guarantees.
Khan Academy has been using Google App Engine since 2009 or '10. Since then, the App Engine APIs have changed dramatically (in a way that should make them more supportable going forward) and Python 2 has been supplanted by Python 3. Python 2 reached its official end of life on January 1, 2020. Despite that, we're still running Python 2 App Engine in production while we move to Go[1] and GCP is still supporting our use. (Note _most_ traffic to Khan Academy today is hitting our Go code and not Python 2.)
So, our experience with GCP and their long-term support of offerings has been good and we use quite a few of their services, but I don't think this has anything to do with their ability to fix the product-killing reputation elsewhere in the org.
[1]: https://blog.khanacademy.org/go-services-one-goliath-project/ https://blog.khanacademy.org/go-services-one-goliath-project...
- throw_m239339 5y ago> I think GCP is a very different beast from the rest of Google and that its approach to business has essentially nothing to do with the rest of Google's That's true, I think it's more of a branding issue. Everytime Google shuts down a service, it reflects poorly on their entire offer.
- maininformer 5y agoYour 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 agoI 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.
- nocommandline 5y agoGenerally, this is true but there are still exceptions and some of them are significant. For example, even though GAE still supports applications built on Python2, they are (as far as I know) not expending effort on fixing issues in Python2 (which is fine). They are asking folks to migrate to Python3 but the issue is some of the key APIs supported in Python2 are not available in Python3. Things like memcache, search, users API are not supported on the Python3 platform. It's as if these APIs' have 'essentially been killed' for Python3. Some of these 'gaps' creates opportunities for folks like me to build some tools/features to address them or write articles about 'hacks' around it but it gets some people worried and can be seen as part of 'killed by Google' issue