De infrastructure as code is in onze IS verschenen om zowel dev als ops te verzoenen of te revolutioneren, laten we hier de belangrijkste succesfactoren van deze methode ontdekken.
... op voorwaarde van een nauwe samenwerking in het begin
Infrastructure as Code is een revolutie in software engineering door consistentie tussen omgevingen te brengen die voorheen ontbrak in versiebeheer en testen. Dat gezegd zijndeIaC ook een transformatie van methoden met zich meebrengt die een zekere voorzichtigheid impliceert en niet mag worden genegeerd.Maar IaC brengt ook een transformatie van methoden met zich mee die een zekere voorzichtigheid impliceert en ons de primordiale rol van de infrastructuuringenieurs niet mag doen vergeten, ten voordele van de ontwikkelingsteams.
L'IaCsneller en beter
Het doel van Infrastructure as Code of IaC is het codificeren van de infrastructuur die ter beschikking wordt gesteld van de toepassingen van het bedrijf. Het maakt het met name mogelijk dezelfde technische enveloppe op geautomatiseerde wijze, en zo nodig continu, te reproduceren op alle bruikbare omgevingen (ontwikkelings-, integratie-, preproductie- of productieomgevingen).
Het voornaamste voordeel van IaC en de standaardisatie die het mogelijk maakt, is dat het de ontplooiing van omgevingen aanzienlijk versnelt en tegelijkertijd de consistentie ervan waarborgt.
Deze wedloop naar snelheid kan soms vragen oproepen. Tien jaar geleden was snelheid al de belofte van Cloud via een PaaS dat vooraf gedefinieerde modellering biedt. Hoewel de IT-afdeling haar methoden grondig heeft kunnen omvormen, tot tevredenheid van zowel de ontwikkelingsteams als de business, moet worden erkend dat de processen nog voor verbetering vatbaar zijn.
Via DevOps ontstond al snel het probleem van identieke replicaties van omgevingen, en via hen, de noodzakelijke documenten voor de beschrijving van de middelen, de uitleg die aan de Ops-teams moest worden gegeven over de gemaakte keuzes en de eeuwige discussies die daaruit voortvloeiden. Kortom, er waren veel zandkorrels die de machine regelmatig blokkeerden.
IaC zorgt ervoor dat ontwikkelingsteams end-to-end controle hebben over de operaties, zodat ze alle gewenste infrastructuur kunnen coderen voor de toepassingen die ze maken. En nog veel meer.
Use cases van Infrastructure as Code met dev en ops
In een DevOps-proces hangt de snelle inzet van nieuwe applicaties daarom in de eerste plaats af van het vermogen van het bedrijf om resources (en hun provisioning) te automatiseren en consistente omgevingen te creëren.
Daarnaast kunnen bedrijven nog vele andere toepassingen vinden.
Door het concept van van gecontaineriseerde microservices, kan de onderneming profiteren van horizontale flexibiliteit. Dit zal het geval zijn wanneer een toepassing die gewoonlijk niet erg druk is, dit in een bepaalde periode wel wordt. Een terugkerende gebeurtenis kan tot dit soort situaties bijdragen (sportevenement, verkiezingsperiode, enz.). Met het IaC kan de productieomgeving meerdere malen worden gereproduceerd om pieken in het verkeer op te vangen, zeer gemakkelijk en in een uiterst korte tijd.
Infrastructuur als code is ook interessant in situaties waarin een upgrade nodig is, om te kunnen profiteren van een volledig gerepliceerde productieomgeving tijdens de test- of productiefase.
Dezelfde voordelen van consistentie en snelheid zullen worden gevonden wanneer het gaat om het creëren van opleidingsomgevingen, die moeten worden geparallelliseerd om plaats te bieden aan meerdere talen.
Deze mogelijkheid om snel identieke omgevingen te creëren is gekoppeld aan de mogelijkheid om automatisch middelen te vernietigen. Voor alle bedrijven die last hebben van overmatig verbruik van Cloud, is het automatisch verwijderen van omgevingen misschien wel het belangrijkste punt om voor IaC te kiezen. Het is in ieder geval een basisbouwsteen van een FinOps-strategie, vooral voor grootverbruikers Cloud en Cloud .
De toegankelijkheid van Infrastructure as Code in de onderneming voor dev en ops
IaC is gericht op bedrijven die ten minste gedeeltelijk volwassen zijn in Cloud , al was het maar omdat het een nieuwe manier van denken over infrastructuur inhoudt. Toch kan er sprake van zijn dat men massaal al zijn omgevingen wil automatiseren. Hoewel het vroegtijdig invoeren van nieuwe technologieën niet de favoriete sport is van Franse bedrijven, zijn sommige avontuurlijker dan andere.
Het is echter raadzaam zich alleen te richten op projecten en niet op reeds gecreëerde omgevingen. Hoewel de overgang naar IaC op bestaande systemen op papier niet onhaalbaar is, gaat het principe van idempotence, d.w.z. de definitie van de doelomgeving die aan de basis ligt van IaC, ervan uit dat de softwareomgeving (Terraform bijvoorbeeld) op de hoogte is van alle middelen die ter beschikking worden gesteld. Dit betekent dat het gehele park (netwerk, opslag, server, enz.) moet worden gemodelleerd tot een basisbouwsteen die in het IaC-hulpmiddel kan worden gebruikt. En dit kan een hoop werk zijn.
Terwijl het risico op mislukking in bestaande omgevingen groot is, kan dat niet worden gezegd van toekomstige omgevingen. Er zijn echter enkele goede samenwerkingspraktijken die te vaak over het hoofd worden gezien.
Het einde van teamwork?
Met IaC zou men kunnen denken dat Dev-teams almachtig worden, een idee dat wordt geschraagd door automatische reproduceerbaarheid, waardoor zij zich kunnen bevrijden van de systeemingenieur, de databasebeheerder en de netwerk- en opslagbeheerder. Het is waar dat ontwikkelaars nu alles zelf kunnen doen op Cloud , maar is dat wel zo'n goed idee?
Enerzijds vereist de initiële planning van een "Infrastructure as a Service" een zekere mate van overleg met alle belanghebbenden van een IT-infrastructuur, of op zijn minst een gedetailleerde kennis van de constructie van de modules die van de plank beschikbaar zullen zijn en die dan het Terraform zullen vormen (als dat het gekozen instrument is).
Anderzijds zijn er maar weinig bedrijven die vandaag geen specifiek beleid hebben ontwikkeld dat moet worden gevolgd, ongeacht de infrastructuur. Met andere woorden, het zal aan de ontwikkelaars zijn om alle regels die in naam van de systeem- en gegevensbescherming zijn vastgesteld, onder de loep te nemen alvorens hun omgevingen te definiëren.
Bijgevolg kan IaC niet zonder een volledig collectief voorbereidend werk, waarbij alle betrokken beheerders, databases, opslag, netwerk, applicatie-architecten, alsmede de basiskennis die onontbeerlijk is, worden betrokken. Daarom is het, in tegenstelling tot wat de IaC suggereert, van belang dat de verantwoordelijkheid voor de invoering van deze oplossingen wordt gedragen door de infrastructuurbeheerder, die het best in staat is om alle vereiste vaardigheden te bundelen tijdens de lanceringsfasen.
