DevOps is een methodologie en framework die door gestructureerd samenwerken, van IT-ontwikkeling en operatie, meerwaarde voor de klant brengt.
De term DevOps een combinatie van twee woorden: Development en Operations. Van DevOps zijn veel verschillende beschrijvingen, waarbij de meeste varianten beschrijven dat DevOps staat voor bedrijfsinnovatie en continue verbeteren van processen. Uit alle varianten zijn drie verschillende en elkaar aanvullende beschrijvingen gekozen.
Volgens Wikipedia is DevOps een gebruik en een praktijk binnen softwareontwikkeling die tot doel heeft softwareontwikkeling (Dev) en softwareoperaties (Ops) samen te voegen.
Een andere willekeurig gekozen beschrijving werkt deze verder uit: DevOps is een reeks software ontwikkelingspraktijken die softwareontwikkeling (Dev) en IT-operaties (Ops) combineert om de levenscyclus van systeemontwikkeling te verkorten en tegelijkertijd frequent functies, fixes en updates te leveren in nauwe afstemming met bedrijfsdoelstellingen.
Zoals je hebt kunnen lezen zou de voorgaande benadering als ‘vrij technisch’ gezien kunnen worden. Begrijpelijk, want DevOps is ontstaan in de IT wereld. Voor de derde beschrijving is gekozen voor een meer agile benadering van DevOps. Dan is het verstandig om DASA te citeren:
Voor ons, is DevOps niet een ding. Het is geen product, standaard, specificatie, raamwerk of functietitel. DevOps gaat over ervaringen, ideeën en cultuur om goed presterende IT-organisaties te creëren.
Devops Agile Skill Association
Met deze drie benaderingen heb je een goede eerste indruk van wat DevOps is. In dit artikel is zal worden getracht om het uitgebreide DevOps jargon te beperken, zodat ook non IT-ers de filosofie en het framework kunnen begrijpen.
Waarom DevOPs?
In de overload aan beschikbare technische informatie is het noodzaak om de hoogste prioriteit van DevOps te kennen: sneller aan de behoefte van de klant te kunnen voldoen, met name door de doorlooptijd van veranderingen te verkorten!
De 3 hoofdredenen waarom Devops tot stand is gekomen:
- De organisatie verlangt snellere en continue levering voor de klant.
- Traditionele IT-opleveringen zijn uiterst moeizaam.
- Ogenschijnlijke tegenstrijdigheden leveren problemen op. Men doelt dan op een wens van snelle ontwikkeling versus de stabiliteit van een IT omgeving. Dev versus Ops.
Interessant is dat het probleem tussen ontwikkeling (Dev) en operatie (OPS)is beschreven als:
‘the wall of confusion’.
Een mooie bewoording van een situatie die je ook in andere omgevingen waarneemt. Wat neem je dan bijvoorbeeld waar: silo’s, verschillende gereedschappen, mindset, omgevingen, processen die niet lopen, matige feedback tot en met de ‘blame game’.
The wall of confusion resulteert in een neerwaartse spiraal. Iedereen krijgt het drukker, alles kost meer tijd, communicatie gaat trager en het werk vertraagd uiteindelijk. Dat vraagt weer om meer communicatie, coördinatie, toestemmingen. Kortom gekibbel over vrijwel alles, waarbij de oplevering steeds trager wordt.
De oplossing om de muur tussen Dev en Ops omlaag te halen is: het creëren van kleine teams die onafhankelijk hun features kunnen valideren in productie achtige omgevingen. Dan kunnen ze hun code snel, veilig en secuur in productie brengen. (bron: The DevOps Handbook, Gene Kim, Jez Humble, Patrick Debois and John Willis.)
Korte introductie DevOps
DevOps is ruim 20 jaar geleden ontstaan om websites met veel traffic overeind te houden. In 2009 vond de eerste presentatie plaats door medewerkers van Flickr. In hetzelfde jaar werd de eerste DevOps dag gehouden in België. Vervolgens werden in de opvolgende jaren frameworks en open source tools ontwikkelt. Deze ontwikkeling zet zich nog steeds voort.
DevOps heeft als primair doel snellere levering van waarde voor de klant. Dat lijkt heel eenvoudig, maar de wens om dit steeds sneller te verrichten, met de juiste kwaliteit, maakt het een complexe aangelegenheid. Want dan is opeens de gehele organisatie betrokken. Denk daarbij aan allerlei eisen zoals beveiliging, administratie, compliance etc.
Het meest herkenbare van DevOps zijn de technische voorbeelden, zoals updates, releases en het toevoegen van functies of foutherstelling (bug fixes) etc. Hoewel dit herkenbare voorbeelden zijn van wat DevOps ook is, is DevOps pas compleet als de filosofie en framework worden toegepast.
DevOps heeft als filosofie om de levenscyclus van de systeemontwikkeling te verkorten en tegelijkertijd regelmatig functies, fixes en updates te leveren volledig in lijn met de bedrijfsdoelstellingen.
Het DevOps framework bestaat uit verschillende fasen, zoals continu ontwikkelen, continu integreren, continu testen, continue implementatie en continue monitoring.
Zowel de filosofie en het framework dienen te worden toegepast om DevOps succesvol te laten zijn.
Huidige ontwikkelingen DevOps
Dat DevOps zich nog steeds ontwikkelt blijkt wel uit de vele varianten die er inmiddels zijn. Voorbeelden hiervan zijn: DevSecOps, DevOps 2.0, GitOps, NoOps en nog veel meer!
Alle varianten zijn gericht op een specifieke toepassing of toevoeging, maar altijd vanuit dezelfde filosofie: een gestructureerd samenbrengen van ontwikkeling en operatie.
De huidige ontwikkeling van DevOps richt zich met name op vergaande automatisering van het ontwikkelproces en op de uitdaging van de toenemende complexiteit. Dit laatste vult men in door zich te (willen) gedragen als een Lean Startup. Lees hiervoor het artikel: Wat is de Lean Startup Methode?
Net als andere agile methodieken is er een sterke focus op het opknippen van grote delen in kleine stukjes en het testen/meten op alle niveaus in de pijplijn en dit proces te automatiseren. Lean programming is een vertrouwd fenomeen binnen IT, maar de wijze waarop deze nu ingericht wordt is beduidend meer agile ingericht.
In DevOps 2.0 heeft men naast technische procesverbeteringen als doel gesteld om de volledige organisatie te betrekken en daarbij de communicatie tussen alle betrokkenen in software ontwikkeling te verbeteren. Het gaat hierbij dus nog steeds om Flow!
Binnen DevOps kun je tegenwoordig naast Product (stream) Teams ook Platform Teams tegenkomen. Het grote verschil tussen deze teams is dat men zich steeds meer richt op het bouwen van een feature door één team, die expert kunnen worden in het toegewezen gebied. Het andere team houdt zich meer bezig met specifieke platform kennis.
Daarmee verlaagd men de hoeveelheid informatie die men nodig heeft om een goed product af te kunnen leveren. Toch blijven de product teams end-of-end verantwoordelijk, platform teams brengen een nieuwe specifieke vaardigheid in en gaan daarna door naar waar hun specifieke vaardigheid nodig is. Men tracht met deze methode een oplossing te vinden om flow te verbeteren.
De uitdaging is cultuur!
Als je voorgaande alinea’s samenvat kun je DevOps in vijf categorieën indelen: een ontwikkelcultuur door automatisering, lean te werken en metrics en informatie te delen, waarbij specifieke DevOps-tools worden ingezet. In het Engels hanteert men hiervoor regelmatig de term CALMS (Culture, Automation, Lean, Metrics en Sharing).
Een andere manier om naar DevOps te kijken is vanuit 3 elementen: mensen, proces en technologie.
Wat je dan waarneemt is dat processen en de bijbehorende technologieën veel aandacht krijgen: ‘Want daar komen de nieuwe mogelijkheden en oplossingen vandaan’. Dat zou zo maar waar kunnen zijn, maar de grootste uitdaging voor organisaties is en blijft cultuur. Nieuwe instrumenten zijn fijn, maar als het leiderschap geen richting geeft, de gewenste agile cultuur niet tot stand komt en de resultaten uitblijven is het snel bergafwaarts, ook met DevOps.
Een mooi uitdagend voorbeeld is scaling. Ook in DevOps is scaling een veel besproken fenomeen, maar welke agile methode je ook hanteert: scaling is en blijft uitdagend. De reden hiervoor is eenvoudig, meer deelnemers staat synoniem aan meer interactie. Echter realiseert men zich veelal niet voldoende dat bij het toevoegen van slechts een paar mensen het aantal contacten exceptioneel toeneemt, lees hiertoe het artikel: Wat is Brooks law?.
Dan blijkt dat je aanvullende technische methoden dient te hanteren, want gedeelde centrale informatie is bij het ontwikkelen van software noodzakelijk. Het bekendste voorbeeld is het tegelijkertijd door meerdere mensen werken aan dezelfde software. Als je dit niet goed regelt heb je voordat je het weet meerdere softwareversies. Een garantie voor versie conflicten en bijbehorende bugs.
DevOps lost dit op door automation van het proces. Het is een noodzaak om iedereen aangesloten en ‘on track’ te houden. Zeker als men ook nog remote werkt. Momenteel is automatisering van het totale proces datgene waar DevOps zich snelst in ontwikkelt.
Uit welke componenten bestaat DevOps?
DevOps bestaat uit 4 herkenbare componenten: principes, concepten, praktijken en mensen. Laten we deze samenhang eens bekijken.
1. Principes
DevOps basisprincipes die je minimaal moet kennen: flow, feedback en continu leren i.c.m. verbeteren.
Van bovenstaande principes is het vooral handig om het begrip flow binnen DevOps te begrijpen. Flow is de snelle stroom van Dev naar Ops naar klant. Een aantal kenmerken zijn: visuele borden, WIP-limits, Slicen (opknippen in kleine stukjes), beperken van handovers, impediments aanpakken en focus op toevoegen van waarde.
Feedback en een lerende organisatie zijn bekende agile principes.
2. Concepten
Aan de principes zijn de concepten verbonden, zoals: product, waardenstroom, los verbonden architectuur en autonome teams.
Denk hierbij aan het concept van een Minimum Viable Product (MVP), maar ook aan thema’s, Epics, features en in de Sprints de User Stories. Geprioritiseerd volgens de waardestroom (value stream en value stream mapping) en passend bij MVP.
3. Praktijken
Dan krijg je de praktijken, zoals Continious Integration, Continious testen, Continious Delivery, Continious Deployment, meten en feedback. Deze worden in de volgende paragraaf beschreven. Zie voor de eerste indruk de onderstaande afbeelding.
4. Mensen
Hoewel in veel literatuur de focus ligt op de technische gereedschappen en/of praktijken, is de mens veelal de doorslaggevende factor. Zie onderstaande afbeelding.
Hiermee beschrijf je eigenlijk ook de cross functionele autonome teams, deze bestaan bijvoorbeeld uit Product Owner, Operations Engineer, Developer, QA/tester, Release Manager en InfoSec.
In dit artikel gaan we nu verder met het uitwerken van de DevOps praktijken. Vanuit een agile perspectief lijken de technische termen wellicht minder interessant, het gaat je mogelijk slechts om de filosofie van DevOps. Toch dien je deze termen wel te kennen, simpelweg om de filosofie van DevOps beter te begrijpen.
DevOps Praktijken
DevOps praktijken gaat over flexibiliteit van ontwikkeling door het automatiseren van verschillende processen, bijvoorbeeld het geautomatiseerd testen van software.
De processtroom (flow) richt zich op de aansturing van de productie waarbij ontwikkeling voortdurend in overleg is met het operationele team. Daar gebruikt men in DevOps meerdere begrippen voor: Continious Integration, Continious Delivery (CD), Continious Feedback, Continious Delivery en Continious Deployment. Deze worden nu achtereenvolgens beschreven.
1. Continious Integration (CI)
Continue Integratie of CI is een proces waarbij ontwikkelaars hun kleine aangepaste codes kunnen updaten in een centrale plaats (repository) die gedeeld wordt met het hele projectteam. Dit vindt meerdere keren per dag plaats.
Hier wordt de toegevoegde code automatisch getest en gevalideerd. Deze repository helpt om vertragingen te verminderen omdat elk teamlid op elk moment de meest up-to-date en gevalideerde versie van de code kan vinden.
De ultieme toets van het fail-fast principe.
2. Continuous Delivery (CD)
CD is de logische stap na CI. Want deze stap staat voor het automatisch bouwen, testen en verpakken van de wijzigingen in de code die bij CI hebben plaatsgevonden.
Zojuist las je het woord ‘automatisch’, jazeker dat is ook hier het sleutelwoord, net als bij CI wordt het leveringsproces grotendeels geautomatiseerd. Het doel is vanzelfsprekend snellere en betere releases.
3. Continuous Feedback
Met continuous feedback vat men het hele proces van het opsporen van fouten in het systeem samen. Hier bedoelt men ook de tools die het operationele team hanteert om (real time) het ontwikkelingsteam te informeren. Dit proces verhoogd de betrouwbaarheid van de software.
4. Continuous Deployment
Dit is de meest verwarrende beschrijving in de terminologie. Zowel vanuit een Nederlandse vertaling, alsook in het Engels. In het Nederlands betekent dit Continue Implementatie, maar dat is verwarrend omdat je dit zou kunnen afkorten naar CI. In het Engels is het ook niet echt handig geregeld, want CD staat al voor Continuous Delivery!
Het belangrijkste verschil met Continuous Delivery is dat bij Continuous Deployment een proces plaatsvindt, waarbij geen menselijke tussenkomst vereist is. Dit doen tools die, na automatisch testen, de code vrijgeven zodra het de verandering in de code detecteert.
Wat je waarneemt is dat beide begrippen door en naast elkaar gehanteerd worden. Ook zie je vaker een combinatie tot stand komen, waarbij ze beiden in dezelfde zin worden genoemd. Mede veroorzaakt door de verdere automatisering, waardoor er in meerdere stappen van het proces geen menselijke tussenkomst meer is.
Continuous Deployment versnelt de feedbackloop. Wist je overigens dat je daardoor ook geen release data meer hoeft te plannen?
Controle
Ben je met voornoemde 4 DevOps praktijken er dan? Nou eigenlijk niet, want dan komt ‘controle’ om de hoek kijken. Dit is echter niet het vijfde component, want controle is geïntegreerd in de vier praktijken. Controle staat voor verandermanagement, informatie beveiliging en taak/functie scheiding.
Bij verandermanagement kan je dan denken aan pair programming, TDD, of peer review. Voor beveiliging kan je dan denken aan het integreren van veiligheid in elke functie als dagelijkse routine, maar ook controles op de repository, in de pijplijn, in de omgeving etc.
Bij taak/functie scheiding dien je vooral te denken aan moderne vormen, want traditionele vormen remmen af. Je kunt bijvoorbeeld voor controle: inspectie, code check-ins, code review en pair programming inzetten.
DevOps Cycle
Als je bovenstaande combineert met meten en feedback, soepelere, continue communicatie, samenwerking, integratie, zichtbaarheid en transparantie. Dan heb je DevOps-cyclus!
Bovenstaande afbeelding toont de initiële softwareplanning tot de code-, build-, test- en releasefasen en tot en met de implementatie, activiteiten en continue monitoring.
Het oneindig symbool staat symbool voor continue terugkoppeling naar klanten voor verdere verbetering, ontwikkeling, testen en implementatie.
Het doel blijft natuurlijk dat oneindig vernieuwingen, wijzigingen of toevoegingen sneller en op continu basis te laten plaatsvinden.
Voor het bovenstaande geldt dat de 6 DevOps principes gehanteerd worden.
Zes DevOps principes
De Devops Agile Skill Assocation (DASA) hanteert 6 principes van DevOps. In onderstaande afbeelding zijn deze beschreven.
Van bovenstaande principes behoeft met name de zesde ‘automatiseer’ een korte aanvullende toelichting. De reden hiervoor is dat met name dit hier momenteel de grootste technologische ontwikkeling plaatsvindt.
Hoewel het wat technisch klinkt is men hier bezig met ‘cloudplatforms die op containers gebaseerd zijn’, waardoor ‘infrastuctuur als code’ gezien kan worden. Want dat geeft teams een vergaande flexibiliteit.
‘Infrastructuur als code’ kom je in veel artikelen tegen. Het is dus handig om te weten waar men mee bezig is, maar op de inhoud hiervan gaan we in dit artikel niet verder in.
Samenvatting
Zoals beloofd zou dit artikel niet al te technisch worden. Een mooie manier om DevOps als filosofie op een agile manier samen te vatten is om het acroniem CALMS te hanteren.
Cultuur: bestaande uit de huidige waarden, overtuigingen en houdingen. Die de bedrijfsomgeving rondom en ter ondersteuning van ontwikkeling, operaties en kwaliteit aanduiden.
DevOps: focus op mensen en omarm verandering en het experimenteren.
Automatisering: alles kan effectief kan worden geautomatiseerd om processen te verbeteren en fouten te verminderen.
DevOps: Continious Delivery en ‘infrastucture as code’
Lean: Dit staat synoniem voor het reduceren van verspilling. Met als doel de waarde voor de klant te maximaliseren. Voorbeelden hiervan zijn teamgrootte, vergaderfrequentie en aantal tools.
DevOps: focus op het produceren van waarde voor de eindgebruiker en hanteer kleine batch grootte.
Meten: Dit verwijst naar het meten van alles. Daarvoor dien je te zorgen voor ingebouwde mechanismen om zichtbaarheid te bieden. Dit betreft dan alle systemen en gebeurtenissen. Veelal hanteert men een dashboard.
DevOps: meet alles en toon de verbetering
Delen (sharing): goede communicatie tussen ontwikkeling en operations, voor een effectieve integratie.
DevOps: open informatie delen, samenwerken en communicatie
CALMS is bedacht door Willis en Edwards en dit is later verder beschreven door Humble, zij wilden de filosofie van DevOps beschrijven.
DevOps is dus een filosofie als een framework, de meeste aandacht gaat veelal uit naar de tools. Want door goed gereedschap kan men sneller bouwen, maar cultuur bepalend is voor het uiteindelijke succes.
In later te verschijnen artikelen zullen de diverse DevOps componenten uitgebreid worden beschreven.