In de eerste twee delen van deze serie hebben we gekeken naar wat Infrastructure as Code (IaC) is en welke rollen er belangrijk zijn bij de implementatie ervan. In dit laatste deel wil ik ingaan op een vraag die ik vaak krijg: wanneer is het juiste moment om met IaC te beginnen?
Voordat ik bij Blis Digital kwam, werkte ik veel met Enterprise-klanten met zeer volwassen Azure-omgevingen. Infrastructure as Code was daar de norm, handmatige configuraties waren de uitzondering.
Bij Blis werkt dat een beetje anders. De klanten van Blis zijn snel en ambitieus, innoveren dus snel en geven de inrichting van de infrastructuur minder prioriteit. Dat is logisch, gezien hun focus op time to market, maar het is precies de reden waarom ik nu deel uitmaak van het team van Blis: IaC draagt, omdat het je infrastructuur standaardiseert en dus bugs en onvoorspelbaarheid voorkomt, juist bij aan het snel lanceren van nieuwe features.
Tenminste, als je op het juiste moment begint.
Wat dat betreft zijn er in mijn ervaring 2 mogelijke situaties:
Scenario 1: handmatige configuratie werkt naar behoren
Het eerste scenario dat ik regelmatig tegenkom: de software draait in de cloud, maar hebben alles handmatig geconfigureerd. En dat werkt dus prima. Het zal je misschien verbazen, maar ik zou zo’n bedrijf niet snel adviseren om alles om te gooien en over te stappen naar IaC. Want dat kan een complex traject zijn en niet zonder risico, terwijl de verwachte voordelen voor een stabiel draaiende oplossing daar niet tegen opwegen.
Dat wordt anders als er daar ineens een investeerder binnenkomt die stevig aan de internationale marketing gaat trekken. Of er stappen om andere redenen ineens duizend nieuwe klanten in, het datacenter moet verhuizen of er verloopt een softwarelicentie. Dat zijn situaties waarin je sowieso gedwongen wordt om kritisch naar je infrastructuur te kijken. En dan ontdek je dat een handmatig ingerichte omgeving het lastig maakt om snel op te schalen en wijzigingen door te voeren.
Dan wordt het ineens wél interessant om met IaC aan het werk te gaan.
Partners die eisen stellen
IaC kan voor deze bedrijven ook ineens relevant worden als ze met leveranciers gaan werken die hun diensten in de cloud aanbieden. Of als klanten hun software ‘doorverkopen’ en onderdeel maken van hun eigen diensten. In feite word je als softwaremaker dan PaaS (Platform as a Service)-leverancier. In beide situaties worden infrastructuren niet alleen complexer, voorspelbaarheid, schaalbaarheid en stabiliteit worden ook veel belangrijker.
Tenslotte kan het ook zo zijn dat wij van Blis Digital eisen stellen aan hoe de infrastructuur geconfigureerd wordt. Dat doen we als klanten ons vragen om hun Azure-omgeving voor ze te onderhouden. Dat lukt ons alleen kosteneffectief als de omgeving heel erg gestandaardiseerd en stabiel is. Dus dan is IaC de enige optie.
Scenario 2: greenfield
In het tweede scenario is IaC voor mij een no-brainer: bedrijven die net beginnen met software bouwen in de cloud. Als je nu aan een nieuw digitaal product begint, dan is er gewoon geen goede reden om je infrastructuur niet in code te definiëren. Ook al is je oplossing klein en simpel van aard. Dan past in eerste instantie het IaC-bestand zonder scrollen op je scherm en neem je dat gewoon vanaf het begin mee. Daar heb je later veel plezier van.
Tot slot
IaC is dus geen doel op zich, maar een middel om je infrastructuur beheersbaar, schaalbaar en voorspelbaar te maken. Het juiste moment om te beginnen hangt af van je situatie. Begin je net? Start dan meteen met IaC. Heb je al een draaiende omgeving? Wacht dan op het juiste moment, zoals een grote verandering in je organisatie, om de overstap te maken. Want uiteindelijk moet je infrastructuur je helpen om je doelen te bereiken, niet andersom.
