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.
FAQ
Veelgestelde vragen
Die beantwoorden we graag alvast. Staat je vraag er niet tussen, neem dan gerust contact op.
Als je handmatig ingerichte cloudomgeving prima werkt en stabiel draait, is overstappen niet per se nodig. De overstap is een complex traject met risico's, terwijl de voordelen voor een stabiele oplossing daar in dat geval niet tegenop wegen.
Denk aan een investeerder die op internationale groei aanstuurt, duizend nieuwe klanten in korte tijd, een verhuizing van het datacenter of een aflopende softwarelicentie. In die situaties wordt het lastig om snel te groeien met een handmatig ingerichte omgeving, en wordt IaC ineens interessant.
Zodra je met cloudleveranciers werkt of klanten je software als PaaS gaan doorverkopen, wordt de infrastructuur complexer en worden voorspelbaarheid en stabiliteit belangrijker. Ook Blis Digital stelt eisen aan de configuratie als het jouw Azure-omgeving gaat onderhouden, want dat lukt alleen kosteneffectief bij een gestandaardiseerde omgeving.
Bij een nieuw digitaal product is er geen goede reden om de infrastructuur niet meteen in code te definiëren, ook niet bij een klein of simpel project. Het IaC-bestand past dan zonder scrollen op je scherm, en daar heb je later veel plezier van.
Dat hangt af van je situatie: begin je net, start dan meteen met IaC. Draait er al een omgeving, wacht dan op een grote verandering in je organisatie om de overstap te maken. Je infrastructuur moet je doelen dienen, niet andersom.
