Switch from Flexible Environments to VMs

[lgarron]

While adding automated requirements checking to the website, we considered switching from App Engine to Google Cloud VMs. See this doc for more details.

We switched to Flexible Environments in the meantime. This had several frustrating issues, which cost me a lot of time:

• incompatibility with scanning HTTP/2 sites (issue #52) due to being stuck on Go 1.6 long after Go 1.7 came out (Go 1.7 had the bug fix we needed)
• Idiosyncratic request handling: all HTTP and HTTPS requests come in on port 8080, so we have to sniff custom App Engine headers instead of implementing a bog-standard Go server.
  • In particular, this makes it pretty tricky to implement proper HSTS for hstspreload.org itself!
• 5-minute deploy cycles, with no way to debug certain issues locally. This impacted
  • HSTS for hstspreload.appspot.com: 658cbf9
  • HSTS for hstspreload.org: 644995a, dd4758b (we had to tweak our custom App Engine hacks, whereas a normal Go server would never have had these issues in the first place)
  • Getting cron jobs to run at all: 6407772 (again, our custom App Engine hacks were broken)

See the google-cloud-workaround issue tag for an up-to-date list of issues.

However, VMs also have their downsides:

• Maintaining OS images (and security updates).
• Provisioning and load balancing enough VMs if traffic grows
• Not able to serve from hstspreload.appspot.com

We obtained hstspreload.org and redirected all traffic there starting late 2016. This was mainly so that we would have the option to swap the frontend servers out with VMs if needed. However, in the meantime we have resolved most of the issues with Flexible Environments (or worked around them) and plan to keep using them in the foreseeable future. I'm filing this bug for the historical record, in case we ever need to take a look and reconsider.