3 ms·

I never get this about google. They had a great product here (I and I know others actively interested) but they just drop development on these things for the ne

I never get this about google. They had a great product here (I and I know others actively interested) but they just drop development on these things for the new shiny toy. We're not asking for a ton, but if you could assign even a few folks to maintain the non-cool stuff, I think a lot more folks would build on GCP. I'm on AWS currently. They keep their old / uncool stuff around in a nice way (and totally seem to drop ball on other stuff that matters less like their new Amazon Linux 2 effort - python 3 support in that is totally wonky etc).

yegle 8y ago
Feature development of GAE (especially the Standard Environment) never stopped. Some of the features require multi quarters of work (e.g. https://cloudplatform.googleblog.com/2018/05/Increase-performance-while-reducing-costs-with-the-new-App-Engine-scheduler.html https://cloudplatform.googleblog.com/2018/05/Increase-perfor...), some are more enterprise-focused, some are not user visible but we improve the reliability with a new stack behind the curtain. We are changing the engine while flying (pun not intended). For various reasons, supporting new runtimes was never an easy task, even for small version bumps. This has changed drastically, starting with Java8 runtime, to the recently announced NodeJS beta, and to the closed alpha of Python 3 (remember this is Python 3.7). If you followed recent announcements from Google you probably can connect the dots. I think we are pretty open on what we are working on to our customers, as long as an NDA is signed. If you are interested be sure to let our cloud support team know! Disclaimer: I'm on App Engine SRE team.
- mijamo 8y ago
  I mean things have been pretty bad for GAE standard in Python for a very long time. It looks so dead I was actually expecting Google to completely remove it in 2 years or so. I work on a project on GAE standard and the platform was chosen before I started. I would say this was the worst possible solution to chose and the biggest cost for us right now. The most annoying point is that it is actually not easy at all to switch to the Flexible environment, because libraries are completely different. Examples of troubles : - new google-cloud libraries run in the flexible environment but not in the standard one (ex: google-cloud-pubsub doesn't run in the standard env after 0.27, and the doc for 0.27 is dead: https://google-cloud-python.readthedocs.io/en/0.27.0/pubsub/index.html https://google-cloud-python.readthedocs.io/en/0.27.0/pubsub/...) - traditional standard env libraries do not run in the flexible env. The most typical example is NDB for the Google datastore. Which means that migrating from the standard to the flexible env requires you to rebuild EVERYTHING that touches Google services... Great, then I'd better just switch to AWS instead! What's moer, flexible env is nice but for some reason it is not possible to have basic scaling anymore, nor is it possible to scale down to 0 when needed, which makes modular apps much more costly (previously we would have several services and when unused they just scaled down to 0). On top of that we just watched services get deprecated one after the other (mail service, then the datastore backup etc.) and old troubles not getting fixed (like memory problems with queries).
  - yegle 8y ago
    The technique behind standard and flex is large enough that we simply cannot provide consistent experience between these two. In fact these two products are supported by different teams. While the inconsistency is unfortunate, we are fully aware of this issue and are working towards a solution. Please expect some announcements from us. Service deprecation is not taken lightly, and we guarantee 12 months per GCP deprecation policy (https://cloud.google.com/terms/deprecation https://cloud.google.com/terms/deprecation). Of the services you mentioned, I don't think mail API is officially deprecated (per https://cloud.google.com/appengine/docs/deprecations/ https://cloud.google.com/appengine/docs/deprecations/), and Datastore Backups is superseded by Managed Export (https://cloud.google.com/datastore/docs/export-import-entities https://cloud.google.com/datastore/docs/export-import-entiti...). Not sure about the memory problems you mentioned though. Disclaimer: I'm on App Engine SRE team.
- james_in_the_uk 8y ago
  This is a fascinating post as it gives away something about the Google GAE culture perhaps. Some examples: "multi quarters" of work is odd phraseology. Does the GAE team prefer smaller, easier to schedule, features to longer more difficult projects to keep pace with development of the underyling toolset? "pretty open" "as long as you sign an NDA" is borderline oxymoronic. "enterprise focused" speaks for itself.
  - zerkten 8y ago
    > "pretty open" "as long as you sign an NDA" is borderline oxymoronic. > "enterprise focused" speaks for itself. GAE is a business and has a niche. Perhaps they'd really be dead if they didn't focus on a set of paying customers. NDAs are the norm for enterprise and are reasonable given that they want to maintain their niche. It's less reasonable for me to comment on their development/deployment methodology since I don't work at Google, but multiple quarters of work doesn't seem unusual for getting products like these deployed across multiple global data centers and achieve the kind of reliability required by these customers.
hknd 8y ago
The Google career page (1) indicates that they are hiring a lot of people in that area, so we might see some fast paced improvements there. 1: https://careers.google.com/jobs#t=sq&q=j&li=20&l=false&j=cloud https://careers.google.com/jobs#t=sq&q=j&li=20&l=false&j=clo...
hayd 8y ago
What have AWS dropped RE Amazon Linux 2? (I thought python 3 was supported there via Amazon Linux Extras.)

yegle 8y ago

Feature development of GAE (especially the Standard Environment) never stopped. Some of the features require multi quarters of work (e.g. https://cloudplatform.googleblog.com/2018/05/Increase-performance-while-reducing-costs-with-the-new-App-Engine-scheduler.html https://cloudplatform.googleblog.com/2018/05/Increase-perfor...), some are more enterprise-focused, some are not user visible but we improve the reliability with a new stack behind the curtain. We are changing the engine while flying (pun not intended). For various reasons, supporting new runtimes was never an easy task, even for small version bumps. This has changed drastically, starting with Java8 runtime, to the recently announced NodeJS beta, and to the closed alpha of Python 3 (remember this is Python 3.7). If you followed recent announcements from Google you probably can connect the dots. I think we are pretty open on what we are working on to our customers, as long as an NDA is signed. If you are interested be sure to let our cloud support team know! Disclaimer: I'm on App Engine SRE team.

mijamo 8y ago
I mean things have been pretty bad for GAE standard in Python for a very long time. It looks so dead I was actually expecting Google to completely remove it in 2 years or so. I work on a project on GAE standard and the platform was chosen before I started. I would say this was the worst possible solution to chose and the biggest cost for us right now. The most annoying point is that it is actually not easy at all to switch to the Flexible environment, because libraries are completely different. Examples of troubles : - new google-cloud libraries run in the flexible environment but not in the standard one (ex: google-cloud-pubsub doesn't run in the standard env after 0.27, and the doc for 0.27 is dead: https://google-cloud-python.readthedocs.io/en/0.27.0/pubsub/index.html https://google-cloud-python.readthedocs.io/en/0.27.0/pubsub/...) - traditional standard env libraries do not run in the flexible env. The most typical example is NDB for the Google datastore. Which means that migrating from the standard to the flexible env requires you to rebuild EVERYTHING that touches Google services... Great, then I'd better just switch to AWS instead! What's moer, flexible env is nice but for some reason it is not possible to have basic scaling anymore, nor is it possible to scale down to 0 when needed, which makes modular apps much more costly (previously we would have several services and when unused they just scaled down to 0). On top of that we just watched services get deprecated one after the other (mail service, then the datastore backup etc.) and old troubles not getting fixed (like memory problems with queries).
- yegle 8y ago
  The technique behind standard and flex is large enough that we simply cannot provide consistent experience between these two. In fact these two products are supported by different teams. While the inconsistency is unfortunate, we are fully aware of this issue and are working towards a solution. Please expect some announcements from us. Service deprecation is not taken lightly, and we guarantee 12 months per GCP deprecation policy (https://cloud.google.com/terms/deprecation https://cloud.google.com/terms/deprecation). Of the services you mentioned, I don't think mail API is officially deprecated (per https://cloud.google.com/appengine/docs/deprecations/ https://cloud.google.com/appengine/docs/deprecations/), and Datastore Backups is superseded by Managed Export (https://cloud.google.com/datastore/docs/export-import-entities https://cloud.google.com/datastore/docs/export-import-entiti...). Not sure about the memory problems you mentioned though. Disclaimer: I'm on App Engine SRE team.
james_in_the_uk 8y ago
This is a fascinating post as it gives away something about the Google GAE culture perhaps. Some examples: "multi quarters" of work is odd phraseology. Does the GAE team prefer smaller, easier to schedule, features to longer more difficult projects to keep pace with development of the underyling toolset? "pretty open" "as long as you sign an NDA" is borderline oxymoronic. "enterprise focused" speaks for itself.
- zerkten 8y ago
  > "pretty open" "as long as you sign an NDA" is borderline oxymoronic. > "enterprise focused" speaks for itself. GAE is a business and has a niche. Perhaps they'd really be dead if they didn't focus on a set of paying customers. NDAs are the norm for enterprise and are reasonable given that they want to maintain their niche. It's less reasonable for me to comment on their development/deployment methodology since I don't work at Google, but multiple quarters of work doesn't seem unusual for getting products like these deployed across multiple global data centers and achieve the kind of reliability required by these customers.

hknd 8y ago

The Google career page (1) indicates that they are hiring a lot of people in that area, so we might see some fast paced improvements there. 1: https://careers.google.com/jobs#t=sq&q=j&li=20&l=false&j=cloud https://careers.google.com/jobs#t=sq&q=j&li=20&l=false&j=clo...

hayd 8y ago

What have AWS dropped RE Amazon Linux 2? (I thought python 3 was supported there via Amazon Linux Extras.)