What a Go developer needs to know about Google Cloud Platform
UPDATE (Oct. 16, 2018): A lot has changed since I wrote this post. In addition to GCE and GKE (see below), App Engine has improved significantly and support for Go on Cloud Functions has been announced (private alpha at the time of writing).
For running Go code on Google Cloud Platform (GCP), there are two great choices for portable code: Google Compute Engine (GCE), and Google Kubernetes Engine (GKE). Let’s look at each in depth as well as a number of additional options for Go developers.
Two Great Choices: GCE and GKE
Billed as Google’s offering for “scalable, high-performance virtual machines,” GCE is a straightforward product with some niceties. See the quickstart here. It comes with the usual costs and benefits. As a nice feature, GCE does live migrations, which means Google performs security updates for you without any impact to a virtual machine’s (VM) workload. Needless to say, it is the user’s responsibility to create machines and networks in whatever configuration necessary. GCE comes with the nice feature of allowing users to create a VM with a container in addition to offering a wide range of host OS’s.
GKE is almost certainly the more exciting offering from a Go developer’s perspective. See the quickstart here. You get all the power of Kubernetes, without the difficulty of running it the hard way on raw compute instances. For smaller systems, GKE might be overkill, but it certainly provides a great story for how you will scale your system as it grows.
Which of these two options you pick depends entirely on what your system looks like, what kind of requirements you have for uptime and scalability, and so on. One reason to use GCE is that it’s significantly cheaper for a small service, whereas a GKE cluster with a load balancer ingress can be much more pricey. For some, it might be best to build a Go binary and run it on GCE using simple tools like supervisord and scp. Alternatively, it’s fairly easy to create a Kubernetes cluster and move the deployment over to GKE. For others, starting with GKE might be the right choice.
Thoughts on App Engine
Aside from GCE and GKE, Google Cloud does offer a third choice to Go developers: App Engine. If you accept the definition that software engineering is programming integrated over time, you will likely find it hard to see App Engine as a reasonable choice. It certainly has significant strengths, e.g., “scaling from zero to planet scale”, but it also suffers from some major weaknesses.
App Engine consists of two environments: Standard and Flexible. The Standard environment breaks with the Twelve Factor App design principle of “maximum portability between execution environments” and makes requirements of how you write your main function. Granted, there are reasonable ways to deal with this. The Standard environment also tends to run one minor version behind the newest Go release. For instance, Go 1.10 was released February 16, 2018. Meanwhile, at the time of writing, the newest version supported by App Engine is Go 1.9. Since February 16, 2016, Go has supported vendoring one’s dependencies. More than two years later, App Engine still does not support vendoring. One can at least use the old approach of checking-in an entire GOPATH per project, a tedious and cumbersome practice otherwise abandoned by the community given the support for vendoring.
While the Standard environment makes some onerous demands on a user’s code, the Flexible environment is closer to the Twelve Factor PaaS many people are used to. The Flexible environment also supports deploying a containizered app. The only problem is that deploys to the Flexible environment are painfully slow. For example, deploying the Hello World sample took 12 minutes on a fresh deploy and 11 minutes on a second deploy with no changes. For me, a slow deploy defeats the purpose of a PaaS.
If your use case falls squarely within what makes App Engine powerful or you’re looking to deploy something simple like a GoDoc redirect for a vanity import path, it can be a great choice. Overall, though, App Engine requires you to write non-portable code or to suffer slow deploys. For some, these might be justifiable shortcomings. For many, they will likely be deal-breakers.
Go support on Google Cloud Functions
Go is currently not supported on Google Cloud Functions (GCF). I am certain all Go developers hope this will change soon. Meanwhile, there is an unofficial (and unsupported) native Go runtime for people who might like to experiment. Alternatively, there are ways to run Go functions on top of Kubernetes. For example, see OpenFaaS or riff.
Once Go receives proper support on GCF, the entire story here will likely change. In fact, for the majority of request/response workloads, I imagine GCF will be the best place for developers to start deploying Go code.
Some Helpful Tools Worth Knowing About
Although not specific to Go per se, a developer will be happy to know about Cloud Source Repositories, Container Registry, and Container Builder. There are a number of other developer tools, as well, but the three named here are especially useful. When deploying applications on GCP, it’s nice to consolidate source code, Docker images, and the steps to build, test, and deploy in the same place. Container Builder is especially nice given it’s support for building, testing, and deploying artifacts.
Finally, there are countless useful APIs available with Go bindings thanks to the Google Cloud Client Libraries for Go. Supported APIs include things like:
See the GoDoc for details. And, it’s helpful to read GCP products described in 4 words or less, simply because there are so many offerings. Provided one has handled authentication, there are no special steps necessary to call the various APIs from GCE. In the case of GKE, one may use GCP APIs through a service broker.
Key Takeaways
When deploying Go code on GCP, GKE is the exceptional option. For users who prefer working with VMs directly, GCE is a powerful and comparatively cheap option. While App Engine for Go offers a mix of strengths and weaknesses, most users probably won’t spend much time considering it and instead look at GKE given the justifiable excitement over Kubernetes. Finally, given GCP’s strong machine learning APIs, easily accessible through the Go client library, GCP is worth considering when evaluating IaaS options.
