DevOps. Developers and Operations. Iedereen in ons vakgebied heeft het er over. En helaas: slechts weinig organisaties doen het goed. Dat is jammer: DevOps is geen menu systeem waar je uit kunt halen wat je leuk vindt en de rest kunt negeren. Je haalt het meeste rendement uit DevOps als je alle stappen doet en gebruikt.
“Walk tall, or don’t walk at all.”
In het nummer New York City Serenade van Bruce Springsteens “The Wild, The Innocent and the E-Street Shuffle” uit 1973 zegt de hoofdpersoon op een gegeven moment: “walk tall, or don’t walk at all.” En dat is precies wat ik hier terug zie. Doe het goed, of doe het niet. Haal je niet de ellende op de hals van het omgooien van je huidige organisatie rondom je development teams als je toch de benefits er niet uit kunt halen. Waarom zou je?
Veel bedrijven kijken naar DevOps en zien eigenlijk maar een stuk: de pipeline. Developers maken iets en auto-magisch verschijnt dat in productie. We worden enthousiast gemaakt met verhalen over Amazon die meer dan 7000 deployments per dag zouden doen en denken: “Dat wil ik ook!”
Maar als je niet het hele proces mee neemt kun je net zo goed niets doen. De enige reden dat organisaties zo succesvol zijn met DevOps is omdat ze alle aspecten goed overwogen hebben en meegenomen hebben in hun planning.
Cargo Cult Syndroom
Ok. Vraagje: wie herkent dit? De organisatie roept vol trots dat we vanaf vandaag Agile werken. Want: we hebben daily stand ups!
Dat is niet agile. Dat is wat we zo mooi het Cargo Cult Syndroom noemen. Cargo Cult is al langere tijd bekend onder antropologen, de oudste beschrijving ervan stamt uit 1885. Maar het meeste bekend is wel het effect hiervan op de bevolking van kleine eilanden in Guinea na de tweede wereldoorlog. De Amerikanen, op weg naar Japan, gebruikte die eilanden als uitvalsbasis. De lokale bevolking zag deze grote, voornamelijk blanke Amerikanen als goden: ze kwamen met vliegtuigen en hadden chocola, sigaretten en andere wonderlijke dingen bij zich. Toen de Amerikanen de eilanden verlieten wilden de bewoners ze terug halen. Dus gingen ze herhalen wat ze de Amerikanen zagen doen in de hoop dat dat deze goden terug zouden lokken. Dus probeerden ze de cultuur van deze Amerikanen na te bootsen. Inclusief het nabouwen van vliegtuigen, verkeerstorens, zendapparatuur en dergelijke.
Uiteraard hadden ze geen idee waarom ze dit deden. De Amerikanen keken bijvoorbeeld door verrekijkers, maar dat werd door de plaatselijke bevolking uitgelegd als de manier waarop je hoorde rond te kijken als je de vliegtuigen naar je toe wilde lokken.
Het meest verbazende is dat deze mensen dit geloof heel lang hebben volgehouden. Decennia lang hebben de lokale mensen vliegtuigen nagebouwd, in de hoop de goden terug te lokken.
Het is makkelijk om deze mensen af te doen als onderontwikkeld. Sommige lachen er om. Maar we doen eigenlijk allemaal hetzelfde.
Een Daily Standup is een gebruik dat in het leven geroepen is met een reden. Dit doen we om een paar dingen te bereiken:
- Update van de status, zodat iedereen in het team weet waar iedereen mee bezig is
- Herkennen van problemen, zoals het te lang blijven vast zitten in een taak
- Mogelijkheid tot het bieden van hulp: door te bespreken waar er aan gewerkt wordt kunnen mensen hun expertise aanbieden indien nodig
- Versterken van het team gevoel, van samen aan een product te werken
Als je echter maar gewoon een dagelijks praatje met elkaar gaat houden, zonder het bovenstaande in het achterhoofd te houden, dan doe je aan Cargo Cult. Je doet wat je gezien hebt zonder de achterliggende boodschap te begrijpen. Het resultaat: hetzelfde als op Melanesie: niets.
Feedback
Dit plaatje kennen we allemaal wel, denk ik:
De meeste organisaties volgen dit wel aardig goed. Zeker het eerste stuk links is meestal goed geregeld. Dat is op zich niet zo vreemd: de meeste DevOps projecten worden gestart vanuit de Development kant.
De taken Plan, Create, Verify en Package zijn niets nieuws voor de meeste ontwikkelaars. Release, Configure en Monitor is iets wat Operations altijd al doet. DevOps zorgt er voor dat deze twee teams samen komen en de verantwoordelijkheid delen waardoor er, als het goed is, synergie ontstaat. Ik geef toe: dit is een enorm overgesimplificeerde weergave van een complex geheel, maar de basis klopt wel.
Maar.. En dit is de grote maar… Er loopt een pijl van Monitor naar Plan (eigenlijk is dat al Plan). En die wordt vaker wel dan niet vergeten. Er is heel vaak geen terugkoppeling van Monitor naar Plan.
Ok. Bugs worden gerapporteerd en opgelost. Maar dat is niets nieuws. Er vindt over het algemeen geen terugkoppeling plaats van de dagelijkse monitoring. Alleen als er problemen zijn, wordt er aan de bel getrokken. Met andere woorden: in plaats van een circulair proces is DevOps vaak een lineair proces. Het begint bij de plan en eindigt als het product gereleased is. Het is een project in plaats van een proces.
Het hele idee van DevOps is nu net juist de goede competenties bij elkaar te krijgen en daar van te leren. In plaats daarvan doen we hetzelfde als we altijd al deden, alleen noemen we het anders. We roepen dat we DevOps doen, we hebben gezamenlijke stand-ups en we doen niets anders dan de bewoners van Melanesie na de tweede wereldoorlog: Cargo Cult.
Feedback op alle niveaus
Wat mij dwars zit aan het plaatje hierboven, is dat het een model is van de werkelijkheid maar dat mensen denken dat het model de werkelijkheid is. Een model is heel handig als je iets wilt versimpelen en daar over wilt praten. Maar je moet nooit vergeten dat datgene wat het model voorstelt veel ingewikkelder en uitgebreider is dan het model. Het plaatje is een model van het werkelijke proces, waarbij details weggelaten zijn. Dat moet ook wel, want anders wordt het plaatje een chaos.
Iedere stap in het proces bevat feedback momenten. Een aantal kennen we wel en hebben we een naam gegeven. Plan bijvoorbeeld wordt in Scrum ondersteund door feedback vanuit de Backlog refinement en de planning sessies. Create krijgt feedback vanuit de daily standups. We hebben de sprint-review (als je Kanban doet, moet je nog steeds deze review sessie houden!), we hebben de retrospective enzovoorts. Maar hoe zit het met de feedback tussen de stappen in? Iedere stap in het proces is een moment om te leren en te verbeteren. Ik denk dat het een slecht idee is om deze stappen als discrete, op zich staande stappen te zien. Het is meer een gradient waarin de ene fase overloopt in de andere met veel momenten en mogelijkheden tot feedback. Dat laatste gebeurt helaas zelden. Het gevolg? Veel fouten worden herhaald. Veel stappen die beter gedaan worden, worden niet verbeterd omdat die feedback niet bij de juiste personen terecht komt.
Er is vaak sprake van kleine groepjes die een van de stappen neemt die in het model staan. Dat zijn eilandjes op zich. Daarna wordt het resultaat hiervan over de muur gegooid en de volgende mag het oppakken.
De lange-termijn effecten zijn nog erger: op een gegeven moment zie je vaak dat er toch weer twee kampen ontstaan: developers versus operations. En dan zijn we weer terug waar we waren. Meestal is het trouwens het management dat nog lang volhoudt dat we toch echt DevOps doen.
Weet je wat je doet en waarom
De principes van DevOps zijn niet zo ingewikkeld. Het goed en consequent uitvoeren daarvan wel. Weet wat de principes zijn, maar vooral: weet waarom die principes er zijn. Snap wat de achterliggende gedachten zijn. Snap wat de hordes zijn die we moeten overwinnen en hoe de stappen binnen DevOps deze helpen overwinnen.
Wees geen Cargo Cult aanhanger. Wees pro-actief, leer bij, snap en vooral: geef continue feedback op alles en iedereen in het proces. Leer van het proces, koppel terug en dan pas zal DevOps gaan werken.
Dennis Vroegop 