I’m a huge fan of Go, and I’m also really interested in containers, and how they make it easier to deploy code, especially at scale. But not all Go programmers use containers. In this article I’ll explore some reasons why you really should consider them for your Go code—and then we’ll look at some cases where containers wouldn’t add any benefit at all.
First, let’s just make sure we’re all on the same page about what we mean by “containers.”
There are probably about as many different definitions of what a container is as there are people using them. For many, the word “container” is synonymous with Docker, although containers have been around a lot longer than either the Docker open-source project or Docker the company. If you’re new to containers, Docker is probably your best starting point, with its developer-friendly command line support, but there are other implementations available:
Container implementations including LXC and LXD
Pod-native container engine from CoreOS
Running containers per the OCI specification
Windows Server containers and Hyper-V containers
Containers are a virtualization technology—they let you isolate an application so that it’s under the impression it’s running in its own physical machine. In that sense a container is similar to a virtual machine, except that it uses the operating system on the host rather than having its own operating ...