Een ‘hype’ is het allang niet meer: DevOps is niet meer weg te denken in de wereld van Softwareontwikkeling. Maar wat is DevOps eigenlijk? En nog belangrijker, hoe kan een succesvolle implementatie van DevOps leiden tot snellere ontwikkeling, minder fouten en het allerbelangrijkste: blije en gemotiveerde medewerkers.

Door Marc Valk

‘Here comes devops”

Wat direct opvalt als je spreekt over DevOps is natuurlijk de samenvoeging van de termen ‘Dev’, van Development en ‘Ops’, van Operations. Als we Wikipedia[i] zich ermee laten bemoeien, dan leer je:

DevOps, een samentrekking van “development” en “operations”, is een praktijk binnen softwareontwikkeling die tot doel heeft softwareontwikkeling (Dev) en softwareoperaties (Ops) samen te brengen. Het hoofdkenmerk van de DevOps-functionaliteit is het benadrukken van automatisering en monitoring in alle onderdelen bij het bouwen van software. Van integratie tot testen, release tot deployment en infrastructuurmanagement. DevOps probeert te komen tot kortere ontwikkelcycli, een verhoogde frequentie van oplevering en een meer betrouwbare oplevering. Allemaal in nauwe overeenstemming met de businessdoelstellingen.

Om nu deze term goed in beeld te krijgen, gaan we allereerst eens terug naar hoe het er vroeger in het ‘pre-DevOps era’ eraan toe ging.

Pre-DevOps: Toen we Software nog over de schutting gooiden

Wanneer een bedrijf software creëerde, had men een team van ontwikkelaars. De zogenoemde Dev’s. En een team van beheerders, de Ops’s. Het Dev-team schreef de code van het softwareproduct en als men daarmee klaar was, werd het als het ware over de schutting gegooid naar de Ops-afdeling. De Ops-afdeling op haar beurt, had als taak om uit te vinden hoe deze software geïnstalleerd en geconfigureerd moest worden op de hardware die zij daarvoor beschikbaar hadden.

Met niet al te ingewikkelde software is deze vorm nog enigszins hanteerbaar. Maar het werd al snel zeer complex wanneer de software grotere vormen aannam. Bijvoorbeeld bij meer gebruik. Omdat de software die gebruikt werd in productie stond, was een nieuwe release altijd een spannend moment. Het groeiende gebruik eiste meer hardware en meer betrokken personen. Wat op haar beurt weer zorgde voor “configuration drifts”, verschillen in de configuratie per server, ontstonden. Samen met het handmatige proces van installeren en configureren, van niet alleen de eigen software maar ook de afhankelijkheden van andere software, zorgde ervoor dat er diverse bugs en handmatig gemaakte fouten ontstonden.

De Developer gaf aan “It works on my machine” en operations werd daardoor alleen nog maar extra voorzichtig met een Deployment. En probeerde dit vaak alleen nog maar uit te stellen en minder toe te passen. Het neveneffect van deze uitstel kwam weer bij de Developer terecht, die de software met meer functionaliteit opleverde. Daardoor werd het nog moeilijker om de software met elkaar te mergen, zonder dat er conflicten ontstonden. “It works on my machine” werd daardoor letterlijk steeds minder geroepen.

Here comes DevOps

Er moest dus iets gebeuren om Dev en Ops beter met elkaar samen te laten werken en de verantwoordelijkheid van de software te delen. DevOps is de methodiek die ervoor zorgt dat Dev en Ops meer met elkaar gaan samenwerken met als uiteindelijke doel om software efficiënter én stabieler op te leveren.

LAN (CONTINUOUS): Organiseren en plannen van het project, bijvoorbeeld via de agile methode [ii]. Het project dus zó plannen dat kleine iteraties van software elkaar opvolgen.

CODE: Het schrijven van “de code”. Tegenwoordig, met name in het “Cloud First / Only -tijdperk”, wordt hiermee niet alleen de applicatiecode bedoeld, maar ook de door Ops gemaakte code in de vorm van infrastructure as code.

BUILD: Het bouwen van de gemaakte code. In deze stap kunnen er diverse tools gebruikt worden om de code te controleren op kwaliteit en veiligheid. Een voorbeeld daarvan is SonarQube.

TEST: Geautomatiseerd testen zorgt er o.a. voor dat de ontwikkelde nieuwe functionaliteit werkt (het functioneel testen) en dat er geen “oude” functionaliteit omvalt (regressietesten).

Het bovenstaande wordt dan “continuous integration”. Het integreren van de code in een gezamenlijke repository, het liefst meerdere keren per dag, zorgt voor een automatisch build. Dan kan je vanuit daar zoveel mogelijk geautomatiseerd testen.

RELEASE: De code die door de testfase is gekomen, wordt samengesteld in een release. Ready for Deployment, noemen we dat.

DEPLOY: Operations zorgt ervoor dat de nieuwe software wordt ingezet. Dit gebeurt zoveel mogelijk geautomatiseerd, zodat ook Continuous Deployment mogelijk gemaakt wordt.

OPERATE: Ops zorgt ook voor een schaalbare infrastructuur en legt deze infrastructuur zo veel mogelijk vast; Infrastructure as Code. Het product kan niet te lijden hebben (downtime) omdat er een Deployment plaatsvindt. Of een update/patching van het onderliggende systeem, binnen software en hardware.

MONITOR: Het monitoren van de omgeving en de werking software. Het monitoren gebeurt op basis van diverse metrics, zoals Performance (end-user), SLA-afspraken en Resources. Dit is een belangrijke stap in het gehele proces. Het zorgt ervoor dat incidenten eerder gevonden worden en deze kunnen dan weer dienen als input voor de PLAN fase. Maar ook dat men proactief inzicht krijgt in de werking van de applicatie.

Me, Myself and DevOps

Hoe implementeer ik DevOps?

In elk geval niet door een DevOps-Engineer aan te nemen en te wachten tot het geregeld is. DevOps is bovenal geen functie of een rol maar bovenal een compleet nieuwe cultuur en mindset. Het toekennen van een DevOps-role aan iemand is gelijk aan het aanwijzen van een SCRUM-master binnen je organisatie en daarmee denken dat je “agile” bent.

Het doel moet ook niet zijn om deze DevOps-methodiek te implementeren door de diverse tools te gaan gebruiken. Het allerbelangrijkste is dat het TEAM de juiste mindset heeft. Het Dev-team en het Ops-team moeten leren samenwerken en beide dezelfde verantwoording voelen voor het product wat zij opleveren. You build it, you run it!

Of het daarvoor nu één team per product is of bijvoorbeeld één team per functionaliteit, en daarmee dus meerdere teams per product, is per product/organisatie verschillend. Hierin is er ook de zogenoemde “no right way”. Er staat nergens hoe het exact moet, maar je weet wel hoe het niét moet; de “wrong way”. Voorkomen moet worden dat er opnieuw silo’s gecreëerd worden van diverse expertises. Dev in één hoek en Ops in de andere. Samenwerking tussen Dev en Ops is essentieel. DevOps integreert daarbij in mensen, processen en gebruikte tools. Men moet als organisatie dus voorbereid zijn op een verandering in de bedrijfscultuur. Een verandering die dus niet alleen top-down in een organisatie ingevoerd moet worden, maar ook bottom-up gedragen wordt. Als hier één van de twee ontbreekt, is de transitie naar de DevOps-cultuur in gevaar.

Eerder werd al de Agile Development methode genoemd. Dit kan een goede aanvulling zijn op DevOps, ongeacht onderlinge verschillen. Beiden streven ernaar om zo effectief en betrouwbaar mogelijk features (of waarden) op te leveren door middel van o.a. samenwerking, goede communicatie en zelf-organiserende teams. Agile legt hierin zijn focus op feedback loops met mogelijke constante veranderingen en korte en snelle iteratie. Waar DevOps het communicatiegat tussen Dev en Ops aanpakt, pakt Agile het communicatiegat tussen klant en ontwikkelaar aan.

Automatisering is een belangrijk onderdeel binnen DevOps. Automatisering van niet alleen de implementatie, maar ook het testen of het monitoren (en het daarmee reageren op alerts). Dit zorgt er voor dat het team vertrouwen krijgt in het opleveren van het product en daarmee dus ook een snellere Releasecycle kan creëren. Het team zal daarmee in een staat kunnen komen waarin men niet alleen op tijd naar productie levert maar ook op elk moment (Continuous Delivery). Gevolg is dat men ook weer sneller feedback vanuit de klant krijgt.

In dit alles kan een Cloud-omgeving, zoals Amazon Web Services of Microsoft Azure, veel verantwoording en zorg wegnemen. Van het snel kunnen creëren van een extra test-omgeving of services rondom een Blue/Green Deployment tot aan Automated Pipelines tools (Azure Devops en AWS Codepipeline) en omgeving monitoring (Cloudwatch). AWS en Azure bieden diverse services op elk onderdeel van de DevOps-methodiek.

Kun je nu meten of DevOps werkt?

Er zijn diverse indicatoren waaraan je kunt zien dat een DevOps implementatie zijn vruchten afwerpt. Enkele gemakkelijke voorbeelden hiervan zijn:

  • Lead Time (de tijd tussen het starten van ontwikkeling van een feature tot aan het moment dat deze in productie staat);
  • Beschikbaarheid van de omgeving;
  • Het aantal Deployments (zowel de frequentie als het aantal features).

Maar… de allerbelangrijkste indicator is nog altijd; “blije en gemotiveerde medewerkers!”

[i] https://nl.wikipedia.org/wiki/DevOps

[ii] https://en.wikipedia.org/wiki/Agile_software_development

Over de auteur:

Marc Valk is ‘Innvolved’ sinds 2020 en gespecialiseerd op AWS. Daarnaast schrijft hij regelmatig over zijn vakgebied en opvallende trends die hem interesseren.

Gerelateerd

Meer innformatie?

Wil je meer weten over DevOps ontrafeld; wat is het en waarom heeft het de toekomst?, neem dan contact met ons op.