Structured DevOps

Door: Rudie Missoorten

DevOps is hot. Uit ons klantennetwerk krijgen we al een tijd lang signalen dat men bezig is om DevOps te adopteren. Het is niet meer incidenteel maar echt een trend. DevOps heeft inmiddels voet aan de grond in de mainstream, naast bijvoorbeeld Lean en Agile. Die beide noem ik niet toevallig overigens, want met name Agile heeft de spanning tussen software ontwikkeling en software lifecycle processen opgevoerd of in ieder geval pijnlijk kenbaar gemaakt. Hoe, daarop ga ik verderop in.

En als we vragen waarom, krijgen we een scala van redenen. Allemaal valide maar de vraag rijst of DevOps wel om de goede reden wordt geadopteerd. Eigenlijk moeten we daar zeggen: In de juiste vorm en mate wordt geadopteerd. Wat we bedoelen is, dat de transitie van de traditionele Development en Operations zuilen naar DevOps een continu proces is, waar iedere organisatie voor zichzelf moet bepalen waar hun optimum vorm van DevOps nu zit. Ook DevOps heeft regels, dus dat is niet helemaal een vrije keuze maar er is binnen DevOps, als framework, zeker een bandbreedte beschikbaar om het voor de eigen organisatie op maat te maken. We noemen dat Structured DevOps, niet te verwarren met hybrid DevOps, wat geboren is uit de angst voor het verlaten van traditioneel beheer maar toch mee wil met Agile Development.

Maar eerst terug naar de aanleiding om met DevOps te beginnen. Wat zijn nu al die verschillende aanleidingen (of excuses) die we te horen krijgen? Zo ongeveer in volgorde van belang en frequentie zoals we dat hebben opgepikt. Niet uitputtend maar wel dekkend.

Snellere reactietijd

PSA, FPA, PID, (Vrijgave voor) GAT en PAT, Overdracht checklists, beheer documentatie, releasekalender en zo voort. Ben je bekend met die termen? Dan weet je ook dat dit qua resources en vooral doorlooptijd flinke porties van het budget zijn. De eisen van de tijd zijn dat veranderingen in de omgeving direct van invloed zijn op de bedrijfsresultaten. Soms opereert de business al Agile en leveren projecten in korte cycli resultaten op die direct in productie moeten. Dat betekent dat iedere verandering snel voor de eindgebruikers beschikbaar moet zijn.

Minder overhead

Zie ook het vorige punt. Lean en Six Sigma hebben ervoor gezorgd dat veel organisaties hun processen flink onder de loep hebben genomen en wat zagen ze? Dat er onder invloed van o.a. ITIL, ASL en BiSL tussen Business, Development en Operations een woud van processen is ontstaan waar naar hartelust in gesnoeid kon worden. Een feest voor Black Belts. En daarmee viel het doek ook voor de specialisten die vooral bezig waren met de processen zelf.

Continuïteit

Een dagje, ook al is het in het weekend en ook al is het gepland, de diensten off-line is niet meer acceptabel. Zeker als je je diensten als SaaS levert. Toenemende schaal en globalisatie vereist ononderbroken dienstverlening. Het antwoord: Continuous integration (CI) en delivery (CD). Voorheen waren dit al principes vanuit development maar nog niet aangesloten op operations. Die zaten nog in het ritme van releases op geschikte en geplande releasemomenten. En o ja, te wachten op documentatie, resultaten van de ketentest en vrijgave voor productie.

Klantbeleving

De gemiddelde klant heeft de aandacht spanne van een vis. Zodra elders iets nieuws wordt geboden is de overstap snel gemaakt. Zie de voorbeelden MySpace, Hyves, FromSpring, Yahoo!. Hoeven we verder niet uit te leggen. De wens om veel veranderingen in hoog tempo door te voeren vraagt een snelle reactietijd (zie eerste punt). Dit wordt nog noodzakelijker als de hoeveelheid veranderingen hand over hand toeneemt onder druk van de business die de klant optimaal wil blijven bedienen en de concurrentie voor wil blijven.

Er zijn nog veel meer aanleidingen maar deze zijn uit onze praktijk de meest gehoorde. Hoog tijd dus om ons licht er vanuit Symbiotic eens over te laten schijnen. Vanuit onze lange ervaring met Agile en Lean is het fenomeen DevOps ons zeker niet onbekend en we hebben onze portie valkuilen ook al wel gehad. En zoals het hoort, we hebben geprobeerd er zo veel mogelijk van te leren.

Voor diegenen onder ons die nog niet helemaal van de bekend zijn met de term. Wat is DevOps en waarom is het er eigenlijk? DevOps is een samentrekking uit de woorden Development en Operations., respectievelijk daar waar software, diensten of producten wordt ontworpen en gebouwd en vervolgens wordt beheerd. Eerst maar een definitie van DevOps. Er zijn er vele in omloop, van haast esoterisch tot heel instrumenteel. We gaan hier voor een hele praktische:

“DevOps is de methodiek waar beheerders en ontwikkelaars samenwerken en participeren in het gehele proces van de service of product life-cycle, van concept tot productie en onderhoud”

Als gevolg hiervan vervalt de scheiding tussen deze twee zuilen. Is er een probleem in productie, dan is dat het probleem van het hele DevOps team, niet alleen van Operations en bij bugs of nieuwe wensen vice versa.

In den beginne… DevOps is eigenlijk niks nieuws wordt wel eens beweerd. Systemen werden ooit gebouwd en onderhouden door dezelfde mensen. Hoogstens had je het onderscheid tussen de mannen van de code en de mannen van het ijzer. Vervolgens maakte toenemende schaal en complexiteit van de systemen het noodzakelijk dat de twee werelden werden gescheiden. Specialisten deden hun intrede: Coders, DBA’s, testers, infrastructuur specialisten, network engineers, etc. etc. Resultaat: Conflict! Deze twee werelden gingen ieder hun eigen weg en ontwikkelden hun eigen cultuur. Als het belang van Operations ligt bij optimale beschikbaarheid en performance, kan dat leiden tot aversie tot verandering. Het wachtwoord van de productie database werd angstvallig geheim gehouden. En de kernopdracht van Development? Juist, het introduceren van verandering!

En wat doen we als voortdurend last hebben van conflicten tussen Dev en Ops? Gaan we terug naar de kern en kijken waar het conflict is ontstaan? En proberen we de kampen te verzoenen? Nee, we reguleren het. We introduceren regels voor iedere situatie waaruit een conflict dreigt te ontstaan. Zie daar: ITIL, BiSL en ASL, de drie belangrijkste beheermodellen die inmiddels redelijk op elkaar aansluiten en de belangrijkste processen dekken tussen Business, Development en Operations. En werkte het? Ja, het werkte. Mits het goed werd doorgevoerd en niet alleen met de mond beleden werd. Nieuwe specialisten deden hun intrede: Portfolio-, Change- , Incident-, Service Level- en Problem-managers. Informatiemanagers, functioneel, technische en applicatiebeheerders en ga maar door. En werkt het overal? Nee, niet overal. Om bijvoorbeeld ITIL goed te laten werken is, naast de goede beschrijving van de processen, discipline en monitoring nodig om deze adequaat uit te voeren. We zien dat enthousiast begonnen wordt, processen worden geïmplementeerd, de organisatie wordt opgelijnd maar de discipline om vast te houden aan de processen en deze te onderhouden, d.w.z. aan te passen aan de veranderingen in de organisatie, na verloop van tijd wegebt. En waar het wel werkte, kwam een ander fenomeen voorbij: Agile. Elke drie weken releasen op z’n minst maar liever voortdurend.

Een aantal dingen kwamen samen: Het besef dat ITIL/ITSM processen vaak topzwaar zijn, het beschikbaar komen van goede provisioning en monitoring tools maar vooral, onder invloed van Agile, de roep om verregaande samenwerking tussen Dev en Ops. Eerst nog binnen zuilen. Zo ontstonden Agile Development en Agile Infrastructure. Maar al gauw smolten principes, processen en praktijk samen en ontstond DevOps.

Is daarmee definitief het antwoord gevonden? Ja, min of meer. Integrale verantwoordelijkheid voor de gehele levenscyclus van een systeem binnen één team, ondersteund door processen, tools en practices voor Continuous Testing, Integration en Delivery is natuurlijk fantastisch. Maar er is toch een aspect dat elke keer roet in het eten gooit. Dat er voor zorgt DevOps niet het verwachte resultaat brengt. En dat aspect is cultuur. Succesvol doorvoeren van DevOps kan niet zonder eerst te onderkennen dat het vooral een kwestie is van een cultuur-transitie. En een cultuur-transitie gaat gepaard met het ontmantelen van bestaande structuren die de transitie in de weg staan. De belangrijkste hierbij is het slechten van de muren tussen de afdelingen beheer en ontwikkeling. Door ze beide op te heffen bijvoorbeeld. En daar zit nu net de crux. Daar komt cultuur om de hoek. Hele functiegebouwen die in de loop van de jaren zijn opgetuigd, waar mensen comfortabel een plekje hebben gevonden en waar ieder poppetje precies binnen de kaders van de functie past breek je niet zomaar af. Waarom niet? Omdat ze juist zijn ontstaan door de divergentie van culturen zoals we hierboven hebben beschreven. Die verschillen zijn zelfs vastgelegd in beheermethodieken (ITIL, BiSl en ASL). Maar je wil toch die integrale DevOps teams. Hoe los je dat op? Hoe bereik je toch die culture-shift maar omzeil je de volledige ontmanteling van je functiegebouw? Het antwoord is Structured DevOps.

Structured DevOps functioneert op het niveau van teams, ongeacht de onderliggende structuren. Het doel is een balans te vinden tussen voldoende verschillen in cultuur, expertises en persoonlijkheidsstijlen zodat een optimaal DevOps team wordt samengesteld die volledig autonoom kan functioneren. Het is gebaseerd op een meer generiek principe over hoe je optimaal teams samenstelt. Het is gebaseerd op grafentheorie en gedragsleer (zie o.a. Tröster et al, 2014).

Hoe bepaal je de groepsgrootte? Wat voor mensen/rollen plaats je er in? Wat moeten ze kunnen? Lijken ze op elkaar of zijn ze juist heel verschillend? Hoe en hoe vaak communiceren ze met elkaar? Hoe je dit moet doen en wat de onderliggende rationale is, is onderwerp voor een andere blog van Symbiotic maar hier poneren we de volgende stelling: De noodzakelijke cultuur verandering bereik je het snelst op teamniveau. Dat doe je door je DevOps teams samen te stellen, zodanig dat er een gewogen synergie van personen en rollen wordt bereikt met voldoende ondersteuning van tools en mandaat om de volledige levenscyclus van een systeem volledig autonoom te kunnen beheren. Het ontkent de culture-shift niet maar maakt juist gebruik van de cultuurverschillen. Het is gebaseerd op het principe dat je mensen moet laten doen waar ze goed in zijn, hun traditionele rol laat houden maar altijd in de setting van een team. In deze situatie fungeren DevOps teams bij de gratie van een goed opgezet ecosysteem van ontwikkelstraten (OTAP), inclusief versioning, integration en deployment tools die continu(ous) ter beschikking staan aan de DevOps teams. Het beheer van die ontwikkelstraten kan gerust heel traditioneel verlopen met alle bendodigde traditionele resources en tools. Voorwaarde: Het gebruik, c.q. functioneel beheer van de ontwikkelstraten is in handen van ieder, volledig autonoom opererend, DevOps team. Introduceren we hiermee niet een nieuw schisma? Nee, hier komen individuen, teams, organisaties, techniek en processen samen maar blijven in hun eigen context.

Zie het als een symbiose, een ‘context for improvement’. Niet toevallig heeft Symbiotic deze zin als pay-off. Wil je daar meer over weten? Bel of mail ons dan: info@symbiotic.nl, of 06-51490241 (Rudie).