4 ms·
The architectural switch to the "Flexible Environment" is what I missed. I can appreciate why this broader new approach for language runtimes took some time. B
by jo909 10y ago
The architectural switch to the "Flexible Environment" is what I missed. I can appreciate why this broader new approach for language runtimes took some time.
But then again the Flexible Environment seems to be a very different product with different features/characteristics and pricing than what I once knew as "App Engine". I would then argue that Python 3 never came to "App Engine", only to their new product. Which is a valid strategy for Google of course, but now stifled my enthusiasm. Probably I only need to learn more about Flexible Environment style App Engine to become hyped again.
- lern_too_spel 10y agoFlexible environments are significantly worse if your application works on the original style of app engine.
- vsrinivas 10y agoJust wondering, why do you think so? (It wasn't obvious to me why, given a first read of the docs; the fact that applications run in VMs in Flex seems more like an implementation detail. Am I missing something?)
- kujenga 10y agoWe use both and try to stick with standard runtimes wherever possible, resorting to flexible runtimes for things doing heavier processing and/or with lots of instances. The standard runtimes are superior in a lot of ways, two big wins being lightning fast deployments (seconds vs. many minutes) and batteries included for all the app engine services. Logging in the flexible environment can also be a bit lacking. When you have something running in standard runtimes you basically don't have to think about many of the things that can normally go wrong on a server. That said, many things about the flexible environment are rapidly improving, they've certainly come a long way since we first started playing with them around 6 months ago.