Veel bedrijven willen met DevOps practices aan de slag. Waarom? Omdat men ziet dat een aantal bedrijven daar zeer succesvol mee is en de volgende voordelen realiseert;
- Meer waarde voor de klant genereren;
- In kortere tijd releasen;
- Hogere kwaliteit;
- Sneller inspelen op veranderingen in de markt.
Deze punten dragen uiteindelijk bij aan een hogere omzet, minder kosten en/of een betere concurrentiepositie!
DevOps transitie
Om in een modus te komen waarbij het gehele bedrijf als een geoliede DevOps-machine werkt moet er vaak een hoop veranderen. Opleiding en reorganisatie van teams, verandering van mindset, procesaanpassingen, invoeren van tools etc.
Wat vaak uit het oog verloren wordt is de software waar het allemaal om draait! Die is waarschijnlijk al vele jaren in productie. In veel gevallen betreft de kern van de software een monoliet die moeilijk op een “DevOps” manier doorontwikkeld kan worden. Waarom is dat zo? Neem als voorbeeld een monolithisch product:
- DevOps teams horen volledig zelfstandig en onafhankelijk van anderen te werken aan functionaliteiten. Wanneer het echter een monoliet betreft waar meerdere teams aan werken, dan zijn er bijna altijd nauw verweven afhankelijkheden die niet los van elkaar gezien kunnen worden, waardoor men al snel elkaar nodig heeft voor bepaalde wijzigingen.
- Het aanbrengen van wijzigingen, testen, bouwen en installeren van een monoliet is vaak een complex en langdurig proces. Dit past niet binnen DevOps, waar regelmatige (kleinschalige) installaties (of incrementen van) de norm zijn.
- Een monoliet is vaak matig tot slecht testbaar via unit tests (enkele uitzonderingen daargelaten). Unit tests zijn van cruciaal belang bij korte ontwikkel- en installatiecycli om snel feedback te krijgen op de kwaliteit van de wijzigingen.
Conway’s law
Vaak wordt in deze context de wet van Conway genoemd:
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
Vertaling:
Organisaties die systemen ontwerpen … worden gedwongen om systemen te bouwen die kopieën zijn van de communicatiestructuren van deze organisaties.
Het zal dus heel lastig zijn om in DevOps teams te werken aan een monoliet. Je zult dan al snel zien dat er allerlei overleggen nodig zijn om alles af te stemmen. Verder zul je zien dat teams werk door gaan schuiven naar volgende sprints, omdat ze voor veel zaken afhankelijk zijn van andere teams die dat dan ook weer moeten inplannen in hun sprints.
Aanpak
De aanpak is vaak lastig omdat er hier sprake is van het kip-ei probleem; de architectuur van het product is afhankelijk van opzet van de teams en de opzet van de teams is afhankelijk van de architectuur van het product.
In mijn optiek is de volgende aanpak in de meeste situaties de beste: één cross-functional team opzetten dat volledig zelfstandig alle aspecten kan implementeren van een deel van het product. Dit team begint dan met het isoleren van een component van de monoliet in bijvoorbeeld één of meerdere Microservices. Het team krijgt vrijheid en ruimte om zaken als automatisch testen, automatisch deployen en automatische provisioning van de onderliggende infrastructuur zelf te regelen.
In dit team zitten idealiter de mensen die graag een voortrekkersrol vervullen. Je wil dit team graag laten slagen, want als dit team slaagt zal de rest van de organisatie automatisch gaan volgen (olievlek principe).
Hulp nodig bij de implementatie van DevOps? Aarzel niet om contact met ons op te nemen via 085 - 487 52 00 of info[a]delta-n.nl.
Meer weten over de mogelijkheden een monolitisch systeem te moderniseren? Kijk eens bij applicatie modernisering.
Fokko Veegens, DevOps Consultant
