Steeds meer organisaties stappen over naar DevOps. Uit internationaal onderzoek van ServiceNow blijkt dat meer dan 90% van de 1850 respondenten al met DevOps bezig is. In Nederland wordt DevOps inmiddels succesvol toegepast bij grote bedrijven als de Rabobank, KPN en Stater. Maar wat is DevOps precies? En hoe gaat een transformatie naar DevOps in zijn werk?
Gezamenlijk oppakken
Sinds vijf jaar werk ik voor de Rabobank, voor het programma Betalen & Sparen. Het laatste jaar hebben we de overgang gemaakt naar agile en sinds een maand of zes zijn we bezig met een overgang naar DevOps. Dit komt erop neer dat Development & Operations opgaan in hetzelfde team en alle taken gezamenlijk oppakken onder het mom van ‘You built it, you run it’.
Ik zie dit vooral als een mooie kans. De muur tussen Dev & Ops wordt afgebroken en botsende belangen veranderen in een gezamenlijk teambelang. Bijkomend voordeel is dat je als individu gemakkelijker een leidende rol kunt nemen: was je voorheen lid van een ontwikkelteam, nu kun je ook gaan uitvoeren.
Verandering vs. stabiliteit
Waar Dev voornamelijk als doel heeft om wijzigingen door te
voeren en nieuwe functionaliteiten te creëren, is het doel van
Ops juist om voor stabiliteit te zorgen met zo weinig mogelijk
verstoringen in productie.
Voeg beide teams samen en het gezamenlijke doel wordt de
eindverantwoordelijkheid voor het product en de functionaliteit.
DevOps-teams moeten in staat zijn om zelfstandig de software te
ontwerpen, bouwen, testen, deployen en beheren.
Er is geen vast scenario om DevOps te implementeren, maar er zijn wel belangrijke zaken die in ieder geval in gang moeten worden gezet:
Van Dev naar Ops
Voor een transformatie van Dev naar Ops is het volgende nodig:
- Regel de praktische zaken: geef developers de juiste autorisaties (toegang tot productie)
- Het beheerteam moet zich de beheertools eigen maken en kennis nemen van de diverse problemen die kunnen spelen in productie (en hoe hiermee wordt omgegaan).
Dit heeft de volgende voordelen:
- Door een beter begrip van wat er komt kijken bij het beheer van een omgeving, zal Dev bij nieuwe changes meer rekening houden met de impact op beheerbaarheid.
- Incidenten in productie kunnen door DevOps-teams gemakkelijker worden geanalyseerd en opgelost doordat kennis van de software vanuit diverse perspectieven samenkomt.
- Voor developers wordt inzichtelijk waarvoor zij nu eigenlijk werken, en dit is doorgaans enthousiasmerend.
- Problemen die zich op productie voordoen worden duidelijker voor developers omdat zij zelf als beheerder met deze problemen te maken krijgen.
Van Ops naar Dev
Wanneer het operationsteam deel gaat uitmaken van het developmentproces, gaan beheerders meedenken over nieuwe oplossingen en changes, kunnen ze testen uitvoeren en de kwaliteit van code bewaken nog voordat deze in productie staat.
Dit heeft de volgende voordelen:
- Omdat Ops-medewerkers vanaf het begin bij bugfixes en changes worden betrokken, kunnen zij eerder aan de bel trekken over gevolgen voor de beheerbaarheid van het systeem.
- Ops-medewerkers zullen minder het gevoel krijgen dat er iets ‘over de muur’ wordt geworpen. Ook zullen ze enthousiaster zijn over aankomende changes aangezien zij zelf betrokken zijn bij de ontwikkeling.
De invulling van deze acties is voor iedere organisatie anders. De snelheid en de manier waarop hangen af van de cultuur van de organisatie, de huidige invulling van Dev & Ops en van in hoeverre het management achter de veranderingen staat.
Een goed begin…
Wil je een gemakkelijke start maken met DevOps, dan kunnen developers en beheerders eerst in dezelfde ruimte gaan werken. Daarna kun je de diverse taken van Dev en Ops in kaart brengen en kijken welke activiteiten als eerste overgedragen kunnen worden.
Belangrijk om rekening mee te houden is dat DevOps vaak wordt geïntroduceerd terwijl er al agile wordt gewerkt. Dit betekent dat Dev vaak al ‘om’ is, terwijl Ops dit voornamelijk nog vanaf de zijlijn heeft gadegeslagen. De transitie is dan ook vaak groter voor Ops.
Wat betekent dit voor een tester?
Van huis uit is een tester gefocust op de kwaliteit van de software en hoe deze zo goed mogelijk volgens de specificaties en de wens van de klant kan worden gerealiseerd. Daarvoor heeft hij kennis van testspecificatietechnieken, testtools en weet hij hoe het proces rondom bevindingen in elkaar zit.
Natuurlijk moet een tester in een DevOps-omgeving de overige (nieuwe) teamleden begeleiden op het gebied van testen (coaching, opleiden). De tester zelf zal in een DevOps-omgeving op zijn beurt bij de technische beheertaken moeten helpen. Dit zijn bijvoorbeeld:
- het deployen van releases in test, acceptatie en productie;
- dagelijks beheer van de productieomgeving (incidentmanagement);
- performancemonitoring;
- het uitlezen van technische logging;
- begrip van databases en opvragen van data met behulp van query’s.
DevOps is voor testers dus een uitstekende kans om meer te leren over de ‘black box’ die beheer heet!
Mis je nog een waardevolle tip of heb je een andere opmerking? Laat het me weten via een reactie onder deze column!
Beste Rob, je schrijft: “In Nederland wordt DevOps inmiddels succesvol toegepast bij grote bedrijven als de Rabobank, KPN en Stater.” Is die informatie correct? Waaruit blijkt dat volgens jou?
Hoi Rob,
Volgens mij gaat een transitie naar agile, maar zeker ook naar devops ook (en misschien zelfs vooral) over cultuur, continuous improvement, information sharing, etc. Dus veel meer over mindset dan processen en samen in een kamer zitten en taken overdragen…
Ken je CALMS? Staat voor: Culture, Automation, Lean, Metrics en Sharing
Rob, Zoals Huib ook al aangaf is het vooral een kwestie van mindset en gewoon doen. Ik zit al enige tijd in een scrumteam waar developers, functioneel beheer en technisch beheer(OPS) in 1 ruimte zitten en intensief samenwerken. Ops staat echter nog op een eilandje aangezien deze nog volgens “het oude organisatiemodel” werkt (changemanagement, CAB enz enz) terwijl de rest van het team al volgens de “nieuw organisatie” werkt. Simpelweg in een ruimte zitten is niet genoeg, de hele organisatie moet meebewegen.
Dag Joris, Huib en Ronald,
Bedankt voor jullie reacties. Erg leuk om te lezen wat de verschillende ervaringen en ideeën zijn.
@Joris: vanuit de Rabobank weet ik eigen ervaring.
Voor meer informatie over DevOps bij Stater zie o.a.:
https://www.ictmagazine.nl/achter-het-nieuws/eerste-grote-devops-implementatie-business-en-it-trekken-echt-samen-op/
https://xebialabs.com/resources/case-studies/stater/
Voor meer informatie over DevOps bij KPN zie o.a.:
http://cw.com.hk/whitepaper/ca-technologies-devops-case-study-featuring-kpn-dutch-telecom-leader
https://vimeopro.com/quintgroup/devops/video/191063405
@Huib & Ronald: Ik ben het met jullie eens dat het vooral ook over de mindset gaat. Zeker het feit dat wanneer iedereen bij elkaar zit, OPS alsnog een eilandje opzich blijft herken ik wel. Uiteindelijk is het inderdaad het gewoon gaan doen en dat kan niet als de gehele organisatie niet mee beweegt. Dus als Ops nog volgens het oude organisatiemodel werkt dan gaat het niet werken.
Overigens is van deze blog nog een deel 2 welke binnenkort online zal komen en waarin ik meer inga op wat het voor de tester betekent om in een DevOps team te werken. O.a. het T-shaped werken komt daarin aan bod en de diverse vakgebieden en vaardigheden volgens DevOps. Ik ben bekend met CALMS, maar wilde juist nog niet teveel in de theorie duiken.
Hallo Rob,
Hartelijk dank voor je antwoord en voor je referenties! Ik twijfel aan de kwaliteit van de referenties waarmee je aantoont dat DevOps succesvol geïmplementeerd is bij Stater. Ik denk dat je je stelling met deze referenties niet sterker maakt. Het artikel in ICT/magazine is een verslag dat door Stater zelf geschreven is, door de twee personen belast met de implementatie ervan. Ik doe geen uitspraken over de objectiviteit van het verhaal, maar over het algemeen zijn we in dit soort situaties genoodzaakt om onszelf in ieder vragen te stellen over de objectiviteit. Ik zie die vragen niet in jouw betoog.
De resultaten die ze melden, zoals meer snelheid, besparingen en nauwere samenwerking worden niet onderbouwd met metingen die gedaan zijn op basis van vooraf opgestelde criteria. Het ontbreken van deze vooraf opgestelde criteria maakt het moeilijk om deze business case te beoordelen, af te zetten tegen andere business cases en om het succes ervan vast te stellen.
We kunnen het verhaal alleen meenemen in een betoog als we geloven dat het waar is; als we onze kritische zintuigen uitschakelen en ons geheel overgeven aan de meningen van anderen. Hetzelfde geldt voor de business case van Xebia waarin Xebia vertelt over hoe succesvol Xebia is geweest. We moeten ook in dit geval ervoor behoed zijn dat dit verhaal mogelijk gekleurd is door persoonlijke drijfveren.
Als we Stater weg laten uit jouw betoog, dan houden we twee Nederlandse bedrijven over (KPN en Rabobank) die volgens het verder niet onderzochte bewijsmateriaal succesvol DevOps zouden hebben geïmplementeerd. Volgens onderzoek van de Rabobank (https://www.rabobankcijfersentrends.nl/index.cfm?action=branche&branche=ICT-dienstverlening) houden in Nederland ongeveer 30.000 bedrijven zich bezig met software ontwikkeling. Waarvan er dus 2 succesvol DevOps hebben geïmplementeerd. Is dit in jouw ogen veel of weinig? In mijn ogen is het weinig en hebben we het over uitzonderingen. Het zou daarom bijvoorbeeld interessant kunnen zijn wat die andere 29.998 bedrijven doen waardoor zij succesvol zijn en waarom zij ervoor hebben gekozen om juist niet DevOps te implementeren. Of waarom bij die bedrijven DevOps niet heeft geleid tot een succesverhaal. Is DevOps eigenlijk wel zo goed?
Ik realiseer me dat dit soort onderzoeksvragen leidt tot een ander artikel dat waarschijnlijk veel meer tijd kost om te schrijven. Toch denk ik dat zo’n artikel zinvoller is dan het papegaaien van een aantal DevOps ‘principes’ die bij 2 bedrijven in Nederland hebben geleid tot iets wat we misschien zouden kunnen omschrijven als succes. Ik neem het je niet kwalijk dat je kiest voor het laatste (dat is wat het merendeel van de IT journalistiek doet), maar ik wil je er wel graag op wijzen dat er achter jouw verhaal een ander verhaal zit, dat mogelijk interessanter is voor ons vakgebied.
Met vriendelijke groet,
Joris