Wat we ermee bouwen
Containers zijn hoe alles wat we schrijven verpakt raakt. Een backendservice, een geplande taak, een buildomgeving — elk daarvan is een image met de afhankelijkheden erin vastgezet, zodat "het werkt op mijn machine" ophoudt een soort bug te zijn.
Het praktische voordeel duikt op zodra iemand nieuw bij een project komt. In plaats van een installatiedocument dat een half jaar achterloopt is er een compose-bestand: één commando brengt de service, de database en de afhankelijkheden op in de versies die het project werkelijk gebruikt.
Waar we het hebben ingezet
Al ons backendwerk draait in containers, inclusief de services achter de projecten in ons portfolio. Ook deze site wordt als container-image gebouwd en uitgerold.
Wanneer we het aanraden
Voor elke service die ergens anders wordt uitgerold dan op de machine waarop hij is geschreven — dat zijn ze allemaal. De kosten zijn een Dockerfile; de opbrengst is een reproduceerbare build en een uitrolverhaal dat niet afhangt van de staat van een server.
Waar we tegenin gaan, is een lokale ontwikkelworkflow in een container stoppen die al eenvoudig is. Is een project één binary zonder afhankelijkheden, dan voegt een container om de ontwikkellus vooral wrijving toe. Lever het image uit; ontwikkel er niet per se in.
In productie draaien die images op Kubernetes.
