Maar het deel van de hele infrastructuur uitrollen via scripting (wat eigenlijk infrastructure as code is) is al veel ouder, hier was men al mee bezig voor het hele ‘cloud’ gebeuren. Dat zagen we eigenlijk al toen men van dedicated fysieke servers naar VMs ging, zeker bij de enorme bedrijven. Dat we er nu meer van zien in de ‘cloud’ zou ik het nog steeds niet als deel van de ‘cloud’ beweging willen benoemen.
Persoonlijk vind ik infrastructure as code heel cool, maar ook heel gevaarlijk. De afstand tussen de ‘script beheerders’ (zij die al hun systemen beheren dmv. scripts) en de daadwerkelijke servers/software is al groot en wat ik in de praktijk zie is dat die afstand alleen maar groter wordt. Ik zie het risico voor enorme fouten veel groter worden, niet omdat ‘infrastructure as code’ een slecht idee is, maar omdat je verwacht dat je infrastructure op een bepaalde manier functioneert. Als dat opeens door settings of patches heel anders functioneert en dat je daar niet van op de hoogte bent of niet/slecht is gedocumenteerd dan kan dat heel fout gaan.
Het is bv. niet de eerste keer dat ik beheerders heb meegemaakt die nog nooit hebben aangemeld op de servers die ze beheren. Ja, maar we zien ‘alles’ via scripting en logging! Maar soms zie je dus niet alles omdat je daarvoor (nog) niet script en logt… Laat ik een voorbeeld geven: Gebruikers hebben opeens zware performance problemen op verschillende RDP servers, ik meld aan op die servers en mijn conclusie is vrij vlot dat er inderdaad iets zwaar mis gaat met servers, steeds meer servers. Uiteindelijk blijkt dat een ander onderdeel beheerders doodleuk extra software is gaan deployen (via scripting) naar alle (VM) servers ivm. het tellen van licenties… Geen documentatie, geen interne berichtgeving. Ik heb heel wat moeten uitzoeken en moeten overtuigen voordat de andere partij toegeef dat dit een issue was omdat ZIJ geen performance issues zagen… Nu kan je dat gooien op slechte beheerders (dat waren ze trouwens niet), maar doordat je zo een afstand heb tussen wat je doet en de mensen die er daadwerkelijk mee werken kom je heel snel in een bepaalde mentaliteit terecht, niet iedereen (jij niet natuurlijk! 
), maar een hele hoop zeker wel.
De afgelopen ~10 jaar doe ik al aan ‘cloud’ migraties en doe daar over het algemeen heel weinig met infrastructure as code, vele jaren bij MSPs gezeten voor het MKB, daar zit je zo vaak met heel specifieke implementaties, dat infrastructure as code meer werk opleverde dan dat het bespaarde (en het was in 2013 een heel stuk complexer dan dat het nu is. Maar zelfs tijdens de pandemie zie je bij grotere bedrijven dat men wil beginnen aan infrastructure as code, maar dat niet alle infrastructure daar klaar voor was. Zo heb ik een tijd terug naar de oplossingen van MS zelf gekeken voor O365, ja dat kon wel, lastig, koste veel tijd en was omslachtig, maar het was ook nog eens een keer hardstikke onveilig! Gewoon niet fit for purpose buiten testopstellingen, ondertussen zie ik wel zaken voorbijkomen waaruit het lijkt dat het nu wat veiliger kan, maar ik zie nog steeds ‘uitdagingen’… Denk aan Global Administrator accounts welke met username en ww in het script moeten staan…
Deel van die grote ‘cloud’ verschuiving is niet alleen lift-and-shift (waar ik een gruwelijke hekel aan heb), maar juist ook allerlei diensten die taken integreren die je zelf allemaal lokaal moest hosten/configureren. Denk aan lokale SSO, MFA, etc. oplossingen die nu allemaal geïntegreerd aangeboden (kunnen) worden. Ik zie juist als je een goede ‘cloud’ migratie uitvoert je met een heleboel minder bewegende onderdelen zit dan als je alles zelf hoste/deployde. En tegen prijzen waar lokale oplossingen niet tegenop kunnen boxen.
Recent Comments