Jouw DevOps is niet mijn DevOps
De term DevOps wordt vaak gebruikt binnen de IT-wereld. We komen het tegen in functietitels, teamnamen, vacatures, tools en diverse andere contexten. Hoe langer ik organisaties begeleid in hun DevOps-reis, hoe meer verwarring de term bij mij oproept. En wat bedoelen we eigenlijk met een "DevOps-reis"?
Het valt mij op dat de term kracht begint te verliezen. De reden hiervoor is eenvoudig te begrijpen, maar lastig uit te voeren. DevOps gaat niet om techniek, het draait om cultuur en daarmee om gedragsverandering. Omdat gedragsveranderingen een van de moeilijkste aspecten van ons vak is, lijkt de term DevOps steeds meer te verbasteren.
In deze blog wil ik terugkeren naar de essentie van DevOps en enkele voorbeelden geven van situaties waarin de term verkeerd wordt gebruikt.
Wat is DevOps in de essentie?
Er is veel geschreven over DevOps, maar de kern ervan draait niet om techniek, maar om cultuur. Deze cultuur wordt uitgedrukt in 'the three ways', zoals beschreven in de boeken 'The Phoenix Project' en 'The DevOps Handbook'. Deze drie manieren zijn:
- The first way: Principes of Flow
- The second way: Principles of Feedback
- The third way: Principles of Continuous Learning
Elke way heeft een aantal onderliggende principes.
The first way: Principes of flow
Het principe van flow draait om het continu optimaliseren en verbeteren van systemen. Dit omvat het beperken van onderhanden werk (WIP limit), het opdelen van werk in kleinere, beheersbare stukken, het verminderen of elimineren van overdrachtsmomenten, en het identificeren en verwijderen van beperkingen (constraints) en verspillingen (waste). De kern van dit principe ligt in systeemdenken, waarbij het hele proces in zijn geheel wordt beschouwd. Een interessant detail is dat kwaliteit een resultaat is van het systeem. Een inspirerende lezing uit 1994 van Russ Ackhoff die gaat over system thinking en quality improvement, biedt veel inzicht in dit onderwerp.
The second way: Principles of feedback
Feedback is essentieel om snel te leren. De bekende term 'fail fast' komt voort uit de principes van deze benadering. Het wegnemen van het chronische conflict tussen Dev en Ops (of anders gezegd tussen verandering en beheer) vindt hier zijn oorsprong. Lees ook onze blog Waarom Dev en Ops silos niet werken - Delta-N.
The third way: Principles of Continuous Learning
Dagelijks leren vormt het hart van DevOps. We streven naar voortduren leren, experimenteren en verbeteren, zowel in het proces als de software die we opleveren. Daarnaast willen we onze dienstverlening minder kwetsbaar maken voor verstoringen. Er moet een cultuur zijn waarin het veilig is om fouten te maken, want dat is de snelste manier om te leren.
Bij Delta-N hanteren wij de 21 DevOps competenties die de three ways ondersteunen. Deze competenties geven invulling aan de three ways. Daarnaast volgen wij een oneliner van Donovan Brown (voormalig partner program manager bij Microsoft): “DevOps is the union of people, process and products to enable continuous delivery of value to our end users”. DevOps draait dus niet om techniek, maar om veel meer.
Nu we hebben stilgestaan bij wat DevOps is, wil ik enkele verschillende contexten bespreken waarin de term wordt gebruikt.
De DevOps engineer
De term 'DevOps engineer' kom je vaak tegen in vacatureteksten, op LinkedIn en in e-mailhandtekeningen. Vaak lijkt deze rol zich vooral te richten op het deployen van applicaties naar cloudomgevingen, container orkestratie zoals Kubernetes, of een mix hiervan. Hoewel deze vaardigheden en kennis zeer waardevol zijn, is de benaming 'DevOps engineer' vreemd. Dit komt door het volgende:
- Als eerste vult de DevOps engineer het gat dat ontstaat als een team volgens een DevOps way of working werkt. De competenties die raakvlakken hebben met Deployments, Infrastructuur en monitoring komen op het bordje te liggen en daarmee wordt een specialist geïntroduceerd in plaats van een generalist. Dat maakt het team minder T-shaped. Het botst met het ‘you build it, you run it’ principe ondanks dat de run verantwoordelijkheid wel in het team kan worden gelegd.
- Als tweede zorgt dit ervoor dat de DevOps engineer een aantal competenties invult, maar dat dit niet wilt zeggen dat het team groeit in de DevOps way of working. De DevOps engineer 'engineert' DevOps niet. Er is geen directe relatie met de 'three ways' om deze te introduceren of te verbeteren, noch komen de practices en methodes aan bod. Het bestaansrecht van de DevOps engineer is niet om het team meer DevOps te laten werken, aangezien het niet ge-engineert kan worden. De vacature 'DevOps engineer' zou niet moeten bestaan.
- Als derde kan de term impliceren dat infrastructuur als code wordt geïntroduceerd en dat dit DevOps is. Infrastructure as Code of Cloud bewegingen helpen zeker mee in het verbeteren van bepaalde competenties, maar is niet perse rand voorwaardelijk voor een DevOps way of working.
Vermijd de term DevOps engineer. Je bent engineer met een bepaald specialisme of juist een generalist.
Het DevOps team
‘Het DevOps team’ of ‘onze teams zijn DevOps’. Ik hoor het vaak. Maar wat betekend dit nu echt? Dat het team volgens DevOps werkt?
Door 'een DevOps team' te benoemen, creëer je eigenlijk opnieuw een functionele silo binnen je organisatie. Dit keer combineer je Dev en Ops, in plaats van ze te scheiden. Dit suggereert dat je nog steeds niet handelt volgens de DevOps three ways. Als het om cultuur gaat, zou iedereen betrokken moeten zijn, zowel direct als indirect, bij het leveren van waarde aan de eindgebruiker. Dit geldt bijvoorbeeld ook voor HR-medewerkers.
De term is dus misleidend. Het suggereert dat alleen Dev en Ops samenwerken, terwijl het om de hele organisatie gaat die de three ways omarmt en zichzelf continu verbetert. Het DevOps team bestaat eigenlijk niet. Benoem teams rondom de waarde die ze leveren. De term DevOps schiet hier tekort.
DevSecOps
We hebben eerder besproken dat de term DevOps een functionele silo kan creëren binnen een organisatie. Security moet volledig onderdeel zijn van de DevOps way of working. De term DevSecOps suggereert echter dat security binnen DevOps niet belangrijk is, maar binnen DevSecOps wel.
Vermijd de term DevSecOps. Binnen de DevOps-cultuur zijn we end-to-end verantwoordelijk voor het leveren van waarde aan de eindgebruiker, en daarbij hoort security volledig bij DevOps.
Azure DevOps
Microsoft staat erom bekend producten vaak van naam te veranderen, wat vanuit marketingperspectief slim kan zijn. Azure DevOps, een product van Microsoft, heette vroeger Team Foundation Service, Visual Studio Team Services (VSTS), en Visual Studio Online.
De naam Azure DevOps zorgt voor veel verwarring binnen organisaties. Bijvoorbeeld: 'Dat moet je even vastleggen in Azure DevOps' of 'Dat moeten we doorspelen naar het DevOps team'. Dit kan ertoe leiden dat het beheerteam van Azure DevOps een incident ontvangt dat eigenlijk naar een ontwikkelteam moet. Bovendien, als een organisatie geen gebruik maakt van Azure, dan heet Azure DevOps ineens Azure. De verwarring wordt compleet als je uitlegt dat Azure en Azure DevOps twee verschillende dingen zijn, maar dat Azure Pipelines weer een onderdeel is van Azure DevOps. Hoewel Azure DevOps een uitstekend product is, blijft de naam verwarrend.
GitLab, Kubernetes, Docker, Python en Yaml
Het is een misverstand dat DevOps gecentraliseerd is rondom tools. Tools ondersteunen het doel, en het doel is om onze eindgebruiker continu te voorzien van waarde in de vorm van IT-oplossingen op een veilige manier. Je kunt zoveel tools inzetten als je wilt, maar dat maakt je niet per definitie meer DevOps. Sterker nog, het kan het geheel vaak complexer maken.
Onlangs heb ik een team ondersteund dat volledig bezig was met microservices op een Kubernetes-platform, maar een gitflow-branchingstrategie had die niet compatibel is met DevOps/Continuous Devivery. Een van de knelpunten was hoe het team hun codebeheer had ingericht.
DevOps is achterhaald, lang leve GitOps
GitOps is een term die de laatste jaren steeds populairder is geworden. Volgens RedHat gebruikt GitOps een git-repository als de enige bron van waarheid om infrastructuur te leveren. Dit gebeurt met tools zoals ArgoCD en Flux, die op basis van een wijziging in de code (in git) de nieuwe infrastructuur of applicatie in gebruik nemen. RedHat stelt dat GitOps voortbouwt op DevOps.
Persoonlijk heb ik moeite met de term GitOps. Ten eerste benoemen we een toolnaam (git) in een methodologie of way of working. Daarnaast suggereert dit dat er binnen DevOps geen ruimte is voor infrastructuur as code. Niets is minder waar. Volgens de DORA capabilities behoort een Flexibile infrastructuur tot DevOps en de manier om dit te bereiken is via infrastructuur als code.
Een nieuwe term zoals GitOps introduceren is verwarrend. Desondanks zijn tools zoals ArgoCD en Flux geweldig. Ze benaderen het deployen (of eigenlijk live zetten) van infrastructuur en applicaties simpelweg anders dan pipelines.
Mijn tips
Zoals ik in de inleiding vertelde vind ik DevOps een verwarrende term geworden. Daarom mijn tips:
- Gebruik termen zoals de 'DevOps engineer' en 'DevOps team' niet meer;
- Bedenk altijd dat DevOps vooral gaat om cultuur en niet alleen om techniek;
- Lees het boek ‘The Phoenix project’. Het is een roman die de ‘three ways’ uitlegt aan de hand van een mooi lopend verhaal rondom het bedrijf Parts Unlimited;
- Als je iemand DevOps hoort zeggen of als je het zelf benoemd, houd dan altijd the three ways in je achterhoofd. Persoonlijk probeer ik minder over DevOps te praten in het dagelijkse leven en meer te praten over flow/system thinking, fast feedback en leren/experimenteren.
De term is verwarrend. Het suggereert dat alleen Dev en Ops samenkomen in een functionele silo. Zelf praat ik liever over de term Continuous Delivery, omdat dit gaat over het continue leveren van waarde aan de eindgebruiker. Deze term geeft niet aan welke disciplines/functionele silo's erbij betrokken zijn.
Ben je benieuwd wat er goed gaat en wat er beter kan in jouw software ontwikkelproces? Lees meer over onze Online DevOps meeting en krijg inzicht in waar jouw software ontwikkelteam(s) kunnen verbeteren.
Joost Voskuil, DevOps Consultant
