Chapter 1. Should You Containerize Your Go Code?
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.”
What Is a Container?
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:
- Linux Containers
Container implementations including LXC and LXD
- rkt
Pod-native container engine from CoreOS
- runc
Running containers per the OCI specification
- Windows Containers
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 ...
Get Should You Containerize Your Go Code? now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.