In het eerste deel van deze serie legde ik uit wat Infrastructure as Code (IaC) is en waarom het zo belangrijk is voor moderne cloudoplossingen. Maar wie is er eigenlijk verantwoordelijk voor al die geautomatiseerde infrastructuur? Welke rollen spelen een cruciale rol bij het succesvol implementeren van IaC? En hoe zorg je ervoor dat je niet alleen technisch, maar ook financieel de juiste keuzes maakt? Dat lees je in dit tweede deel.
Bij het werken met IaC zijn er 3 belangrijke rollen die nauw met elkaar samenwerken: de enterprise architect, de solution architect en de support engineer. In mijn werk als infrastructuurconsultant zie ik hoe elk van deze rollen bijdraagt aan het succes van cloudoplossingen. Tenminste, in het ideale geval. Want er zijn ook wel eens misverstanden over wie waarvoor verantwoordelijk is.
Om die te voorkomen schets ik hoe voor mij het ideale plaatje eruitziet.
Enterprise architect en solution architect: heldere verantwoordelijkheden
De enterprise architect zet de kaders voor de hele organisatie en neemt bijvoorbeeld cruciale beslissingen over welke cloudplatforms er wel en niet gebruikt worden. Dit heeft enorme invloed op de implementatie van IaC. Dat werkt nou eenmaal anders in een multicloud-omgeving dan in een organisatie met een ‘Microsoft tenzij’-beleid.
Het is ook de verantwoordelijkheid van de enterprise-architect om een knoop door te hakken over naming conventions, netwerkinrichting en het gebruik van subscriptions. Je krijgt als solution team bijvoorbeeld vanuit de architectuur 1 subscription voor development, 1 voor test en 1 voor productie. In de praktijk zie ik hoe belangrijk dit is: zulke richtlijnen zorgen dat alle teams binnen dezelfde kaders werken.
Binnen die kaders is het aan de solution architect om de concrete IaC-implementatie te ontwerpen. Want infrastructuur is wat mij betreft gewoon deel van de oplossing. De solution architect weet wat de oplossing moet kunnen en kiest welke componenten, netwerkconfiguratie en authenticatiemethoden daarbij horen. De developers rollen dat dan consistent uit, omdat ze bij iedere omgeving die ze inrichten dezelfde code gebruiken.
De support engineer hoeft niet meer alle details te kennen
De derde rol die belangrijk is bij IaC, is die van de support engineer. Een support engineer is meestal verantwoordelijk voor meerdere oplossingen. Als al die oplossingen eigen infrastructuur richtlijnen gebruiken, is dat geen pretje. Want het is totaal onmogelijk om op de hoogte te zijn van alle details daarvan.
Het mooie is: dankzij IaC hoeft dat ook niet meer. Als de enterprise architect en de solution architects hun werk gedaan hebben, tenminste. Omdat alles dan volgens vaste patronen is ingericht, werken alle oplossingen op dezelfde manier en maakt het dus niet uit aan welke oplossing de support engineer moet werken. Alles heeft voorspelbare, duidelijke namen, alles is op dezelfde manier met elkaar verbonden en alle softwarecomponenten staan waar de support engineer ze verwacht. Dat scheelt heel veel zoeken en bellen.
De financiële kant van infra vraagt om bewuste keuzes
En dan ontbreekt er eigenlijk nog een rol: die van het hoger management. Want een cruciaal aspect van IaC, en cloud-infra in het algemeen, is de financiële impact. In mijn ervaring zijn CEO’s vaak sterk gericht op de functionaliteiten van hun software en hebben ze minder oog voor de infrastructuur. Dat is begrijpelijk, want vanuit hun perspectief is infra een randvoorwaarde. Het zijn de features waarmee ze klanten aantrekken en concurrenten voorblijven. Het is dus vaak aan de architecten, developers en support engineers (en natuurlijk aan mij als consultant) om IaC te ‘verkopen’ aan het hoger management.
Niet per se een moeilijke klus, afhankelijk van in welk stadium product en bedrijf zich bevinden (meer daarover in deel 3), want een cloudomgeving kost serieus geld en als je die niet goed inricht komt de ROI van je project snel in gevaar.
Financiële verantwoordelijkheden in het team
De solution architect moet in het ontwerp ook rekening houden met de kosten. ‘We hebben een SQL-database nodig’ is niet specifiek genoeg. Want dat kan een Mercedes van een omgeving zijn, terwijl je misschien aan een Ford Focus genoeg hebt. Het gaat er dus om de juiste balans te vinden tussen functionaliteit en kosten.
Ook het support team heeft een belangrijke rol in kostenbewaking. Een support engineer die in het latere traject de software moet onderhouden, ziet ook de kosten en kan waar nodig ingrijpen: “Hé jongens, ik zie dat deze server 5000 euro per maand kost, klopt dat? Of kan dat minder?” Zo’n proactieve houding helpt om onnodige kosten te voorkomen.
Slim differentiëren met IaC
Eén van de grote voordelen van IaC is dat je makkelijk verschillende varianten van een omgeving kunt maken. In een ontwikkelomgeving heb je bijvoorbeeld genoeg aan een kleine, simpele server, terwijl je in productie weet dat er dagelijks 10.000 mensen op werken en je dus een robuustere machine nodig hebt. Door deze flexibiliteit kun je de kosten optimaliseren zonder in te leveren op kwaliteit, terwijl je nog steeds profiteert van de voorspelbaarheid van IaC-omgevingen.
In het volgende deel van deze serie ga ik dieper in op de praktische implementatie van IaC en bespreek ik concrete voorbeelden van hoe je dit aanpakt in jouw organisatie.
