Hello Henderson, I answered you in your other thread. <https://groups.google.com/forum/#!topic/google-appengine/xDIQwQ94Mkc>
On Tuesday, September 25, 2018 at 11:36:28 PM UTC-4, Handerson Contreras wrote: > > Hey Steren > > How much time takes to enable the Cloud task api after fill in the form? > > I already filled but i haven't received news > > I am getting this error: > > google.api_core.exceptions.PermissionDenied: 403 Cloud Tasks API has not > been used in project <mi_project_id> before or it is disabled > > I suppous the cause is because is not enabled yet, but i enabled it from > here > https://console.cloud.google.com/apis/api/tasks.googleapis.com/overview?project=myprojectid > > > Or do you have an idea what could be the problem? > > Thanks > > On Monday, November 20, 2017 at 8:06:42 PM UTC-6, Steren Giannini wrote: >> >> Thanks for the detailed feedback. We value it a lot and it helps us >> orient the direction of our products. >> >> Regarding managed services: A new API, currently in Alpha, called "Cloud >> Tasks API" allows you to submit push tasks from App Engine Flex. >> Get whitelisted by filling this form: https://goo.gl/Ya0AZd >> >> Thanks, >> >> Steren >> Product Manager >> Google Cloud Platform >> >> On Saturday, November 18, 2017 at 12:11:32 AM UTC-8, Attila-Mihaly Balazs >> wrote: >>> >>> Hello all, >>> >>> I would like to kick off this discussion because I think the Google >>> AppEngine team is missing an opportunity to differentiate themselves from >>> the competitors. >>> >>> First, a quick rundown of why I've chosen AppEngine many years ago and >>> why I continue to use/recommend it: >>> >>> - the free tier (important to try stuff out) >>> - managed services (like Memcache, Datastore, Taskqueues, CloudSQL) >>> - automatic scaling / failover >>> - automatic patching / updating / tuning of the instances >>> >>> In short, I want to focus on delivering the solution to my stakeholders >>> and I don't have the time to become ops (even though ops is very >>> important). Also, I have confidence in the world-class ops team at Google >>> that they will keep my app secure and well-performing. >>> >>> Of course this is not to say that everything is rosy. One big painpoint >>> was/is the lag of updating the runtimes (only recently did we get Java 8 - >>> god knows when we'll get Java 9 - and Python 3 isn't even discussed - even >>> though major libraries are dropping support for Python 2 soon). The other >>> one is the inability to "bring your own libraries" if they require native >>> code. And finally sometimes there is a general flakyness to AppEngine, but >>> that's just a fact of life when running on such a large distributed system. >>> >>> So the new AppEngine flex offering comes out which is basically "we run >>> your docker image using the autoscaler". Which is great, but looses many of >>> the advantages of AppEngine standard: >>> >>> - free tier? forget it >>> - managed services? some yes, some no (like memcache), some in beta with >>> limitations (like taskqueue - I think you can't submit push tasks with >>> AppEngine Flex) >>> - the big one for me: NO automatic updating / patching / tuning / >>> optimizing of your runtime environment (see the discussion at [1]) >>> >>> So basically: I'm paying more (since AppEngine flex is more expensive) >>> and I get less performance (since Google engineers are not assisting me in >>> tuning Nginx / the JVM / etc inside my container) and I have to play ops by >>> following the security discussions for the different parts of my stack and >>> diligently rebuild/patch my containers. >>> >>> At this point I'm like: screw it, there is very little difference >>> between running a bunch of docker images on the Google Cloud vs any other >>> competitor. >>> >>> But this could be very easily be fixed: >>> >>> - offer a "no questions asked, here are $300 / month" tier on Google >>> Cloud which the user can spend on anything (including running AppEngine >>> flex instances, CloudSQL instances, etc). It could even be $10 / day to >>> avoid the "because of a bug I just used up my monthly allowance" kind of >>> situations >>> - allow flexible environments to scale down to 0 instances. The "it's >>> slow to start up" seem bull, since a docker container is just like a >>> process - isolated using namespaces, cgroups, etc. So it's not like you >>> have to boot a VM to serve the first request >>> - have an official base image (based on Debian for example) and say: as >>> long as your docker images are derived "FROM >>> google-appengine-flex-base:latest", we promise to update/tune the >>> underlying packages and apply it to your instances without you having to do >>> anything >>> - commit to provide complete access to all the Google Cloud Services in >>> a select number of programming languages (lets say C/C++ / Java - which >>> covers the JVM languages / C# - covering the .NET languages / Python 3 / >>> PHP - and the other languages can wrap the C library). >>> >>> This is not some genius idea, so I guess the explanation for why this >>> hasn't happened is internal politiking. Thus I would like to ask you: get >>> off of that and make AppEngine a great PaaS again (currently it's just a >>> good one). >>> >>> Regards, >>> Attila >>> >>> [1] https://groups.google.com/forum/#!topic/google-appengine/QulhjoBGlHc >>> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/1a786b90-7c71-4d34-8c06-5f9451d85b53%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
