Over DevOps en Snowflakes

Men kan tegenwoordig nauwelijks een spreekwoordelijke kat door de IT slingeren zonder mensen over DevOps te horen praten. DevOps is het hete nieuwe onderwerp in de branche dat de fakkel overneemt waar het gepraat over de cloud ophield, en wanneer men mensen erover hoort praten, zou men kunnen geloven dat traditioneel systeembeheer reeds dood en begraven is.

Eerst moeten wij bespreken wat wij met DevOps bedoelen. Dit kan verwarrend zijn, omdat, net als bij de cloud, vaak een oudere term wordt ontvreemd om iets anders te betekenen, of, op zijn best, iets wat verband houdt met iets wat al bestond. Traditionele DevOps was het samenvoegen van ontwikkelaars- en operationele rollen. Van de jaren zestig tot de jaren negentig was dit de standaardmanier om systemen te beheren. In deze wereld waren de mensen die de software schreven over het algemeen dezelfden die haar uitrolden en onderhielden. Vandaar het samenvoegen van “developer” (ontwikkelaar) en “operations” (beheer), waarbij operations een semi-standaardterm is voor de rol van systeembeheerder. Deze rollen werden doorgaans niet gescheiden tot de opkomst van de “IT-afdeling” in de jaren negentig en de jaren 2000. Sindsdien is de terugkeer naar het samenvoegen van de twee rollen weer in populariteit beginnen toe te nemen, voornamelijk vanwege de wijze waarop de twee met grote waarde kunnen samenwerken in veel moderne, gehoste webapplicatiesituaties.

Waar DevOps tegenwoordig vaak over gesproken wordt, is niet als een strikte samenvoeging van de ontwikkelaars en het operationeel personeel, maar als een wijziging van het operationeel personeel met een veel grotere nadruk op het coderen, niet van de applicatie zelf, maar van het definiëren van applicatie-infrastructuren als code, als een natuurlijke uitbreiding van cloudarchitecturen. Dit kan in eerste instantie tamelijk verwarrend zijn. Wat van belang is om op te merken, is dat traditionele DevOps niet is wat zich tegenwoordig vaak voordoet, maar een nieuwe “nep”-DevOps, waarbij ontwikkelaars ontwikkelaars blijven en beheer beheer blijft, maar waarbij het beheer is geëvolueerd tot een nieuwe, “code-intensieve” rol die zich blijft richten op het beheren van servers die code uitvoeren die door de ontwikkelaars wordt aangeleverd.

Wat tegenwoordig significant is, is dat de rol van de systeembeheerder zich is gaan splitsen in twee verwante, maar significant verschillende rollen, waarvan er een door het merendeel van de branche tegenwoordig ten onrechte DevOps wordt genoemd (waarbij het merendeel van de branche te jong is om zich te herinneren toen DevOps de norm was, niet de uitzondering, en zeker niet iets nieuws en noviteits). Ik verwijs hier naar deze twee aspecten van de systeembeheerdersrol als de DevOps- en de Snowflake-benaderingen.

Ik gebruik de term Snowflake om te verwijzen naar traditionele architecturen voor systemen, omdat elke individuele server gezien kan worden als een “unieke Snowflake” (sneeuwvlok). Zij zijn allemaal verschillend, althans voor zover zij niet op de een of andere wijze zodanig worden beheerd dat zij identiek worden gehouden. Dit betekent niet dat zij allemaal uniek moeten zijn, slechts dat zij het potentieel behouden om dat te zijn. In traditionele omgevingen logt een systeembeheerder afzonderlijk op elke server in om eraan te werken. Een zekere mate van scripting is gangbaar om beheertaken te vergemakkelijken, maar in de kern behelst de rol veel tijd waarin aan individuele systemen wordt gewerkt.

Het vergemakkelijken van het beheer van Snowflake-architecturen behelsde vaak pogingen om de verschillen tussen systemen op redelijke wijze te minimaliseren. Dit begint over het algemeen met zaken als het kiezen van één standaardbesturingssysteem en -versie (Windows 2012 R2 of Red Hat Enterprise Linux 7) in plaats van toe te staan dat elke serverinstallatie een ander besturingssysteem of een andere versie is. Deze standaardisatie lijkt wellicht basaal, maar veel afdelingen ontberen deze standaardisatie zelfs vandaag de dag.

Een volgende stap is doorgaans het creëren van een standaard uitrolmethode of een gouden master-image die wordt gebruikt voor het maken van alle systemen, zodat het basisbesturingssysteem en alle basispakketten, vaak inclusief systeemaanpassingen, monitoringpakketten, beveiligingspakketten, authenticatieconfiguratie en soortgelijke wijzigingen, standaard zijn en uniform worden uitgerold. Dit biedt een gemeenschappelijk uitgangspunt voor alle systemen om afwijking te minimaliseren. Maar technisch gezien waarborgen zij slechts een standaard uitgangspunt, en in de loop der tijd moet er op afwijking in de configuratie worden geanticipeerd.

Naast deze stappen maken Snowflake-omgevingen doorgaans gebruik van op maat gemaakte, specifieke beheerscripts of beheertools om in de loop der tijd enige standaardisatie tussen systemen te handhaven. Hoe meer overeenkomsten er tussen systemen bestaan, des te eenvoudiger zij te onderhouden en problemen op te lossen zijn, en des te minder kennis er nodig is bij het beheerpersoneel. Meer standaardisatie betekent minder verrassingen, minder onbekenden en veel betere testmogelijkheden.

In een omgeving met één systeembeheerder met goede werkwijzen en goed gereedschap kunnen Snowflake-omgevingen een hoge mate van standaardisatie aannemen. Maar in omgevingen met vele systeembeheerders, met name die welke rond de klok vanuit vele regio's worden ondersteund, en met een groot aantal systemen, kan standaardisatie, zelfs met zeer nauwgezette werkwijzen, zeer moeilijk worden. En dat is nog vóór wij de voor de hand liggende kwesties aanpakken rondom het feit dat verschillende pakketten en mogelijk pakketversies nodig zijn op systemen die verschillende rollen vervullen.

De DevOps-benadering groeit organisch voort uit het cloudarchitectuurmodel. Cloudarchitectuur is ontworpen rondom automatisch aangemaakte en automatisch vernietigde, in grote lijnen identieke systemen (althans in groepen) die worden bestuurd via een programmatische interface of API. Dit model leent zich, vrij vanzelfsprekend, ervoor om centraal te worden bestuurd via een beheersysteem in plaats van via de handmatige inspanningen van een systeembeheerder. Handmatig beheer is in de praktijk onmogelijk en volstrekt onpraktisch onder dit model. Individuele systemen zijn niet uniek zoals in het Snowflake-model, en elke afwijking zal ernstige problemen veroorzaken.

Het idee dat is voortgekomen uit de wereld van de cloudarchitectuur, is dat de systeemarchitectuur centraal “in code” gedefinieerd zou moeten worden in plaats van op de servers zelf. Dit klinkt in eerste instantie verwarrend, maar is heel logisch wanneer wij er dieper naar kijken. Om dit model te ondersteunen is een nieuw type systeembeheertool, dat nog geen werkelijk standaard naam heeft aangenomen maar vaak een systeemautomatiseringstool, DevOps-framework, IT-automatiseringstool of simpelweg “infrastructure as code”-tool wordt genoemd, beginnen op te komen. Veelvoorkomende toolsets binnen dit domein zijn onder meer Puppet, Chef, CFEngine en SaltStack.

Het idee achter deze automatiseringstoolsets is dat een centrale dienst wordt gebruikt om alle systemen te beheren en te besturen. Deze centrale autoriteit beheert individuele servers door middel van op code gebaseerde beschrijvingen van hoe het systeem eruit zou moeten zien en zich zou moeten gedragen. In de Chef-wereld worden deze “recipes” (recepten) genoemd, om leuk te zijn, maar de analogie werkt goed. De code van elk systeem kan informatie bevatten zoals een lijst van welke pakketten en pakketversies geïnstalleerd zouden moeten worden, welke systeemconfiguraties gewijzigd zouden moeten worden en bestanden die naar de machine gekopieerd moeten worden. In veel gevallen worden beslissingen over deze uitrollen of wijzigingen afgehandeld via potentieel complexe logica, en vandaar de behoefte aan daadwerkelijke code in plaats van iets simpelers zoals opmaaktaal of sjablonen. Systemen worden vervolgens gegroepeerd op rol en als groepen beheerd. De rol “webserver” zou een verzameling systemen kunnen opdragen om Apache en PHP te installeren en het geheugen zodanig te configureren dat er zeer weinig wordt geswapt. De rol “SQL Server” zou MS SQL Server kunnen installeren en speciale back-uptools die alleen voor die applicatie worden gebruikt, en het geheugen zodanig kunnen configureren dat het wordt afgestemd zoals gewenst voor een pool van SQL Server-machines. Dit zijn slechts voorbeelden. Doorgaans zou een organisatie zeer veel rollen hebben, sommige mogelijk generiek zoals “webserver” en andere veel specifieker om zeer specifieke applicaties te ondersteunen. Rollen kunnen over het algemeen worden gelaagd, zodat een systeem zowel een “webserver” als een “javaserver” kan zijn, waarbij aan de gecombineerde behoeften van beide wordt voldaan.

Deze standaarddefinities betekenen dat systemen, zodra zij zijn aangewezen als behorend tot de ene of de andere rol, zichzelf automatisch “kunnen bouwen”. Een nieuw systeem zou kunnen worden aangemaakt doordat een beheerder een systeem aanvraagt, of een capaciteitsmonitoringsysteem zou kunnen besluiten dat er aanvullende capaciteit nodig is voor een rol en automatisch nieuwe serverinstanties kunnen aanmaken zonder enige menselijke tussenkomst. Op het moment dat het systeem wordt aangevraagd, door een mens of automatisch, wordt de rol aangewezen en zal het systeem zich, door middel van het automatiseringsframework, transformeren tot een volledig geconfigureerde en up-to-date “node” (knooppunt). Geen menselijke tussenkomst van systeembeheer vereist. Het proces is snel, eenvoudig en, belangrijker nog, volledig herhaalbaar.

Het in code definiëren van systemen heeft enkele niet voor de hand liggende gevolgen. Een daarvan is dat back-ups van complete systemen niet langer nodig zijn. Waarom een back-up maken van een systeem dat u, met minimale inspanning, vrijwel onmiddellijk opnieuw kunt aanmaken? Lokale gegevens van databasesystemen zouden geback-upt moeten worden, maar alleen de databasegegevens, niet het volledige systeem. Dit kan de belasting van back-upinfrastructuren aanzienlijk verminderen en herstelprocessen sneller en betrouwbaarder maken.

De hoeveelheid documentatie die nodig is voor systemen die reeds in code zijn gedefinieerd, is zeer minimaal. In Snowflake-omgevingen moet de systeembeheerder documentatie bijhouden die specifiek is voor elke host en die documentatie handmatig onderhouden. Dit is zeer tijdrovend en foutgevoelig. Systemen die door middel van centrale code zijn gedefinieerd, hebben weinig tot geen documentatie nodig, en de documentatie kan op groepsniveau worden afgehandeld, niet op het niveau van de individuele node.

Het testen van systemen die in code zijn gedefinieerd, is eveneens eenvoudig te doen. U kunt een systeem via code aanmaken, het testen en weten dat wanneer u die definitie naar productie verplaatst, het productiesysteem herhaalbaar precies zo zal worden aangemaakt zoals het in de testomgeving werd aangemaakt. In Snowflake-omgevingen is het zeer gangbaar om testwerkwijzen te hebben die dit proberen te doen, maar dat doen via handmatige inspanningen en die vatbaar zijn voor slordigheid en niet exact herhaalbaar zijn, en zeer vaak zal de politiek voorschrijven dat het sneller is om herhaalbaarheid na te bootsen dan er daadwerkelijk naar te streven. In code gedefinieerde systemen omzeilen deze problemen, waardoor testen veel waardevoller wordt.

Afgezien van de noodzaak om een aantal nodes te definiëren die binnen elke rol moeten bestaan, kan het systeem een volledige architectuur, vanaf nul, automatisch opnieuw provisioneren. Het opnieuw opbouwen na een ramp of het opzetten van een secundaire locatie kan zeer snel en eenvoudig gedaan worden. Ook het verplaatsen tussen lokaal gehoste systemen en op afstand gehoste systemen, inclusief die van bedrijven als Amazon, Microsoft, IBM, Rackspace en anderen, is uiterst eenvoudig.

Uiteraard is er in de DevOps-wereld een grote waarde verbonden aan het gebruik van cloudarchitecturen om het meest extreme niveau van automatisering mogelijk te maken, maar het gebruik van cloudarchitecturen is niet noodzakelijk om dit soort tools te benutten. En, uiteraard, zou een in code gedefinieerde architectuur gedeeltelijk gebruikt kunnen worden, terwijl handmatig beheer eveneens geïmplementeerd zou kunnen worden voor een hybride benadering, maar dit wordt zelden aanbevolen op individuele systemen. Het is over het algemeen veel beter om twee omgevingen te hebben, een die als Snowflakes wordt beheerd en een die als DevOps wordt beheerd wanneer de twee benaderingen worden voorgeschreven. Dit vormt een veel betere hybridisatie. Ik heb dit uitstekend zien werken in een ondernemingsomgeving met meerdere tienduizenden “Snowflake”-servers, elk zeer uniek, maar met een toegewijde omgeving van tienduizenden nodes die op een DevOps-wijze werd beheerd omdat alle nodes identiek en onderling uitwisselbaar moesten zijn met gebruikmaking van een van twee mogelijke configuraties. Hybridisatie was zeer effectief.

De DevOps-benadering gaat echter eveneens gepaard met belangrijke kanttekeningen. De vaardigheden die nodig zijn om een systeem op deze wijze te beheren, zijn veel groter dan die welke nodig zijn voor traditioneel systeembeheer, aangezien, ten minste, alle traditionele systeembeheerkennis nog steeds nodig is, plus gedegen programmeerkennis, doorgaans van moderne talen als Python en Ruby, en kennis van de specifieke betrokken frameworks. Deze uitgebreide eis aan de kennisbasis betekent dat DevOps-beoefenaars niet alleen zeldzaam, maar ook duur zijn. Het betekent eveneens dat universitair onderwijs, dat al verre van toereikend is om systeembeheerders of ontwikkelaars voor te bereiden op de professionele wereld, nu nog verder verwijderd is van het voorbereiden van afgestudeerden om onder een DevOps-model te werken.

Systeembeheerders die in elk van deze twee kampen werken, hebben de neiging om alle systemen te zien als systemen die in hun eigen mal moeten passen. Nieuwe DevOps-beoefenaars geloven vaak dat Snowflake-systemen verouderd zijn en bijgewerkt moeten worden. Snowflake-beheerders (traditionele beheerders) hebben de neiging om de “infrastructure as code”-beweging te zien als dwaas, vol onnodige overhead, overdreven gecompliceerd en zeer niche.

De realiteit is dat beide benaderingen een enorme hoeveelheid waarde hebben en dat beide uiterst werkbaar zullen blijven. Beide zijn zinvol voor zeer verschillende werklasten, en grote organisaties zullen, vermoed ik, doorgaans beide in gebruik zien via een of andere vorm van hybridisatie. In de SMB-markt, waar er doorgaans slechts een handvol servers is, geen schaalvoordeel om cloudarchitecturen te rechtvaardigen en een grote ongelijkheid tussen systemen, vermoed ik dat DevOps vrijwel onbepaalde tijd buiten de norm zal blijven, aangezien de overhead en de aanvullende vaardigheden die nodig zijn om het te laten functioneren, onpraktisch of zelfs onmogelijk te verwerven zijn. Grotere organisaties moeten naar hun werklasten kijken. Veel traditionele werklasten en veel traditionele software is niet goed geschikt voor de DevOps-benadering, met name cloudautomatisering, en zal ofwel hybridisatie vereisen, ofwel een onpraktisch hoog niveau van codering per systeem, waardoor het DevOps-model onmogelijk te rechtvaardigen is. Maar werklasten die zijn gebouwd op webarchitecturen of die uiterst goed horizontaal kunnen schalen, zullen op schaal sterk profiteren van het DevOps-model. Dit zou van toepassing kunnen zijn op grote ondernemingen of op kleinere bedrijven die waarschijnlijk gehoste applicaties voor extern gebruik produceren.

Dit verschil in benadering betekent dat, in de Verenigde Staten bijvoorbeeld, het grootste deel van de VS bestaat uit bedrijven die gericht zullen blijven op het Snowflake-beheermodel, terwijl sommige oostkustbedrijven het DevOps-model effectief zouden kunnen evalueren en in die richting zouden kunnen beginnen te bewegen. Maar aan de westkust, waar modernere architecturen en een veel grotere nadruk op gehoste applicaties en applicaties voor extern gebruik de drijvende economische factoren zijn, beweegt DevOps reeds van nieuwkomer naar volwassen, gevestigde normaliteit. De DevOps- en Snowflake-benaderingen zullen waarschijnlijk op deze wijze sterk gescheiden blijven naar regio, net zoals de IT in het algemeen verschillende vaardigheden naar verschillende regio's ziet migreren. Het zou niet verbazend zijn om DevOps voet aan de grond te zien krijgen in markten als Austin, waar de traditionele IT het tamelijk slecht heeft gedaan.

Geen van beide benaderingen is beter of slechter; het zijn twee verschillende benaderingen die twee zeer verschillende manieren van het provisioneren van systemen bedienen en twee verschillende fundamentele behoeften van die systemen. Met de opkomst van cloudarchitecturen en het DevOps-model is het echter van cruciaal belang dat bestaande systeembeheerders begrijpen wat het DevOps-model betekent en wanneer het van toepassing is, zodat zij hun eigen werklasten en unieke behoeften juist kunnen evalueren. Een groot deel van de traditionele Snowflake-systeembeheerwereld zal, in de loop der tijd, migreren naar het DevOps-model. Wij zijn er nog verre van om in de branche een evenwichtstoestand te bereiken wat betreft de balans tussen deze twee modellen.

Oorspronkelijk gepubliceerd op de StorageCraft Blog.