We've been on a bit of a tear lately on Google Cloud lately (or at least I have), and I have no desire to stop any time soon. I probably should though...  our analytics show that half our viewers are just people struggling to us AWS. Speaking of capitalizing on shitty UI, stay tuned in the future where we'll offer grossly overpriced unauthorized AWS certification programs.

AWS aside, I'm here to talk about the other Cloud in town - in particular, Google's solution to make sure you never configure a webserver again. This is a trend that's been grinding my gears a bit: as much as I appreciate the reduction in effort, the costs of choosing proprietary (paid) services to avoid opening a Linux shell seems like a dangerous prospect over time as every day developers become more and more reliant on convenience. Then again, I'm probably just angry that nobody will have to endure the pain of Python development circa 2012.

Random Old-Man Tangent About Configuring Webservers

Remember when we all ran Apache servers, and the world decided that mod_python should stop existing for no reason? The replacement was, of course, mod_wsgi: an entirely undocumented way of running Python on an Apache server created by a single guy from Google (who has apparently opted to spend the entirety of his life attempting to explain mod_wsgi on StackOverflow).

Besides mod_wsgi, the Nginx alternatives (Gunicorn and uWSGI) are almost equally insufferable to implement. Much of this can be attributed to tutorials (such as those posted by DigitalOcean) which dominate SEO, merely because those tutorials include glaring inexcusable typos in their configuration files. This results in an infinite Google search feedback loop, where you find what seems to be a perfectly fine tutorial... plus 10 pages of frustrated developers backlinking to said tutorial, trying to figure out where the hell the missing colon is in their Nginx config. Spoiler alert: that's not the only typo, and I'm pretty sure at this point nobody cares to put up with monetized troubleshooting bullshit schemes (calling it now: the slightly-false-tutorial is an elaborate SEO scam).  So yeah, app containers it is then.

The Benefits of App Engine

Besides not needing to know anything about Linux, hosting on App Engine provides a few other benefits. Considering all microservices are obfuscated in the cloud, we can easily hook into other services such as setting up CRON jobs, Tasks, and DNS, for instance. GCP's catalogue of offerings is destined to grow, whether those offerings are ferociously released from Google's ambitious backlog, or the result of a partnership utilizing Google Cloud for architecture, such as MongoDB cloud and others. Prepare to witness fierce and unapologetic growth from GCP by every metric, year-over-year.

App Engine is also intimately close with your source code. Despite the dynamically typed nature of Python and Javascript, App Engine will catch fatal errors when attempting to deploy your app which would not happen otherwise. Adding this type of interpreter adds a convenient level of 'easy mode,' where potentially fatal production errors are caught before deployment is even permitted. I even tried deploying some personal projects to App Engine which had been running live elsewhere, and App Engine was able to catch errors existing in my code which had been shamelessly running in production. Oops.

Even while the app is live, all errors are conveniently detected and reported front and center in the app engine dashboard:

"No module named App" seems like a pretty bad error
"No module named App" seems like a pretty bad error

So yes, there are plenty of benefits and reasons to use App Engine over a VPS: removal of web server configuration, build errors caught at runtime, and easy command-line deployments name a few of such benefits. The question of whether or not these perks are worth the price tag and vendor-lock are a personal decision.

Creating your First App... Engine

Google provides the luxury of creating apps in a variety of languages, including hot new -comer to the game, PHP. Lucky us!

Hah, people still use .NET
Hah, people still use .NET

Google will forcefully insist you complete their own step-by-step tutorial, which essentially teaches you how to use git clone and explains the contents of their YAML file. You can follow this if you want.

More interestingly is what you'll find when you open the GCP browser shell. While working through this tutorial, it's impossible to ignore that Google Cloud is essentially just a giant VPS across all your projects:

All of these directories were created in different projects
All of these directories were created in different projects

Just when we were done ranting, it turns out every service we pay for is just a thinly veiled obfuscation of something we could probably do on a 10 dollar Droplet. Fuck, let's just move on.

Simple Project Configuration

Perhaps majority of what one needs to learn to deploy apps is contained within a single YAML file. Add a YAML file in your directory:

runtime: python37
api_version: 1

handlers:
  # This configures Google App Engine to serve the files in the app's static
  # directory.
- url: static
  static_dir: static

  # This handler routes all requests not caught above to your main app.
  # Required when static routes are defined. 
  # Can be omitted when there are no static files defined.
- url: /.*
  script: auto

Set your Static directory if you're working in Python. Use Python 3.7.

Google also invented its own version of .gitignore for App Engine called .gcloudignore, so be aware of that.

Having worked with Flask in the past, you should presumably be familiar with a startup script such as the following:

from framewrk import create_app

app = create_app()

if __name__ == "__main__":
    app.run(host='0.0.0.0')

That's pretty much it man. Just remember that Google prefers requirements.txt over other forms of package management (Google will actually bar Pipfile from being committed, interestingly enough).

If you're working locally, gcloud app deploy is all you need to push to production (doesn't require a git commit, interestingly enough. gcloud app browse will open you newly deployed app, and gcloud app logs tail -s default will display your logs when something goes horribly wrong.

And there you have it: the practical and completely cynical guide to embracing modern architecture. Join us next time when we pay 50 dollars to deploy a single-click app simply because we're too lazy or unmotivated to set anything up ourselves.