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 own 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 very expensive unauthorized AWS certification programs.
AWS aside, I'm actually here to talk about the other cloud architecture trend that's been grinding my gears: choosing proprietary (paid) services to ensure modern developers will never need to open a Linux shell. Then again, I'm probably just angry that nobody will have to endure the pain of Python development circa 2012. 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. This is mostly due to tutorials such as those posted by DigitalOcean which dominate SEO, simply 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. Because everything is obfuscated in the cloud, we can easily hook into other services such as setting up CRON jobs, Tasks, and DNS, for instance. GCP's number of microservices are only bound to grow, and they will do so fiercely and unapologetically.
Even while the app is live, all errors are conveniently detected and reported front and center in the app engine dashboard:
So yes, fine. There are plenty of benefits and reasons to use App Engine over a VPS. Let's get on with it.
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!
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:
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.
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.