DevOps
De basis
Letterlijk gesproken is DevOps een samenvoeging van ontwikkeling en operatie. Maar om te begrijpen wat het echt is, is enige achtergrondinformatie over de oorsprong ervan nodig. Het werd in het leven geroepen door Patrick Debois en Andrew Clay Shafer, die agile infrastructuur bespraken op de Agile 2008 conferentie. Een jaar later, tijdens de eerste DevOps Days in Gent, kwam het pas echt op gang. Sindsdien zijn er tientallen DevOps Days georganiseerd door een snel groeiende, hands-on gemeenschap van IT-professionals uit zowel ontwikkeling als operatie. Het
heeft geleid tot een wereldwijde, bottom-up beweging om een snelle en veerkrachtige levering van IT-services mogelijk te maken. Samen met deze relevante beweging komt automatisch het onvermijdelijke verlangen om DevOps te definiëren en te definiëren. Dit leidt tot semantische, zelfs religieuze discussies, die
in feite niet bijdragen aan het doel (wendbaarheid, samenwerking en empathie in de hele IT-waardeketen). Dus, zonder te proberen het af te bakenen, DevOps richt zich op een organisatorische mindset voor het continu verbeteren van de waarde van de digitale waardeketen door cross-functionele samenwerking mogelijk te maken op proces-, technologie- en gedragsniveau.
Samenvatting
Organisaties over de hele wereld hebben Lean en Agile werkwijzen geadopteerd om met de huidige disruptieve markten om te gaan.
Lean Startup-principes worden toegepast door grote multinationals en Agile-methodologieën zijn de IT-afdeling ontgroeid, richting primaire processen in advocatenkantoren, scholen en bouwbureaus. Dit zegt echter niet
dat deze organisaties nieuwe of aangepaste software ook daadwerkelijk met de vereiste snelheid en frequentie in productie brengen. Voornamelijk tijdens deze laatste stap (vaak aangeduid als “the last mile”) hapert de oplevering. De hoofdoorzaak? De organisatie heeft te veel silo’s, die niet (genoeg) met elkaar verbonden zijn.
Het probleem
Wie heeft ze niet gezien: IT-afdelingen waar ontwerpers, ontwikkelaars, testers, support en operations in splendid isolation van elkaar leven, met een minimale mate van samenwerking. De ontwerpers koesteren hun eigen requirements en methodologieën, de ontwikkelaars werken aan hun code (eventueel in Scrum-teams), waarna de resultaten door de testfabriek worden gehaald om aan het eind over de operations-muur te worden gegooid. Producten, zoals ze door de ontwikkelteams worden opgeleverd (Scrum heeft ze “potentially shippable products” of PSP genoemd), stapelen zich op voor de deur van operations. Trouwens, het consequent gebruiken van de PSP-term in Scrum-implementaties wereldwijd, heeft sterk bijgedragen aan de divergentie van verantwoordelijkheid in de organisatie.
aan de divergentie van verantwoordelijkheid in de waardeketen. Immers, vanuit het oogpunt van de (Scrum) ontwikkelaar was hun werk “klaar” zodra het potentieel verschepbaar was, dus op een pallet, wachtend om verscheept te worden. Op dat moment levert het nog helemaal geen waarde op! Maar de ontwikkelaar beschouwde het als gedaan, omdat zijn werk gedaan was. Geen enkele relatie met waarde.
En wanneer deze product incrementen uiteindelijk worden geïmplementeerd in een grote release, duurt het onaanvaardbaar lang voordat fouten kunnen worden gerelateerd aan hun bron. Integratieproblemen komen pas aan de oppervlakte als de tester de acceptatietests uitvoert. En hoe zit het met de klanttevredenheid, als gebruikers voortdurend worden geconfronteerd met vertragingen en onbeschikbaarheden? Kortom, DevOps voorziet in de behoefte aan een hogere gebruikerstevredenheid, een dynamische balans tussen
waarde en risico’s, een kortere time-to-market en meer efficiëntie in de end-to-end keten door cross-functionele samenwerking.
De drie manieren
Zoals prachtig geïllustreerd in de DevOps-bijbel “The Phoenix Project”, is de waarde die IT kan leveren aan een organisatie volledig afhankelijk van haar vermogen om de organisatie te laten samenwerken als
als geheel. Hoewel de naam suggereert dat alleen Development (Dev) en Operations (Ops) nauwer gaan samenwerken, is de essentie veel breder dan alleen dat. Het samenbrengen van Dev en Ops wordt “DevOps Lite” genoemd (naar Patrick Debois), terwijl echte DevOps ook de integratie inhoudt van cruciale rollen zoals de business, testing/QA en security. Dit holistische denken is het eerste principe (The First Way) van DevOps.
Daarnaast wordt het als fundamenteel voor DevOps beschouwd om (meestal Agile) ontwikkelteams niet alleen “potentieel verzendbare producten” te laten opleveren, maar ook om de beoogde implementatieomgevingen beschikbaar te hebben (provisioning). Het is duidelijk dat DevOps hier een stap verder gaat met Agile-implementaties, waardoor de IT-organisatie meer waardevolle feedback krijgt (The Second Way) over de kwaliteit van de opgeleverde producten. Zeker automatisering speelt hier een essentiële rol. Zonder een hoge mate van automatisering is het vrijwel onmogelijk om omgevingen snel en gestandaardiseerd te provisionen en te synchroniseren (DTAP).
Waarschijnlijk de meest fundamentele verschuiving die deel uitmaakt van de DevOps manier van werken, is de manier waarop fouten en risico’s worden aangepakt. Traditionele organisaties hebben de neiging om een culturele erfenis te hebben waar fouten worden bestraft en dus in de doofpot gestopt. DevOps-organisaties gaan ervan uit dat fouten en experimenten uitstekend zijn, omdat ze de veerkracht van de organisatie vergroten (The Third Way).
Het vergroot het vermogen van de organisatie om te leren, waardoor dit soort organisaties evolueren naar een staat van “antifragiliteit” (Nicholas Taleb). Ze staan bekend om hun vermogen om verstoringen te absorberen, er zelfs uit te groeien, en zich voortdurend aan te passen aan veranderende omstandigheden.
Relaties
Het revolutionaire aspect van DevOps gaat niet over de individuele componenten die het aanraakt. Het is de contextuele combinatie en toepassing van deze raamwerken, methoden en bewegingen. De volgende essentiële relaties worden geïdentificeerd in relatie tot DevOps:
Agile: Veel van de principes die worden toegepast in organisaties die DevOps hebben geadopteerd, komen overeen met de Agile principes. Denk aan korte feedbackloops, het minimaliseren van de grootte van eenheden en een snelle stroom van gepland werk.
Lean: De Lean manier van denken is niet alleen van toepassing op de fabrieksvloer. Lean elementen zoals Voice of the Customer, Flow, Pull en Kaizen worden steeds meer gebruikt in IT-organisaties. Afval wordt verminderd en fouten worden bij de bron opgespoord en opgelost (“no defects downstream”).
Theorie van Beperkingen: Deze methodologie, verwant aan Lean, wordt gekenmerkt door het elimineren van knelpunten. Door consequent te zoeken naar essentiële beperkingen in de product- en
product- en servicestromen van uw organisatie, kunnen deze beperkingen (of knelpunten) adequaat worden weggenomen.
ITIL: Zonder twijfel speelt ITIL ook een belangrijke rol in DevOps-organisaties. Als het goed wordt toegepast, zorgt de introductie van Agile en Lean principes en instrumenten in de hele IT-leveringsketen (dus inclusief operations en support) voor snellere en flexibelere servicemanagementprocessen. Neem Configuration Management, dat in DevOps cruciaal is voor het delen van informatie tussen verschillende rollen en domeinen.
Cloud: Veel organisaties zijn begonnen met hun transformatie naar de cloud, gedeeltelijk of volledig. Cloudtechnologie maakt snelle provisioning, aanpassing (omhoog/omlaag schalen) en
synchronisatie van (DTAP) omgevingen en in het automatiseren van verschillende build-, integratie-, test- of implementatietaken.
Thema’s
Typische patronen die we tegenkomen in DevOps-omgevingen zijn:
– Continuous Delivery
Delivery pipelines worden geautomatiseerd, wat resulteert in praktijken zoals continuous integration, continuous deployment, geautomatiseerd testen.
– Alles gedefinieerd door software
Servers en zelfs hele netwerken zijn tegenwoordig softwaregedefinieerd. Fysieke, on-premise hardware wordt vervangen door virtuele machines en containers.
– Behendige architectuur
Enorme monolythische applicaties worden vervangen door microservices, waardoor snelle feedback, weinig regressietests en maximaal gebruik van marktstandaardisatie mogelijk worden.
– Dienstenstroom
Door Lean-processen te gebruiken, daagt een waardegedreven aanpak de end-to-end prestaties van de waardestroom uit, waarbij de batchgrootte en wachtrijen voortdurend worden geoptimaliseerd.
– Functionele versus niet-functionele eisen
Een goede balans tussen functioneel en niet-functioneel systeemgedrag vereist professioneel producteigenaarschap, maar ook ingebouwde kwaliteit, beveiliging en monitoring.
– Lerende cultuur
Falen wordt gezien als waardevolle leerpunten in plaats van kansen voor straf, wat resulteert in schuldloze postmortems en beloningen voor positief experimenteel gedrag.
Doelgroep
DevOps als thema is relevant voor iedereen die betrokken is bij de digitale waardeketen. Of je nu bij HR werkt, hypotheken verkoopt, software ontwikkelt, testscripts schrijft of infrastructuur in de cloud beheert.