Go 1.11 is now available on App Engine!

[Steven Buss]

https://cloud.google.com/blog/products/application-development/go-1-11-is-now-available-on-app-engine

I'm super thrilled to announce that Go 1.11 is now available on App Engine! As promised, we now support...

* vendoring

* regular best-practice package structures

* go modules

* the regular Google Cloud client libraries

This is a "second-generation" runtime, meaning that we're now running stock Go in the gVisor sandbox. We've removed all of the restrictions present in the old runtime, like limited socket and file access. You can even import "unsafe"!

Learn how to migrate from the Go 1.9 runtime to the new Go 1.11 runtime with this migration guide. For the time being, you can still use the legacy App Engine APIs with the Go 1.11 runtime, but you should start migrating to the Google Cloud client libraries.

Check out our launch video: https://www.youtube.com/watch?v=FPG-rB4QCnY

If you have any questions, please don't hesitate to ask!

[Prateek Malhotra]

A couple questions pop to mind:

• Is cgo available in the build process with the new runtime? I know even with the Flex runtime I had to custom build images before deploying them as the default go cloudbuilders couldn't compile packages requiring cgo.
  
• What does this mean for the Flex runtime? I do use the Flex runtime for some features the old standard runtime sandbox wouldn't allow, but now that it's opened up there are few reasons to stay on the Flex runtime except maybe for placing instances in a private network. Will these runtimes converge in the future? Looks like the second generation is stripping away features like the Memcache API (actually, does Memorystore supplant this or is this still in early access?), Users API, and Search API like the flex runtime did.
• How long will the standard AppEngine APIs be supported going forward? It looks like support is legacy. While I don't mind moving away from these APIs, I don't like that comparable "pay-as-you-go" alternatives aren't available. Hosting my own redis cluster or elasticsearch cluster to achieve the same availability and performance as I did with AppEngine Standard is now billed-by-hour, comes with high upfront cost for small projects, and security/devops is back on my hands or I'm paying 3rd parties to handle this for me (Redis Labs or Elastic Cloud). The very fact that virtually all documentation recommends moving away from the old APIs makes me feel uncomfortable continuing using them, especially seeing how access is becoming more and more limited from the suite of products available from GCP.
• Are background  tasks now available? Can I have long-running background go routines that exist outside of requests?
• Are warmup tasks still relevant or can I just use init() functions to access datastore and such with the new client libraries outside of requests?

I'm genuinely excited for this release/launch and look forward to further improvements to AppEngine, but the small-budget projects I used to use AppEngine for are not going as far as they used to and I think it irresponsible to continue using the older APIs given the updates to the platform over the last few years.

Thank you,

Prateek

[Steven Buss]

> Is cgo available in the build process with the new runtime? I know even with the Flex runtime I had to custom build images before deploying them as the default go cloudbuilders couldn't compile packages requiring cgo.

cgo is not currently enabled. This may change, but there are no promises. We're currently revisiting the decision to disable it.

> What does this mean for the Flex runtime?

Flex is unchanged.

> Will these runtimes converge in the future?

They will become more and more similar as time goes on.

> Looks like the second generation is stripping away features like the Memcache API (actually, does Memorystore supplant this or is this still in early access?), Users API, and Search API like the flex runtime did.

Memorystore will replace it, but I don't have a time estimate for you. Users and Search will be deprecated, yes. But for now you can still the legacy APIs. +CC steren@google to provide more context.

> How long will the standard AppEngine APIs be supported going forward?

We haven't made any final decisions, but all deprecations are subject to our deprecation policy (see https://cloud.google.com/terms/, section 7), which is at least 1 year. We have not issued any formal deprecation announcements, so you have more than 1 year to move off of the legacy APIs. The year countdown will start from the date of an official deprecation announcement.

steren@ may have more information on this, too.

> Are background  tasks now available? Can I have long-running background go routines that exist outside of requests?

You can use background goroutines, but apps are reaped within some timeframe after the last request. You may be interested in https://cloud.google.com/tasks/, which might be a better fit for what you're trying to do.

> Are warmup tasks still relevant or can I just use init() functions to access datastore and such with the new client libraries outside of requests?

Warmup requests are still relevant, though it looks like we missed the code samples on that docs page.

--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/9b2f1a61-58c6-4dab-add8-e1d572dfaa2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Prateek Malhotra]

Thanks for the quick responses!

Do you mind explaining the use-case for a warmup request? Loading an instance for a Go-based app already loads the code in the instance so this isn't relevant as it may be in something like Python. If RPCs are no longer tied to a request context, any pre-caching can happen with init() functions in the code, correct? I guess I'd like context on any potential use-case I'm missing here that a warmup request enables that isn't currently possible.

I'm looking forward to cgo support should it come! Memorystore from Standard doesn't look like its supported as I guess you can't place instances in a specified network (e.g. the network your Memorystore deployment is in) - getting this to work would be great, and it would also eliminate the last need I have for the Flex runtime (deploying instances in the same network that has VPN access to internal resources). I'd love to see both of these supported!

I guess it may be too much to ask for a glimpse of what may be coming next? 

Thanks again,

Prateek

[Chris Broadfoot]

I don't know the details of the health checker for the standard runtime, but the difference is basically doing your initialization before or after the HTTP server starts. I don't know what would happen if you have a long startup (say, 60 seconds) *then* start listening for requests, versus starting to listen for requests and doing the initialization inside the warmup request.

But yes, you can do the kind of pre-caching you're talking about in init() or in main() before you call into appengine.Main/http.ListenAndServe.

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/f1867426-9954-4725-9d22-9da43a1c007d%40googlegroups.com.

[Steven Buss]

> I'm looking forward to cgo support should it come!

I've added CGO support to my GA-blockers list. I can't guarantee it'll come but I don't currently see a reason to keep it disabled.

Memorystore support will come, but I don't have any guesses as to a timeline.

> I guess it may be too much to ask for a glimpse of what may be coming next? 

Generally, you can assume that everyone working on this product believes we need to avoid vendor lock-in and follow idiomatic patterns. The future should be a great, affordable, and easy to use platform where your Go apps just work.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/CAAfqdq7JHAZ1GSbHoiaTh4uEdTrJnH%3DmF-TDYLU5-Ax66sJqAw%40mail.gmail.com.

[Kun Li]

What's the general guideline for someone who is looking at what to choose for the next project, standard or flex? These two suddenly looks identical to each other now.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/CAN_t6Fv3Wn4-rXZvDZLvqSciVZ-U1EHzfWbTUNedwiJtMt-ujw%40mail.gmail.com.

[Steren Giannini]

Hi Kun,

This page could help you chose: https://cloud.google.com/appengine/docs/go/

If you are OK with a product in Beta, I recommend getting started with App Engine standard, mostly because its pricing model (scale to zero and pay for usage) is a great fit for exploration, and because of its fast deployment times.

Steren

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/CAHq%3D1bXH9a9uHyJQpgfu5-vpHaGkufpWFtSbcNeMu2bpK%3DdRGw%40mail.gmail.com.

[Ronoaldo José de Lana Pereira]

Thanks for the great news Steven! Amazing news for me and the the company I work for and use Go and App Engine for the past 3 years on production!

We are in the hurry to upgrade to the new runtime, and *huge thank you* for keeping the legacy APIs supported. For a 50k+ LOC app this is a very handy.

I need to express that this particular statement made my day: "The future should be a great, affordable, and easy to use platform where your Go apps just work." I don't know words in English enough to express how happy I am to hear that.

Congratulations to the whole team for the work on App Engine! It's by far my favorite go-to deployment of all kinds.

Best regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/CAN_t6Fv3Wn4-rXZvDZLvqSciVZ-U1EHzfWbTUNedwiJtMt-ujw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Ronoaldo Pereira

ronoaldo.com

[José Colón]

Hi all. Is the new 1.11 Standard Environment multithreaded? I believe the first generation environment was limited to only one thread. Is this still the case?

On Tuesday, October 16, 2018 at 12:36:25 PM UTC-4, Steven Buss wrote:

[Steven Buss]

Yup! Multi-threading should now work normally :)

If it doesn't, please let me know!

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/3d2c8926-c655-43c6-ac95-ec99317c8f86%40googlegroups.com.

[José Colón]

OMG this is awesome! I mean, App Engine for Go was already a high performance platform, but now this takes it to another level. Thanks for this and all the other great features! :)

On Saturday, October 20, 2018 at 1:09:36 PM UTC-4, Steven Buss wrote:

Yup! Multi-threading should now work normally :)

If it doesn't, please let me know!

On Sat, Oct 20, 2018 at 10:07 AM José Colón <jec...@gmail.com> wrote:

Hi all. Is the new 1.11 Standard Environment multithreaded? I believe the first generation environment was limited to only one thread. Is this still the case?

On Tuesday, October 16, 2018 at 12:36:25 PM UTC-4, Steven Buss wrote:

https://cloud.google.com/blog/products/application-development/go-1-11-is-now-available-on-app-engine

I'm super thrilled to announce that Go 1.11 is now available on App Engine! As promised, we now support...

* vendoring

* regular best-practice package structures

* go modules

* the regular Google Cloud client libraries

This is a "second-generation" runtime, meaning that we're now running stock Go in the gVisor sandbox. We've removed all of the restrictions present in the old runtime, like limited socket and file access. You can even import "unsafe"!

Learn how to migrate from the Go 1.9 runtime to the new Go 1.11 runtime with this migration guide. For the time being, you can still use the legacy App Engine APIs with the Go 1.11 runtime, but you should start migrating to the Google Cloud client libraries.

Check out our launch video: https://www.youtube.com/watch?v=FPG-rB4QCnY

If you have any questions, please don't hesitate to ask!

--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.

[const...@topinvestor.app]

It would be nice if there are Golang examples for Cloud Tasks:

https://cloud.google.com/tasks/docs/quickstart-appengine

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.

[Steren Giannini]

Thanks for the suggestion. I fully agree with you and have opened an internal feature request (#118061226 for googlers on this thread).

Steren

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/9b2f1a61-58c6-4dab-add8-e1d572dfaa2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/8476a875-19b9-4d93-9bac-42954268f792%40googlegroups.com.

[Dheeraj Panyam]

Is go 1.11 also available on App Engine Flexi ?

Regards

Dheeraj

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/CANHKq5Gz_isb3%2B6Kp0quHwUovfRPBqAf9s2cxKkOJozFpdz3vQ%40mail.gmail.com.

[Steren Giannini]

Hi,

Yes, Go 1.11 is now the default version on the App Engine flexible environment.

Steren

[Babu Sreekanth]

Hi.

 I was going through the docs, and found

The appengine build tag is deprecated and will not be used when building your app for deployment. Ensure your code still functions correctly without it being set.

Is there a way to conditionally include files (like specify a custom build flag and set it through env). I use firestore, which doesn't have a local simulator, and I have an adapter for testing and development locally which uses local db. Is there a way I can still keep it?

thanks.

bsr

[Michaël Palomas]

Hi all, Go 1.11 support with modules and most (all) of the previous limitations removed sounds really great and exciting.

I have one question though:

if you read this page https://cloud.google.com/appengine/docs/standard/go111/specifying-dependencies you can notice:

"If you use Go Modules through a go.mod file, App Engine uploads only your application files and automatically fetches those dependencies."

So, what would happen if my Go application has dependencies from repositories which requires credentials/authentication?

Because I am a entreprise developer, we just don't put all our code open-source on public Github repo. For instance we use Azure DevOps, but could be Github with private repo. Anyway it requires credentials to fetch those repositories.

What's the behaviour there? How can App Engine deploy and run correctly my Go 1.1 app with modules in this particular use case? In the "old App Engine", it would first fetch and try to build everything locally, with my credentials, and then upload all application code and the required dependencies...

Thanks,

Michael

[Steren Giannini]

Hi,

Modules are experimental both in the Go language and Go on App Engine. Our goal to support them was to gather this kind of feedback.

For the moment, the Go builder for App Engine does not support private repositories. Contrary to Node.js, where developers can specify credentials in an .npmrc file, Go does not have a mechanism to do so and rely on the configuration of the local machine.

What would be your preferred way for us to handle that? Would you like to fallback to a "vendor mode", where we ignore go.mod and use your vendor folder?

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/b4f12863-8678-4506-986b-278ee3355305%40googlegroups.com.

[Steven Buss]

> Is there a way to conditionally include files (like specify a custom build flag and set it through env). I use firestore, which doesn't have a local simulator, and I have an adapter for testing and development locally which uses local db. Is there a way I can still keep it?

I recommend adding a build tag for your local development code and using it when building and running on your dev machine. Eg:

// +build dev

And then use `go build -tags dev` locally.

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/fb5ad62e-e2d1-4aa4-863e-8ec42454ce43%40googlegroups.com.

[babu]

Steven. thank you for the idea. Using .gcloudignore with build tag would hopefully allow to keep my files for now. thanks again

On Tuesday, October 23, 2018 at 12:16:40 PM UTC-4, Steven Buss wrote:

> Is there a way to conditionally include files (like specify a custom build flag and set it through env). I use firestore, which doesn't have a local simulator, and I have an adapter for testing and development locally which uses local db. Is there a way I can still keep it?

I recommend adding a build tag for your local development code and using it when building and running on your dev machine. Eg:

// +build dev

And then use `go build -tags dev` locally.

On Mon, Oct 22, 2018, 7:21 PM Babu Sreekanth <babu.sr...@gmail.com wrote:

Hi.

 I was going through the docs, and found

The appengine build tag is deprecated and will not be used when building your app for deployment. Ensure your code still functions correctly without it being set.

Is there a way to conditionally include files (like specify a custom build flag and set it through env). I use firestore, which doesn't have a local simulator, and I have an adapter for testing and development locally which uses local db. Is there a way I can still keep it?

thanks.

bsr

--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.

[Steven Buss]

> So, what would happen if my Go application has dependencies from repositories which requires credentials/authentication?

You can depend on private repos by following these instructions:

1) Starting from your app's root directory (where your go.mod is located) create a directory for private deps, eg: `mkdir private`

2) a) Create a symlink to your private code in your app's private deps directory or b) use a git submodule

3) use a go.mod replace directive, eg:

```

#go.mod

module example.com/myapp

require example.com/mypriv...@v0.0.0

replace example.com/myprivaterepoo -> ./private/myprivaterepo

```

This will cause `gcloud app deploy` to upload the source for your private repo.

You may want to read https://github.com/golang/go/wiki/Modules#what-community-tooling-exists-for-working-with-modules to learn more about go.mod tooling.

Please let me know if you have any trouble! I'll also open a ticket to add this info to our docs.

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/b4f12863-8678-4506-986b-278ee3355305%40googlegroups.com.

[Steven Buss]

Since we don't set any build tags in our cloud builder, your dev code won't be included in the complication, and you shouldn't need to exclude any code with .gcloudignore.

Give it a shot and let me know if you have any problems!

On Tue, Oct 23, 2018, 9:46 AM babu <babu.sr...@gmail.com wrote:

Steven. thank you for the idea. Using .gcloudignore with build tag would hopefully allow to keep my files for now. thanks again
On Tuesday, October 23, 2018 at 12:16:40 PM UTC-4, Steven Buss wrote:

> Is there a way to conditionally include files (like specify a custom build flag and set it through env). I use firestore, which doesn't have a local simulator, and I have an adapter for testing and development locally which uses local db. Is there a way I can still keep it?

I recommend adding a build tag for your local development code and using it when building and running on your dev machine. Eg:

// +build dev

And then use `go build -tags dev` locally.

On Mon, Oct 22, 2018, 7:21 PM Babu Sreekanth <babu.sr...@gmail.com wrote:

Hi.

 I was going through the docs, and found

The appengine build tag is deprecated and will not be used when building your app for deployment. Ensure your code still functions correctly without it being set.

Is there a way to conditionally include files (like specify a custom build flag and set it through env). I use firestore, which doesn't have a local simulator, and I have an adapter for testing and development locally which uses local db. Is there a way I can still keep it?

thanks.

bsr

--
You received this message because you are subscribed to the Google Groups "google-appengine-go" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/fb5ad62e-e2d1-4aa4-863e-8ec42454ce43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/3bc3062f-aec4-46a3-b4ad-64b13adea82b%40googlegroups.com.

[Michaël Palomas]

Hi Steven,

Thanks a lot for the various suggestions. We will try this out, will let you know.

On Tuesday, October 23, 2018 at 5:48:57 PM UTC+1, Steven Buss wrote:

> So, what would happen if my Go application has dependencies from repositories which requires credentials/authentication?

You can depend on private repos by following these instructions:

1) Starting from your app's root directory (where your go.mod is located) create a directory for private deps, eg: `mkdir private`

2) a) Create a symlink to your private code in your app's private deps directory or b) use a git submodule

3) use a go.mod replace directive, eg:

```

#go.mod

module example.com/myapp

require example.com/myprivaterepo@v0.0.0

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.

[Michaël Palomas]

Hi Steren, thanks for prompt reply.

Sure, we do understand the current experimental support. There are some interesting suggestions below from Steven, my team needs to do a bit of exploration and we will get back to you.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine-go+unsub...@googlegroups.com.

[Nuno Cruces]

Hi all,

This is very exciting. I'm all for avoiding vendor lock-in and following idiomatic patterns as much as possible.

But as someone who's been with App Engine for 6 years, I hope too much isn't lost in the transition.

Usage of the old AppEngine APIs is pretty strongly discouraged in the (Go 1.11) documentation.

It's nice that you're still supporting the old APIs (no NDB on Python 3 hurt).

But some features have no clear replacements. Hopefully this is being worked on.

A few things I'm using:

About Memorystore as a replacement for Memcache: will a "shared" tier be available?

I use around 10Mb of cache for lightweight instance synchronization. A 1Gb Redis instance is overkill for this.

Outbound network traffic to *.googleapis.com with the URL fetch service used to be (still is) free.

So, do "cloud.google.com/go" packages use URL fetch on App Engine?

Or is "outbound" traffic (to datastore.googleapis.com, to storage.googleapis.com, etc) now $0.12 GB?

The Blobstore as been superseded for, I don't know how long. I've long abandoned it for storage.

But blobstore.Send, blobstore.BlobKeyForFile (and X-AppEngine-BlobKey/X-AppEngine-BlobRange) are still the only ways to send more than 32 Mb in a response.

If you drop those APIs how can I serve large GCS objects? It's not clear that a portable API makes sense here.

Best regards,

Nuno Cruces

[Steren Giannini]

Hi,

Regarding Memorystore, I do not have more info. Memcache support is only in Alpha and I am not sure the pricing model is settled. 

I think that you are not billed for networking when you stay on Google's network in the same region. +Karolína Netolická might be able to give more details.

For GCS, did you consider directly serving the files from GCS? I am not sure it is the best use of App Engine to return files. What is your use case exactly?

Steren

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/01a24049-0680-41db-8e77-8c8d29c57ab8%40googlegroups.com.

[Nuno Cruces]

Hi Steren, thanks!

So, in terms of memcache I'll have to wait and see.

For networking, you'll now follow the Cloud Functions pricing model (egress is free to Google APIs in same region)? That's OK, but you should update the pricing page and specify what this means for multiregional resources (datastore, cloud storage).

For GCS, yes I have. That comes with its own set of limitations. SSL on custom domains is a big one. I'd need Firebase Hosting for to fix it and have any kind of rewriting. It'd be static rewriting. In practice I'd put these buckets behind CloudFlare and use their Workers to do some rewriting.

Use case is something like this. User A uploads X.docx. User B uploads same file, except named Y.docx. Hopefully, I want to store it only once without users realizing this. Different URLs, same blob. Then user A asks for a PDF conversion of X, and B asks the same for Y (it's the same file). I'd like to serve the same blob, with different URLs and perhaps different headers (Content-Disposition) both cases. Redirects solve the URL part, costing a round-trip, but don't solve headers.

I'd imagine "SendFile" is something useful on a "server", and for GAE "files" live on GCS. But only you can know how (un)popular this is, and the cost of supporting it (with its bugs). Maybe I'm the last guy still left using X-AppEngine-BlobKey. Feels like it.

Thanks again!

Nuno Cruces

[Alexander Trakhimenok]

@Steve Buss,

Where I can learn more about "and we protect you against DDoS attacks" quoted at https://cloud.google.com/blog/products/application-development/go-1-11-is-now-available-on-app-engine ?

If it is about Cloud Firewall it does not sound like real DDOS protection as we would need manually to update IP ranges and it's mean it's very reactive.
--

Alex

[Steren Giannini]

Hi Alexander,

By default, App Engine apps are protected with a basic DOS protection, an engineer on the team confirmed me this.

I realize we do not have more info about it in our docs, I will follow up internally to publish more info.

Steren

Product manager

--

You received this message because you are subscribed to the Google Groups "google-appengine-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine-go/514078ef-c5b7-4a97-8c08-d31235ba466e%40googlegroups.com.

[Steren Giannini]

After further investigation, we found this public reference: https://cloud.google.com/files/GCPDDoSprotection-04122016.pdf

○ App Engine is designed to be a fully multi-tenant system and implements a

number of safeguards intended to ensure that a single bad application will

not impact the performance or availability of other applications on the

platform.

○ App Engine sits behind the Google Front End which mitigates and absorbs

many Layer 4 and below attacks, such as SYN floods, IP fragment floods,

port exhaustion, etc.

○ You can also specify a set of IPs/IP networks via a dos.yaml file to block

them from accessing your application(s).

The last point is outdated, as you should now be using App Engine firewall instead of dos.yaml.

We'll work on incorporating some of this in our docs. Thanks for your feedback.

Steren