Bij een moderne filosofie van softwarevoortbrenging en delivery hoort een andere kijk op hoe erg het is als iets niet helemaal verloopt zoals gepland. En eigenlijk is dat zelfs te ouderwets denken, want het veronderstelt dat er een planning is.
De stroming die zich hiermee bezighoudt, heet Chaos Engineering. Er is een manifest beschikbaar op https://principlesofchaos.org/ en een aantal startups (met bijbehorende toolset) houdt zich ermee bezig. In dit artikel een overzicht van de wereld van de chaos, specifiek toegespitst op containers.
Aanleiding
Hoe complexer een systeem wordt, hoe meer componenten samenwerken en hoe sneller functionaliteit in productie wordt gebracht, hoe groter de kans dat er iets misgaat. Verklaar het met de Peter Principle, Gall’s of Murhpy’s Law – alle omvangrijke systemen gaan op enig moment stuk.
In de wereld van Continuous beta, fail fast and fail often is een belangrijk uitgangspunt dat fouten maken niet erg is, zolang er maar snel genoeg wordt ingegrepen en foutherstel zonder al te veel problemen verloopt. Daar zijn het moderne ontwikkelproces en de bijbehorende toolset op ingericht. Geautomatiseerde kwaliteitscontroles vangen fouten bijvoorbeeld al in een vroeg stadium af, ingegeven door de gedachte dat de kosten van herstel later in het ontwikkelproces exponentieel toenemen.
Weerbarstige praktijk
Portabiliteit is een belangrijke eigenschap van werken met containers. In theorie kan een ontwikkelaar zich niet langer verschuilen achter “works on my machine”. De praktijk is echter weerbarstiger. Laura Frank, Director of Engineering bij CodeShip, zegt het als volgt: “Docker isn’t going to solve your scalability and operational reliability problems. It’s true that it can help a lot (using declarative services with a self-healing system like Docker in Swarm Mode or Kubernetes, for example, can ease a lot of the pain), but bottlenecks and performance problems are still going to exist. In some cases, you might even feel more pain because wrapping everything in a container can expose design and process flaws that might have been hidden before.” (https://www.oreilly.com/ideas/using-docker-in-production).
Daaruit spreekt nog een behoorlijk vertrouwen in het herstellende vermogen van een containeromgeving. Ik denk dat het nog iets minder sterk is: de toegenomen ontwikkelsnelheid brengt wel flexibiliteit met zich mee, maar de combinatie daarvan leidt niet per definitie tot de meest stabiele omgeving, nog los van wat er in die omgeving draait. En al helemaal niet als al die losse componenten met elkaar gaan communiceren.
Failure is (not) an option
Op een productieomgeving is het zaak om foutsituaties zoveel mogelijk te vermijden. Vermijden is alleen mogelijk als er inzicht is in gedrag en precies om die reden startte Netflix een aantal jaar geleden een experiment waarin het gedrag van een omgeving in een gecontroleerde setting werd bestudeerd. Dit leidde tot een aantal principes van wat Netflix Chaos Engineering is gaan noemen:
- Beschrijf de normale output van het systeem (de “ready state”) aan de hand van specifieke metrics (zoals latency, througput en fouten) en meet deze gedurende korte tijd;
- Definieer variabelen van verstoring en hun impact, bijvoorbeeld uitval van servers of onevenredig grote toename van berichtenverkeer;
- Experimenteer in productie;
- Automatiseer de experimenten;
- Minimaliseer de impact van de experimenten.
Simpel gezegd is Chaos Engineering het opzettelijk introduceren van fouten in een productieomgeving om mogelijke problemen op te sporen voordat ze uit zichzelf ontstaan. Iets plastischer uitgedrukt: twee handen om de stekker van het SAN en niks graceful shutdown. Het is wel belangrijk goed na te denken over de mogelijke gevolgen, want “starting to break things in production without properly estimating the impact can put your job at risk.” (Ido Cohen van Loadmill). Ik denk dat Ido “will” bedoelt, in plaats van “can”.
Chaos Monkey
Netflix heeft vervolgens het tool Chaos Monkey (https://github.com/Netflix/chaosmonkey) ontwikkeld. Dit tool sluit op willekeurige tijdstippen instanties van applicaties af, zonder verder rekening te houden met waar die applicatie op dit moment mee bezig is. Chaosmonkey is gekoppeld aan het CI/CD platform van Netflix zelf (Spinnaker), maar we zijn natuurlijk vooral geïnteresseerd of het ook rechtstreeks aan Kubernetes en Docker is te hangen. Dat kan bijvoorbeeld via Fabric8, het ontwikkelplatform van Red Hat voor Kubernetes (https://fabric8.io/guide/chaosMonkey.html), maar ook handmatig.
Kubernetes: Kubemonkey
En inderdaad, er is een versie van Chaos Monkey specifiek voor Kubernetes clusters: Kubemonkey (https://github.com/asobti/kube-monkey), waarmee het mogelijk is geautomatiseerd en willekeurig pods te verwijderen uit een productieomgeving. Het tool werkt alleen met applicaties die dat expliciet toestaan (dat is dan weer een spijtige concessie).
Docker: Pumba
Ook voor Docker is een chaos-tool beschikbaar: Pumba (https://github.com/alexei-led/pumba). Hiermee is het mogelijk containers op een verschrikkelijke manier te mishandelen, bijvoorbeeld ze willekeurig onderuithalen of het netwerkverkeer vertragen of stoppen. Meer informatie over hoe het tool werkt van de ontwikkelaar zelf: https://hackernoon.com/pumba-chaos-testing-for-docker-1b8815c6b61e
Binnen Google houdt het Disaster Recovery Testing (DiRT) team zich al een aantal jaar met “The art of breaking Google” bezig, ingegeven door de constatering dat een het hebben van een backup-strategie en uitwijkplannen alleen niet voldoende is. Het team gaat echter veel verder dan alleen de technische infrastructuur: er wordt naar het hele bedrijf gekeken, dus inclusief uitval van medewerkers of fysieke toegang tot gebouwen.
Meer achtergrondinformatie
Een interessante lijst van verdere bronnen over chaos engineering is terug te vinden op Github. https://github.com/dastergon/awesome-chaos-engineering.