Om te begrijpen waar DevOps vandaan komt, gaan we terug in de tijd. Sam Rosbergen (DevOps Cultural Change Consultant bij Brunel) vertelt wat het inhoudt, welk groot voordeel het biedt voor organisaties en hun IT, en waar we met z’n allen voor moeten waken.
Sneller en beter
Groeide je op na de jaren tachtig, dan had je waarschijnlijk al vrij snel een pc, mobiele telefoon en internet in de buurt. Je raakte eraan gewend dat je steeds makkelijker informatie kon verkrijgen en sneller kon communiceren. Ook de oudere generaties gingen daarin mee. Daarmee veranderden de verwachtingen die we hebben als consumenten. Bedrijven moeten steeds sneller en beter hun producten en diensten leveren. Werkwijzes die dat mogelijk maken, zijn bijvoorbeeld Lean, Agile en sinds een paar jaar ook DevOps.
Bedrijven moeten steeds sneller leveren. Dat kan dankzij werkwijzes als DevOps.
Twee soorten werk in IT
Waar komt DevOps vandaan? Even terug in de tijd: in de jaren tachtig ontwikkelde de IT zich snel. Het werd belangrijk om te werken met standaarden. Werk moest voorspelbaar en makkelijk te herhalen zijn, en daarom beschreven worden in processen. Aan het eind van de jaren 80 ontstond daarom ITIL, een methodiek die beheerstandaarden bood. Rond dezelfde tijd gebeurde hetzelfde op het gebied van projectmanagement in de vorm van PROMPT II. In 1996 is daar Prince2 uit ontstaan. In grote lijnen zag je in IT al snel twee soorten werk: projectmanagement en beheer.
Een stroperig geheel
In traditionele IT-omgevingen werden projecten op de lange termijn gepland. Zo kon het bestuur langetermijnbeslissingen maken op het gebied van innovatie, investeringen en productverbetering. Er werden processen ingericht om zowel projecten als beheer soepel te laten verlopen. Maar vaak werd ITIL verkeerd geïmplementeerd en werd er werk uitbesteed aan derde partijen. Daar kwamen ingewikkelde contracten bij kijken, veel administratieve verplichtingen, en vaak ook gelimiteerde en verspreide rechten voor de toegang tot systemen. Dat gaf een complex geheel. Je kunt je voorstellen dat dit de levering van producten en diensten vertraagde. Ook zat het innovatie in de weg en was het slecht voor het vertrouwen tussen verschillende IT-partijen.
Nieuwe methodes om het tempo te verhogen
Om sneller en efficiënter producten te leveren, en ook de kwaliteit ervan te verhogen, ontstond Lean. Het doel: met minimale inspanning maximale toegevoegde waarde bieden voor de klant. Daarnaast kwam Agile op, als tegenbeweging tegen langetermijn-projectmanagement. Het hoofddoel van Agile is snel aanpassingen maken om sneller te leveren.
Zo helpen Lean en Agile organisaties efficiënter te werken én continu te verbeteren. Maar pas je deze projectmethodieken toe op IT, dan ontbreekt nog het beheergedeelte. Een deel van de organisatie is er dan op gericht om te veranderen en een ander deel juist om zo stabiel mogelijk te blijven.
De komst van DevOps
Steeds meer partijen kregen door dat die tegenstelling niet efficiënt werkt – en snelle verandering en levering tegenhoudt. Op basis van al die ervaringen is DevOps ontstaan. Daarin werken ontwikkelaars (DEVelopers) en beheerders (OPerationS) samen:
- Met alle kennis en verantwoordelijkheden bij elkaar voer je sneller wijzigingen door.
- Toegang tot verschillende omgevingen is niet meer gelimiteerd tot bepaalde personen of partijen.
- Het team is zelf verantwoordelijk voor de levering van een dienst of product.
Deze zelfsturende teams worden geholpen door recente technologische ontwikkelingen om sneller te leveren. Denk aan de cloud, microservices, en CI/CD tooling (Continuous Integration/Continuous Development).
Waar we voor moeten waken
Toch zal DevOps niet voor alle partijen de beste oplossing zijn. Voor partijen die nog veel met mainframe-systemen werken, is sneller veranderen hoogstwaarschijnlijk geen optie. Ook zullen organisaties die veel te maken hebben met wet- en regelgeving niet altijd (volledig) DevOps kunnen werken. Laten we er met z’n allen voor waken dat we nu ook niet doorslaan in het DevOps- en Agile-denken en dit pragmatisch en bedrijfsspecifiek in gaan richten.
Laten we niet doorslaan in het DevOps-denken: laten we het pragmatisch aanpakken.
Dit is deel 1 van een drieluik. In het volgende deel gaat Sam in op uitdagingen die organisaties tegenkomen als ze beginnen met DevOps. Hoe ga je daarmee om? Hou ons blog in de gaten.