Onderhoudbaarheid tip 5: Automatiseer de infrastructuur

Rol van de infrastructuur

Onderhoudbaarheid zit niet alleen in de specifieke applicatiecode, maar ook in de onderliggende infrastructuur. Zoals in deel 1 besproken bepalen o.a. de herbruikbaarheid, analyseerbaarheid en modulariteit de mate van onderhoudbaarheid van een applicatie. Elke nieuwe release komt uiteindelijk in een productieomgeving terecht en dient te functioneren volgens de gestelde eisen (beschikbaarheid, schaalbaarheid, performance, security, etc.). Pas wanneer ook deze laatste stap geslaagd is, kan de onderhoudbaarheid beoordeeld worden. Een applicatie waarvan de *technical debt** *op een acceptabel niveau is en de testbaarheid hoog is, kan toch voor veel problemen zorgen bij het in productie nemen.

Veel voorkomende issues

Bij het in productie nemen van een maatwerk applicatie komen vaak de volgende issues voor:

• Doordat beheerders van de productieomgeving de installatie handmatig uitvoeren, is een volledige en kloppende installatie-instructie nodig. Hier zitten geregeldonvolkomenheden in die niet eerder in het proces zijn opgemerkt, met een foutieve inproductiename tot gevolg;
• Doordat er verschillen zijn ontstaan tussen de specificaties van de infrastructuur en de daadwerkelijke infrastructuur, ontstaan issues bij de inproductiename. Waarom werkt het nu wel op de acceptatie-omgeving maar niet op de productie-omgeving?! Dit wordt Configuation Drift genoemd;
• Door toenemendemodulariteit (en schaalbaarheid) is het aantal (virtuele) machines of containers steeds groter aan het worden. Dit verhoogt de complexiteit en de kans op fouten bij een handmatige update. Bijvoorbeeld wanneer onderdelen vergeten worden bij een installatie.
  

Automatiseer de infrastructuur

Door de opkomst Cloud computing en Infrastructure as a Service (IaaS) is tooling voor Infrastructure as Code (IaC) steeds meer beschikbaar gekomen. Tevens groeide de behoefte om sneller applicaties in productie te nemen. Dit zorgde ervoor dat de traditionele silo’s (development en operations) en bijbehorende ‘overdracht’ niet meer wenselijk zijn. Te traag en te veel kans op fouten. Met de opkomst van DevOps teams (agile teams met een mix van development en operations die verantwoordelijk zijn voor de hele application lifecycle) is het mogelijk de infrastructuur te beschrijven in code. Net als de applicatie zelf. Hierdoor is het mogelijk vanuit code de infrastructuur op te tuigen, zonder handmatige handelingen. Voordelen van Infrastructure as Code?

• De infrastructuur is bij elkedeployment geautomatiseerd op te tuigen, is altijd hetzelfde en daardoor testbaar. Hiermee voorkomen we het ‘It works on my machine‘ probleem;
• Wijzigingen in de infrastructuur (bijv. patches op Operating System, Applicatie server, etc.) worden nu in code gemaakt en getest. Door infrastructuur in code te beschrijving, kan gebruik gemaakt worden van de voordelen vanContinuous Integration, zoals versiebeheer en automatische testen;
• Patches, versies van componenten, zijn nu eenvoudig te vinden in een bepaald deel van de infrastructuur. In feite niets anders dan een zoekopdracht in de code. De code is per definitie gelijk aan de productieomgeving. Wat niet gezegd kan worden van eventuele specificaties of een CMDB;
• Veel sneller en goedkoper door het wegvallen van handmatige handelingen. Tevens verkleint een geautomatiseerde uitrol de kans op fouten aanzienlijk. Tooling die veel gebruikt worden voor het automatiseren van infrastructuur zijn

Puppet, Chef en Ansible. Hiermee past deze aanpak bij Continuous Deployment, waarin de deployment over alle OTAP-omgevingen geautomatiseerd plaatsvindt en continu getest kan worden of de hele stack (van userinterface tot en met infrastructuur) voldoet aan de eisen, en dus werkt! Volgende week het laatste deel. Dan staan we stil bij overdraagbaarheid.