6 ms·
If you're going to be handling http requests it's almost a given you'll be using AppEngine rather than Cloud Functions. Still "serverless" but more tools and la
by spyspy 9y ago
If you're going to be handling http requests it's almost a given you'll be using AppEngine rather than Cloud Functions. Still "serverless" but more tools and languages to choose from.
- the_common_man 9y agoAppEngine is more like a PaaS and not like 'serverless'
- seangrogg 9y agoThis. AppEngine assumes an "always on" mentality and is far from "pay for use" unless your "use" is 24/7.
- octalmage 9y agoAppEngine standard can actually scale down to 0 instances when not in use to save money. Still very different from a serverless architecture though.
- nothrabannosir 9y agoNot the flexible environment iirc. Which is basically the reasonable env to expect, now. Standard env has some aging issues that keep getting worse. most notably jvm 7, if that’s your poison, but just all round crippled env lacking standard libs and with lock in substitutions. As far as I remember, that is..
- iangudger 9y agoJava 8 is now supported with the full standard library: https://cloud.google.com/appengine/docs/standard/java/runtime-java8 https://cloud.google.com/appengine/docs/standard/java/runtim...
- dragonwriter 9y ago> If you're going to be handling http requests it's almost a given you'll be using AppEngine rather than Cloud Functions Why? Cloud Functions support HTTP. I mean, if you can stay within AppEngine’s free tier quotas, there's a clear reason to use it, but otherwise it would seem to be a matter of weighing pros and cons, with HTTP alone not deciding that you should use AE over CF.
- vira28 9y agoAre you kidding? You know how much you have to pay for AppEngine's right?!!
- jpatokal 9y agoNothing, if it's a small app? https://cloud.google.com/free/docs/always-free-usage-limits#gae_name https://cloud.google.com/free/docs/always-free-usage-limits#... Disclaimer: I work at GCP.