Wat is DevOps?

Je bent softwareontwikkelaar en hebt wekenlang hard gewerkt aan de enorm verbeterde 2.0 versie van je applicatie. Bijna alles is af en het moment dat je kunt gaan uitrollen in productie is aangebroken. Je hebt je best gedaan om een goede installatie- en beheer handleiding op te stellen, er zijn geen blokkerende testresultaten en je hebt vrijwel alle vragen van de business beantwoord. De enige die nog dwars ligt is de systeembeheerder…

Je bent systeembeheer en hebt net de laatste operationele problemen opgelost na de uitrol van een nieuwe applicatie. Twee stressvolle dagen troubleshooten liggen achter je omdat de softwareontwikkelaar niet duidelijk in zijn handleiding had vermeld dat er een library vereist is die niet standaard op de productieservers aanwezig is. Je zit er uiteraard niet op te wachten om bij de volgende applicatie opnieuw te moeten puinruimen….

Herkenbaar? Als oplossing voor dit soort situaties is in 2009 de DevOps filosofie bedacht en nadien verder ontwikkeld. DevOps beslaat de gehele levensloop van een applicatie en wordt gedragen door drie pilaren: development en operations (zoals de naam al doet vermoeden) en kwaliteitsbeheer (QA, quality assurance). Ontwikkelaars, systeembeheerders en kwaliteitsmanagement werken bij DevOps in één (virtueel) team nauw samen om een product of dienst te ontwerpen, te bouwen en continue te verbeteren. Dit alles om uiteindelijk meer waarde voor de klant te realiseren.

Bron: https://commons.wikimedia.org/wiki/File:Devops.svg

Dev is mijn ding: wat verandert er voor mij?

Ben je software-ontwikkelaar? Dan blijft het schrijven van programmeercode voor je applicatie(s) nog steeds je primaire taak. Je krijgt er echter een belangrijke verantwoordelijkheid bij: je wordt met DevOps ook verantwoordelijk voor de operatie van de door jou geschreven code. Je zult dus samen met de systeembeheer(s) moeten zorgen dat jouw code zo goed mogelijk kan draaien op de onderliggende infrastructuur. Gaat er iets mis? Dan word je direct betrokken bij het oplostraject. Je staat er echter niet alleen voor, want je Ops-collega’s staan naast je en niet meer tegenover je.

Ops als een baas: wat verandert er voor mij?

Als systeembeheerder blijft het je voornaamste taak om te zorgen dat de infrastructuur (netwerk, storage, servers, containers) die bij de applicatie of service horen operationeel zijn. Je krijgt er echter een belangrijke verantwoordelijkheid bij: ook het continue optimaliseren en up-to-date houden van de omgeving is nu onderdeel van je takenpakket. Op die manier zorg je ervoor dat de infrastructuur zo goed mogelijk aansluit bij de wensen van de ontwikkelaars in je team. Op basis van onder meer analyse en monitoring bekijk je proactief of alles naar wens draait. Zijn er afwijkingen? Dan los je die waar nodig direct op, al dan niet in samenwerking met de ontwikkelaar(s). Draait alles zoals het hoort? Dan helpt je je Dev-collega’s met het schrijven van scripts of het verder automatiseren van het IT-landschap. Er komt hierdoor in groeiende mate nadruk te liggen op kennis en kunde op gebied van scripts en programmeren.

QA

Ook kwaliteitsmanagement is onderdeel van werken volgens de DevOps filosofie. QA heeft als taak om ervoor te zorgen dat het werk van Dev en Ops continu wordt getoetst op basis van een set van kwaliteitseisen. Dit is belangrijk om te borgen dat de toegenomen hoeveelheid wijzigingen aan applicatie en IT-infra niet zorgt voor een groei van het aantal incidenten en storingen. QA voorkomt daardoor verrassingen en bijbehorende stress en paniek. QA ziet er tevens op toe dat alle producten en diensten worden gebouwd en onderhouden volgens de voorschriften en standaarden die binnen de organisatie gelden. QA heeft hiermee een belangrijke rol op gebied van conformiteit (en daarmee richting o.a. ISO certificering).

Hoe zit het met security en de business?

Op internet duiken de termen SecDevOps en DevOpsSec steeds vaker op. Ook kom je BusDevOps met enige regelmaat tegen. Het idee achter deze beide varianten op DevOps is dat er meer schakels in de productketen zitten dan alleen Dev en Ops en dat deze schakels ook betrokken moeten worden bij de totstandkoming en uitrol van software. Hoewel dat op zich terecht is, gaat de DevOps filosofie er in basis al vanuit dat de business en security onderdeel zijn van de samenwerking. Security is hierbij een belangrijk onderdeel van QA (veiligheid is een vorm van kwaliteit). De business is aangehaakt omdat er constant contact met de ontwikkelaars is over functionaliteit en werking van de applicatie. Omdat er in snelle, korte releases wordt gewerkt is er dus ook frequent contact met de business nodig om te zorgen dat er voldoende vraag naar nieuwe functionaliteit blijft. Wanneer dit niet gebeurt dan droogt het werk uiteindelijk op.

Waarom DevOps?

Door het stimuleren en faciliteren van samenwerking tussen softwareontwikkelaars en systeembeheerders worden problemen die ontstaan bij overdracht en op gebied van verantwoordelijkheden weggenomen. Er zijn daardoor geen tegenstrijdige belangen meer en door de nauwe betrokkenheid bij de hele levenscyclus van de applicatie wordt voorkomen dat er op het laatste moment nog verrassingen optreden. Dit komt niet alleen de snelheid waarmee nieuwe of functionaliteit of een verbetering aan een applicatie kan worden toegevoegd ten goede, maar zorgt intrinsiek ook voor een hogere kwaliteit. Deze eigenschappen maken dat DevOps perfect samengaat met werken op basis van Agile en Scrum.

Hoe begin ik met DevOps?

In veel gevallen vraagt DevOps op meerdere manieren om een flinke verandering. Denk hierbij aan verandering van:

  • De organisatiestructuur: geen silo’s meer, maar multidisciplinaire teams
  • De workflow en/of processen
  • De mindset van medewerkers én het management
  • De benodigde vaardigheden van medewerkers én het management (zowel op gebied van techniek als communicatie)
  • De IT-infrastructuur en de gebruikte beheer- en ontwikkel software

Jazeker, bovenstaande zet de hele organisatie totaal op z’n kop als je op vrijdag besluit dat je vanaf maandag alleen nog maar DevOps gaat doen. Dat is echter (meestal) niet de beste manier. De kans op succes is een stuk groter wanneer je, gebruikmakend van methodes als Agile en Scrum, stap voor stap begint met DevOps. Het optimaliseren van één applicatie of één bedrijfsproces kan al snel resultaat opleveren zonder dat er direct een enorme, organisatiebrede verandering wordt doorgevoerd. Met de opgedane kennis en ervaring kan vervolgens met vertrouwen een grotere wijziging worden opgepakt. Deze manier van werken heeft bovendien als voordeel dat de organisatie kan wennen aan de verandering. Dat zorgt voor meer begrip en draagvlak. Hoewel het door deze aanpak langer zal duren voordat alles en iedereen DevOps werkt, zal dit op lange termijn zorgen voor een beter resultaat.

Continuous Integration (CI), Continuous Delivery (CD) en Site Reliability Engineering (SRE)

Wie leest over DevOps komt in veel gevallen in aanraking met de termen CI, CD en SRE. CI en CD zijn methodes die invulling kunnen geven aan een deel van de DevOps filosofie.

Continuous Integration

Continuous Integration zorgt ervoor dat wijzigingen aan de applicatiecode door verschillende ontwikkelaars snel en effectief worden samengevoegd tot één nieuwe versie. Hiermee wordt het samenvoegen van code veel minder tijdrovend en complex. Dit bespaart niet alleen tijd, maar helpt ook bij het verhogen van de kwaliteit van de code omdat fouten of conflicten sneller worden ontdekt en in veel gevallen kleiner van omvang zijn (en daarmee eenvoudiger te corrigeren). De bij ontwikkelaars beruchte “merge hell” wordt hiermee voorkomen.

Continuous Delivery

Continuous Delivery streeft naar een zoveel mogelijk geoptimaliseerd proces om software uit te rollen. De twee belangrijkste uitgangspunten hierbij zijn: testen, testen, testen & automatiseren, automatiseren, automatiseren. Dit gaat zo ver dat de eerste stap van deze methode is om vooraf, nog voor je begint met schrijven van je applicatie, te definiëren hoe je geautomatiseerd gaat testen of de software het goed doet. Omdat je hierdoor vanaf de eerste regel code kunt vaststellen of je software goed werkt, kun je in combinatie met volledig geautomatiseerd uitrollen, zeer hoge kwaliteit garanderen en de kans op fouten reduceren. Uitrollen naar productie wordt hierdoor een stuk minder spannend en de doorlooptijd van wijzigingen kan aanzienlijk worden verlaagd.

Site Reliability Engineering

Site Reliability Engineering is een term die is bedacht door een medewerker van Google. Het doel van SRE is om op basis van continue verbeteren te streven naar een zo optimaal mogelijke betrouwbaarheid van een IT-dienst. Dat kan een applicatie zijn, maar ook een stuk IT-infrastructuur (zoals servers, databases, netwerken of storage). Optimaal wil hierbij niet zeggen: 100% beschikbaar. Optimaal betekent dat naar een gulden middenweg wordt gezocht die rekening houdt met beschikbaarheid, prestaties en kosten waarbij de klanttevredenheid op het gewenste niveau blijft. Om dit optimum te bereiken wordt nauw samengewerkt tussen ontwikkelaars en systeembeheerder (hé dat kennen we van DevOps!). Een Site Reliability Engineer werkt vanuit de Ops kant en kan daarmee worden gezien worden als een nieuwe generatie systeembeheerder.

Net zoals bij DevOps, ligt er bij SRE een zeer duidelijk nadruk op de kruisbestuiving met development en een continu streven naar het verder automatiseren van systemen. Hiervoor heeft Google als best practice een maximum van 50% operationeel werk ingesteld voor iedere engineer. Binnen die 50% moeten incidenten en calamiteiten worden opgelost. Alle overige tijd (liefst meer dan 50%) wordt besteed aan engineering: het structureel optimaliseren (en automatiseren) van de IT-service(s) waar voor je verantwoordelijk bent.

De crux van SRE zit in het werken met een zogeheten error budget. Op basis van marktonderzoek wordt vastgesteld aan welke eisen een IT-dienst moet voldoen. Denk bijvoorbeeld aan een webapplicatie waarvoor 99% van de tijd volledig functioneel zijn het doel is. Het error budget van deze applicatie bedraagt dat 100%-99%=1%. Deze procent geeft extra resources vrij voor het ontwikkelteam om wijzigingen aan de applicatie door te voeren. Hiermee wordt de applicatie dus sneller vernieuwd en bijvoorbeeld van extra functionaliteit voorzien. Zorgen de wijzigingen er echter voor dat de beschikbaarheid afneemt (bijvoorbeeld omdat de vele wijzigingen storingen veroorzaken), dan zal de beschikbaarheid na enige tijd op of onder de 99% komen. Daarmee is het error budget op en zal de frequentie van wijzigingen op de applicatie vanzelf afnemen. Het error budget zorgt dus voor een zelfsturend mechanisme dat steeds een balans zoekt tussen stabiliteit en innovatie.

Bij zowel CI, CD als SRE is continu meten en verbeteren vast onderdeel van de methode of werkwijze. Hiermee wordt gezorgd voor een steeds verdere optimalisatie. Dit heeft een positief effect snelheid, kwaliteit én op de kosten. CI, CD en SRE kunnen je dus helpen om zoveel mogelijk rendement te halen uit DevOps.

Welke DevOps tools kan ik gebruiken?

Het doel van de DevOps filosofie is zoals gezegd het samenbrengen en optimaliseren van development en operations zodat de ontwikkelsnelheid, operationele stabiliteit en kwaliteit van software verbeterd. Om het rendement van DevOps te vergroten, ligt een belangrijke nadruk op automatisering en monitoring van alle stappen die bij het softwareontwikkelproces komen kijken. DevOps zegt echter niets over hoe je je doel bereikt. Je bent dan ook volledig vrij om gereedschap te kiezen waarmee jij denkt het meest succesvol te zijn. Omdat DevOps al bijna tien jaar bestaat, zijn er intussen vele tientallen softwareproducten waarvan in de praktijk is gebleken dat ze erg goed samengaan met de filosofie. Bij AT Computing gebruiken we meestal onderstaande open source software:

  • GitLab voor versiebeheer van code voor zowel de applicatie als bijbehorende infrastructuur (CI)
  • Docker voor het creëren van containers
  • Docker Swarm en Kubernetes voor de orkestratie van containers
  • Jenkins voor het geautomatiseerd uitrollen van nieuwe applicatieversies (CD)
  • Ansible voor het beheer van serverconfiguraties
  • Prometheus voor monitoring
  • Elastic Search, Logstash & Kibana (ELK Stack) voor loganalyse
  • Kanboard, Rocket Chat en Nextcloud voor locatie-onafhankelijk samenwerken

Bron: https://commons.wikimedia.org/wiki/File:Devops-toolchain.svg

Welke kennis en kunde heb ik nodig voor DevOps?

Om de samenwerking tussen softwareontwikkelaars en systeembeheerders te laten slagen, zijn zowel op gebied van communicatie, techniek als management nieuwe vaardigheden nodig.

  • Softwareontwikkelaars moeten de basis van de gebruikte IT-infrastructuur snappen
    systeembeheerders moeten in staat zijn om automatiseringsscripts te schrijven (lezen van programmeercode is een pré)
  • Periodieke teambuilding activiteiten en training van softs kills zijn nodig om de onderlinge samenwerking en communicatie op niveau te krijgen en te houden training in methodes als Agile en Scrum helpen om grip te krijgen op het nieuwe ritme van continue wijzigen
  • Training voor gebruik van nieuw digitaal gereedschap is vereist
  • Managers moeten zorgen voor aansturing die past bij de dynamiek van een DevOps team en hebben daarnaast als belangrijkste taak om continue te helpen om de samenwerking in het team te verbeteren en te zorgen dat aan de juiste randvoorwaarden wordt voldaan om meer en meer snelheid te kunnen ontwikkelen

 

Wat kan AT Computing op gebied van DevOps voor jou betekenen?

Onze consultants kunnen je gedegen en onafhankelijk advies geven. Daarnaast helpen ze graag bij het automatiseren van je werkprocessen en het implementeren van de benodigde software. Met Remote Services kunnen we je volledig ontzorgen op gebied van operations door op basis van GitLab, Docker, Ansible en Prometheus diverse diensten te leveren. Wil je jezelf verder ontwikkelen? In dat geval staan onze docenten voor je klaar om je met kwaliteitsopleidingen van alle benodigde kennis en kunde te voorzien. Hierdoor biedt AT Computing alles wat je nodig hebt om van DevOps binnen jouw bedrijf een succes te maken.

Wil je meer weten of heb je vragen? Bel dan (024) 352 72 82 of stuur een mailtje naar info@atcomputing.nl

Onderwerpen
Actieve filters: Wis alle filters
Loading...