Less is more: build small container images

The light virtualization brought by the container technology allows us to finally implement the old good slogan coined by Sun Microsystems “write once, run everywhere” [1], so all cloud native applications built nowadays use multiple container images built by stacking layers and layers, which eventually ends up with very big container images if we do not take the appropriate precautions.

Why small images are good?

Building small images have several important benefits:

• Building speed: the fewer components included within your images the shorter building times, which means that you can merge more commits in less time, improving your agility to make changes, make improvements or fix bugs.

• Deployment speed: any container image is deployed thousands of times during the product’s lifetime on different environments, ranging from development to production. Some of those deployments will be planned and others due to reconfigurations, reboots, outages, bugs, etc. Products that use smaller images can be deployed faster and therefore they will recover from failures faster as well, which means less downtime for your service.

• Storage savings: although storage is cheap, both locally and on the cloud, it is important to take into account that container images are built by stacking layers [2], and those layers are stored temporary both on the local cache and on the Container Registry which can rapidly increase the total amount of storage needed.

• Bandwidth savings: during a product’s lifecycle its container images are going to be uploaded (with every new tag) and downloaded onto the deployments environments (Docker Swarm, Kubernetes, OpenShift, etc.) thousands of times, so the smaller their size the lesser the bandwidth consumed by that traffic.

• Costs savings: as highlighted on the previous points, storage and bandwidth, although cheap nowadays, cost money in all the cloud computing services out there. Heavy images take more time to be built and tested, so it we will need more CI/CD minutes to do so and those minutes are the key cost driver for almost every CI/CD system out there.

• Security: last but not least, it is well known that all software components have security vulnerabilities; so every component added to each of the image’s layer will be accumulating their own vulnerabilities, from the base image to the latest software installed, widening the attack surface of your image. If you want to improve the security of your images, install only the essential applications and packages needed, nothing else.