Steeds meer organisaties kiezen voor een devops way of working. Ze brengen softwaredevelopment, testen en operatie onder in één team, zodat engineers bij het ontwikkelen van software al meer nadenken over de kwaliteit en het beheer van die code op de lange termijn. Verantwoordelijkheden liggen laag in de organisatie, in de devops-teams. Die krijgen het mandaat om zelf te bepalen hoe ze doelen bereiken en om hun werk van A tot Z te organiseren.
Deze gedachte is heel mooi en inspirerend voor de medewerkers in de teams, maar er schuilt ook een gevaar in. Want voor je het weet krijg je een wildgroei aan werkmethodes, technieken, tools en programmeertalen. Op korte termijn merk je daar weinig van. Ja, enthousiasme bij de teams die met de tools van hun eigen voorkeur mogen werken. Op langere termijn snijd je jezelf echter in de vingers. Want hoe zorg je ervoor dat er in de organisatie voldoende mensen zijn die kennis hebben van die veelheid aan gebruikte tools? Hoe borg je dat software-engineers elkaars werk kunnen overnemen of kunnen switchen van team? Voor je het weet, ontstaat er chaos en is iedereen het overzicht kwijt.
Hergebruik microservices
Bovendien wordt hergebruik van ontwikkelde microservices een stuk lastiger als die onderdelen niet allemaal volgens dezelfde spelregels zijn ontwikkeld. Want als ieder team anders omgaat met containers, pipelines, security et cetera, dan kun je er niet van op aan dat een microservice alles bevat wat het in een bepaalde omgeving nodig heeft. En dat terwijl eenvoudige herbruikbaarheid van componenten juist een belangrijk voordeel is van het werken met containers.
Je ontkomt daarom niet aan afspraken. Op welke platformen gaan we ontwikkelen? Hoe gaan we met containers om? Welke werkprocessen spreken we af voor de pipelines? Welke tools gebruiken we daarbij (en welke dus niet)? Hoe gaan we om met security? Op welke manier testen we nieuwe code? Hoe regelen we monitoring in? Deze hele set aan afspraken noemen we ook wel ‘cloud operations’ (cloudops). Je stelt hiermee je teams in staat om op een uniforme manier te werken. Daardoor houd je controle op de kwaliteit, zorg je ervoor dat medewerkers in devops-teams elkaars werk makkelijk kunnen overnemen en vergroot je de mogelijkheid tot hergebruik van componenten.
In mijn ogen is cloudops een randvoorwaarde voor devops. Je kunt verantwoordelijkheden alleen laag in de organisatie beleggen als je de teams ook in staat stelt hun werk op een goede manier te doen. Daar horen nu eenmaal kaders en richtlijnen bij.
Continu proces
Gelukkig bieden de bekende cloudplatformen, zoals Azure en AWS, frameworks die je kunt gebruiken bij het inrichten van de governance. Maar zo’n framework is uiteraard niet meer dan een handvat. Uiteindelijk gaat het erom dat je de gesprekken met je teams voert over hoe zij vinden dat de kaders en richtlijnen eruit horen te zien. Het idee dat je daar vandaag bij hebt, kan morgen weer anders zijn. Want niet alleen tools en technieken veranderen, maar ook je organisatie verandert. De governance op je werkprocessen moet mee veranderen. Het inrichten van cloudops is dus geen eenmalige exercitie, maar een doorlopend proces waarbij je leert, bijstuurt, verbetert en innoveert.
Ik zie helaas vaak dat bij de haast om devops te introduceren, organisaties te makkelijk denken: de governance richten we later wel in, laten we eerst maar ervaring opdoen. Een logische gedachte die past bij een agile werkwijze. Maar ook een gedachte waarbij je later veel herstelwerk moet doen. Lastig herstelwerk, want teams tools afpakken waarmee ze graag werken omdat ze niet bij de door jouw gedefinieerde set behoren, is een stuk lastiger dan samen met de teams beslissen welke tools en technieken ze gaan inzetten. Kortom, wil jij een devops way of working introduceren, denk dan vooraf na over je cloudops. Daarmee bespaar je jezelf later een hoop gedoe (en schaduw-it!).
