DevOps Handboek E-Book

Oleg Skrynnik

• Herausgeber: Van Haren Publishing
• Kategorie: Fachliteratur
• Sprache: Niederländisch

Seitenzahl: 203

Veröffentlichungsjahr: 2019

Beschreibung

Dit boek legt de managementaspecten van DevOps uit voor degenen die zich professioneel bezighouden met informatie- en technologiemanagement. Het is geschreven voor IT-specialisten, IT-managers en IT-executives. Het toont DevOps niet als een fenomeen dat geassocieerd wordt met nieuwe automatiseringstools, programmeertechnieken of -technologieën en het verschilt van andere boeken door het gestructureerde verhaal (misschien is het overmatig gestructureerd) en door de poging om het fenomeen DevOps volledig te dekken op zowel een basis- als een fundamenteel niveau. Door die benadering wordt de lezer zich bewust van het nieuwe onderwerp en helpt het boek de fundering de bouwen, de basis. De lezer leert over de oorsprong van DevOps, de onvermijdelijkheid van zijn opkomst, de belangrijkste voorwaarden ervan en hoe die in de praktijk tot uiting komen, over de praktijk zelf en de principes waarop die is gebaseerd. In dit boek staat de stof voor de EXIN DevOps Foundation certificering. Dit examen test het begrip van (1) de basisconcepten van DevOps, (2) hoe deze aan elkaar gerelateerd zijn, en (3) de waarde van DevOps voor de business. EXIN DevOps Foundation is het eerste niveau van het EXIN DevOps certificeringsprogramma. De EXIN DevOps Professional certificering test de kennis van de DevOps praktijk en van hoe teams te integreren. De EXIN DevOps Master certificering gaat over het bevorderen van organisatieverandering en over het toeleiden naar continu leveren en verbeteren.

Leseprobe

DevOps Handboek

Andere uitgaven bij Van Haren Publishing

Van Haren Publishing (VHP) is gespecialiseerd in uitgaven over Best Practices, methodes en standaarden op het gebied van de volgende domeinen:

- IT en IT-management;

- Enterprise-architectuur;

- Projectmanagement, en

- Businessmanagement.

Deze uitgaven zijn beschikbaar in meerdere talen en maken deel uit van toonaangevende series, zoals Best Practice, The Open Group series, Project management en PM series.

Van Haren Publishing is tevens de uitgever voor toonaangevende instellingen en bedrijven, onder andere: Agile Consortium, ASL BiSL Foundation, CA, Centre Henri Tudor, Gaming Works, IACCM, IAOP, IPMA-NL, ITSqc, NAF, KNVI, PMI-NL, PON, The Open Group, The SOX Institute.

Onderwerpen per domein zijn:

IT and IT Management

ABC of ICT

ASL®

CATS CM®

CMMI®

COBIT®

e-CF

ISM

ISO/IEC 20000

ISO/IEC 27001/27002

ISPL

IT4IT®

IT-CMFTM

IT Service CMM

ITIL®

MOF

MSF

SABSA

SAF

SIAMTM

TRIM

VersiSMTM

Enterprise Architecture

ArchiMate®

BIAN

GEA®

Novius Architectuur Methode

TOGAF®

Business Management

BABOK ® Guide

BiSL® and BiSL® Next

BRMBOKTM

BTF

EFQM

eSCM

FSM

IACCM

ISA-95

ISO 9000/9001

OPBOK

SixSigma

SOX

SqEME®

Project Management

A4-Projectmanagement

DSDM/Atern

ICB / NCB

ISO 21500

MINCE®

M_o_R®

MSP®

P3O®

PMBOK ® Guide

Praxis®

PRINCE2®

Voor een compleet overzicht van alle uitgaven, ga naar onze website: www.vanharen.net

Colofon

Titel:

DevOps Handboek

Auteur:

Oleg Skrynnik

Oorspronkelijke titel:

DevOps – A Business Perspective

Oorspronkelijke uitgever:

Van Haren Publishing, ’s-Hertogenbosch, 2019

Vertaling:

Theo Wanders, Maarssen

Tekstredactie:

Janneke Wolters, Amsterdam

Illustraties:

Oleg Skrynnik

Uitgever:

Van Haren Publishing, ’s-Hertogenbosch, www.vanharen.net

ISBN Hard copy:

9789401804363

ISBN eBook:

9789401804370

ISBN ePub:

9789401804387

Druk:

Eerste druk, maart 2019

Lay-out en DTP:

Coco Bookmedia, Amersfoort – NL

Copyright:

© Van Haren Publishing

Trademarks:

COBIT© is a registered trademark of ISACA

ITIL© is a registered trademark of AXELOS Limited

SAFe© is a registered trademark of Scaled Agile, Inc.

Copyright

Niets uit deze opgave mag vermenigvuldigd, vastgelegd in een geautomatiseerd bestand of openbaar gemaakt worden op of via enig medium, hetzij elektronisch, mechanisch, door fotokopieën of anderszins, zonder voorafgaande schriftelijke toestemming van de uitgever.

Ondanks alle zorg die aan deze uitgave is besteed, kunnen er eventuele fouten in voorkomen. De uitgever en de auteurs aanvaarden geen aansprakelijkheid voor het optreden van fouten en/of onvolkomenheden.

Voorwoord

Dit boek is geschreven door een IT-manager, voor IT-specialisten, IT-managers en IT-executives. Het toont DevOps niet als een fenomeen dat geassocieerd wordt met nieuwe automatiseringstools, programmeertechnieken of -technologieën, maar het verklaart de managementaspecten van DevOps voor degenen die zich professioneel bezighouden met informatietechnologie en informatiemanagement.

Het verschilt van andere boeken door het gestructureerde verhaal (misschien is het overmatig gestructureerd) en door de poging om het fenomeen DevOps volledig te dekken op zowel een basis- als een fundamenteel niveau. Dit betekent niet dat de inhoud oppervlakkig is, net voldoende om het bewustzijn over het nieuwe onderwerp te vergroten. ‘Fundamenteel niveau’ betekent het bouwen van de fundering, de basis: ik heb het over de oorsprong van DevOps, de onvermijdelijkheid van zijn opkomst, de belangrijkste voorwaarden ervan en hoe die in de praktijk tot uiting komen, over de praktijk zelf en de principes waarop die is gebaseerd.

Ondanks de overvloed aan literatuur over dit onderwerp, is dit het boek dat ik echt miste toen ik zelf DevOps studeerde. Ik streef ernaar om een duidelijke, gestructureerde en beknopte beschrijving van dit complexe maar zeer interessante onderwerp te geven. Ik durf te hopen dat er geen overtollige termen in dit boek staan, en dat alle noodzakelijke termen juist wel aanwezig zijn.

Ik moet mijn oprechte dank betuigen aan mijn familie en vrienden. Ik kan niet zeggen dat ze me hebben geholpen om dit boek te schrijven: gelukkig hebben ze heel weinig te maken met zaken als DevOps. Ze hebben er echter absoluut last van gehad: heel vaak, van juli tot december 2017, zonderde ik mijzelf af van de buitenwereld en reageerde ik niet op hun signalen; soms eiste ik zelfs ‘s avonds stilte.

Ik moet ook mijn collega’s bij Cleverics bedanken. We hebben dit bedrijf opgezet samen met de slimste mensen die ik ooit heb ontmoet, en dat was toevallig een van de belangrijkste beslissingen van mijn leven. Gemeenschappelijke doelen en principes, vrijheid in besluitvorming, verantwoordelijkheid voor de resultaten, en partners die klaarstaan om me te ondersteunen wanneer het nodig is – zonder dit zou ik geen tijd vinden om mijn denken over DevOps te structureren en het in dit boek op te nemen.

Tot slot bedank ik onze klanten: ze blijven ons nieuwe en opwindende problemen aanbieden om op te lossen; nieuwe uitdagingen. Ze blijven nieuwe trainingen, workshops en simulaties eisen; ze willen meer en beter. Ze staan letterlijk niet toe dat we stil blijven staan en stuwen ons constant vooruit.

De auteur, Moskou, herfst 2018

Over dit boek

In dit boek staat de stof voor de EXIN DevOps Foundation certificering. Dit examen test het begrip van (1) de basisconcepten van DevOps, (2) hoe deze aan elkaar gerelateerd zijn, en (3) de waarde van DevOps voor de business. EXIN DevOps Foundation is het eerste niveau van het EXIN DevOps certificeringsprogramma. De EXIN DevOps Professional certificering test de kennis van de DevOps praktijk en van hoe teams te integreren. De EXIN DevOps Master certificering gaat over het bevorderen van organisatieverandering en over het toeleiden naar continu leveren en verbeteren.

Uit het veld

‘Ik dacht dat ik wel een beetje wist van DevOps, maar ik heb veel geleerd van dit boek. Het is in een verhalende stijl geschreven, wat ik leuk vind. Het is geschreven vanuit het perspectief van legacy werkwijzen die zich verplaatsen naar nieuwe manieren van werken en niet zozeer vanuit een ontwikkelingstechnische focus. Het raakt alle punten die ik zou raken als ik er ooit toe zou zijn gekomen om zo’n boek te schrijven. Ik zal het nu niet doen, omdat Oleg het zo goed heeft gedaan. Goed gedaan!‘

Rob England

‘DevOps Handboek is een goed geschreven en zorgvuldig samengestelde samenvatting van de belangrijkste DevOps-onderwerpen die IT-managers moeten kennen. Het combineert onpartijdigheid met scherpzinnige en bruikbare persoonlijke observaties – de auteur kent zijn stof duidelijk. Ik verwacht het van tijd tot tijd te raadplegen en ik aarzel niet om het aan te bevelen.’

Mark Smalley

‘Een gemakkelijk te lezen en goed doordacht en geconstrueerd overzicht van de geschiedenis van Devops in termen van werkwijzen en de bijbehorende technologie. Het biedt een aantal goede samenvattingen, toont dilemma’s waar organisaties voor staan en geeft enkele goede voorbeelden van het maken van keuzes om vooruit te komen. Het signaleert tegelijkertijd potentiële belemmeringen en valkuilen om te vermijden. Als je een DevOps 101 wilt, is dit het.’

Paul Wilkinson

Inhoud

1 WAT IS DEVOPS?

1.1 De oorsprong

1.1.1 Agile methoden voor softwareontwikkeling

1.1.2 Het managen van de IT-infrastructuur als code

1.1.3 Het was onvermijdelijk

1.2 De definitie

1.3 Waarom DevOps?

1.3.1 Reduceer time-to-market

1.3.2 Reduceren van technical debt

1.3.3 Elimineer kwetsbaarheden

1.4 De ontstaansgeschiedenis

1.5 Veelvuldig geuite misvattingen

1.5.1 DevOps is een onderdeel van Agile

1.5.2 Bij DevOps draait alles om tools en automatisering

1.5.3 DevOps is een nieuw beroep

1.6 Samenvatting

2 DE FOUNDATION

2.1 Lean productie

2.1.1 Belangrijkste feiten

2.1.2 Uitdagingen

2.2 Agile

2.2.1 Belangrijkste feiten

2.2.2 Uitdagingen

3 DE PRINCIPES

3.1 Waardestroom

3.2 Deployment pijplijn

3.3 Alles moet worden opgeslagen in een versiebeheersysteem

3.4 Geautomatiseerd configuratiebeheer

3.5 De Definition of Done

3.6 Samenvatting

4 KEY PRACTICES

4.1 Belangrijkste verschillen met traditionele werkwijzen

4.1.1 Een release is een routine

4.1.2 Een release is een zakelijke beslissing

4.1.3 Alles is geautomatiseerd

4.1.4 Incidenten worden onmiddellijk opgelost

4.1.5 Fouten worden onmiddellijk verholpen

4.1.6 Processen worden continu verbeterd

4.1.7 Doe als een start-up

4.2 Ongebruikelijke teams

4.3 Werkvisualisatie

4.4 Beperk work in progress

4.5 Verminder de batchgrootte

4.6 Let op de operationele vereisten

4.7 Vroegtijdige detectie en correctie van fouten

4.8 Gecontroleerde en niet-gecontroleerde verbeteringen en innovaties

4.9 Financiering die innovaties mogelijk maakt

4.10 Prioriteitstelling van taken

4.11 Voortdurende identificatie, exploitatie en beperkingen

4.12 Samenvatting

5 PRAKTISCHE TOEPASSING

5.1 De toepasbaarheid en beperkingen van DevOps

5.2 COTS

5.3 Evoluerende architectuur

5.4 DevOps en ITSM

5.5 Cargocultus

5.6 Begin waar u staat, boek iteratief vooruitgang

5.7 Waardestroom als de kern

5.8 Samenvatting

6 CONCLUSIE

BIJLAGEN

Bijlage 1 Test: Doet u DevOps?

Bijlage 2 Aanbevolen literatuur

OVER DE AUTEUR

INDEX

1   WAT IS DEVOPS?

Methoden voor IT-management staan niet stil. Het ontwikkelen en beheren van informatiesystemen pakt men tegenwoordig anders aan dan enkele decennia geleden. Bovendien zal er in de nabije toekomst alweer een volgende generatie opkomen van verfijnde methoden en technieken, die gebaseerd zullen zijn op nieuwe kennis, ervaring en technologie. Meestal evolueren managementmethoden geleidelijk, door middel van het systematiseren en aanscherpen van de modellen die eerder zijn gemaakt, op basis van bepaalde basisprincipes en behoeften. Van tijd tot tijd treden er echter discontinuïteiten op, waardoor individuele leidende organisaties een belangrijke stap voorwaarts kunnen maken met betrekking tot effectief en efficiënt gebruik van informatietechnologie.

Een goed voorbeeld is de overgang van de focus op IT-systemen naar het managen van IT-services door IT-management. Dit wordt IT-servicemanagement (ITSM) genoemd. Deze verandering in de visie van het management van rond het jaar 2000 stelde pioniers in staat belangrijke concurrentievoordelen te behalen. Opkomende management practices werden overgenomen door leiders, en veranderden in zogenoemde best practices. Enkele van de best practices evolueerden verder naar algemeen aanvaarde good practices en droegen zelfs bij tot industriestandaarden. Niet alle organisaties gebruikten best practices of normen in hun werk omdat niet alle sectoren van de economie in die tijd in belangrijke mate afhankelijk waren van informatietechnologie. Onder ‘practices’ (praktijkhandelingen of werkwijzen) verstaan we activiteiten uitgevoerd volgens bepaalde principes om een gewenste uitkomst te produceren.

Laten we eens kijken naar IT-servicemanagement. In de jaren tachtig ontstond het idee om waarde te genereren uit informatietechnologie in de vorm van services (diensten) en om IT-activiteiten in de vorm van processen te organiseren. Bepaalde Europese bedrijven werden pioniers, ontwikkelden nieuwe werkwijzen voor het organiseren van werk en nieuwe benaderingen voor het oplossen van managementproblemen. Enkele van de practices, zoals de introductie van een servicedesk, onderscheid tussen incidenten en problemen, beheerde en gecontroleerde wijzigingen in de IT-infrastructuur, enzovoort, werden geformuleerd in 2000-2001 in belangrijke publicaties zoals ITIL® (dat staat voor IT-infrastructure library)1. Leidende organisaties en vele ‘volgers’ gebruikten deze publicaties, en daardoor werden ze best practices. Uiteindelijk werd in het jaar 2002 de eerste standaard voor IT-servicemanagement gepubliceerd: BS 15000-1: 2002, die een bepaalde norm vastlegde voor degenen die een samenhangend IT-servicemanagementsysteem wilden opbouwen. Inmiddels is BS 15000-1 vervangen door ISO/IEC 20.000-1 en ISO/IEC 20.000-2. Daaruit zal duidelijk zijn dat practices, publicaties en standaarden niet stoppen met hun ontwikkeling, maar zich verder ontwikkelen.

Figuur 1.1 Opkomst en gebruik van nieuwe practices

Soortgelijke dynamiek kan nu worden waargenomen in Agile softwareontwikkeling. De revolutie die hier plaatsvindt, beïnvloedt echter een groter gebied dan alleen softwareontwikkeling en de omvang van de gevolgen kan even groot zijn als die van ITSM.

Nieuwe, opkomende practices worden geëtiketteerd als ‘DevOps’ (Development + Operations), wat net zover verwijderd is van de beoogde betekenis als die van ITIL® ver verwijderd is van het ‘bibliotheekconcept’. Evenzo is de huidige COBIT ver verwijderd van controledoelstellingen (Control Objectives for Information and Related Technology)2.

Figuur 1.2 Ontwikkeling van practices

Tijdens het publiceren van COBIT 5 in 2012 wees de auteursrechthouder erop dat, hoewel COBIT oorspronkelijk een afkorting was van Control Objectives for Information and Related Technology, het nu juist een naam is.

AXELOS Limited heeft sinds 2013 soortgelijke opmerkingen gemaakt over ITIL®.

DevOps-experts, die de initiatiefnemers van deze beweging waren, erkennen de beperkte aard van de naam, en hebben nauwkeuriger namen geopperd. De kans om de naam te wijzigen is nu echter onwaarschijnlijk.

Het DevOps-fenomeen is dus het bestuderen waard. Om de essentie van DevOps volledig te begrijpen, is het noodzakelijk om de achtergrond van zowel het idee als de bijbehorende beweging te beschouwen.

▪  1.1 DE OORSPRONG

Je zou kunnen stellen dat DevOps verscheen vanwege twee factoren: brede acceptatie van Agile softwareontwikkelmethoden en van beheer van IT-infrastructuur als code. Uitleg over IT-infrastructuur als code volgt in paragraaf 1.1.2. Laten we eerst kijken naar Agile softwareontwikkelmethoden.

1.1.1 Agile methoden voor softwareontwikkeling

Aan het einde van de twintigste eeuw was de dominante methode van softwareontwikkeling het zogenoemde ‘watervalmodel’: sequentiële uitvoering van vooraf bepaalde fasen, die elk een aanzienlijke tijd in beslag nemen en eindigen met het behalen van eerder overeengekomen resultaten; overgang naar de volgende fase gebeurt in veel gevallen pas nadat de vorige fase volledig en formeel is voltooid. Zie figuur 1.3. Een bijkomend onderscheidend kenmerk van dit model is de functionele specialisatie van de betrokken personen in elke fase: analisten, architecten, ontwikkelaars, testers, enzovoort.

Figuur 1.3 Een voorbeeld van een waterval softwareontwikkelingsmodel

Voor het ontwikkelen van grote informatiesystemen met vooraf gedefinieerde functionaliteit, zonder dat snelle levering vereist werd, in een weinig veranderende omgeving, was het een bruikbaar model dat een effectieve en gedetailleerde kostenbeheersing mogelijk maakte.

Eind jaren negentig, met de snelle groei van internettechnologieën en webprogrammering, begonnen de negatieve kanten van het watervalmodel de interactie en het begrip te beïnvloeden tussen klanten van informatiesystemen (interne of externe bedrijven) en providers (interne of externe softwareontwikkelaars). Marktkansen voor zakelijke klanten vereisten immers snelle lancering (binnen enkele maanden) van nieuwe producten op de markt. Een typische ontwikkelingscyclus van het begin van het project tot het eerste werkende prototype zou echter zes tot achttien maanden in beslag kunnen nemen; en twee tot drie jaar in grotere ondernemingen. Met de opkomst van voorheen onbekende, maar potentieel veelbelovende marktkansen, zouden de eisen van de klant in de loop van de ontwikkeling kunnen veranderen, wat buitengewoon moeilijk was om mee te nemen zonder de deadlines te verschuiven, het budget te overschrijden of de scope en de kwaliteit van het product te verminderen. Zie figuur 1.4.

Figuur 1.4 Klassieke piramide van de beperkingen van projectmanagement

Zo ontstond er spanning tussen klanten en providers; tussen de corebusiness en softwareontwikkelaars. Innovatieve benaderingen van programmeren waren het antwoord op deze uitdaging. Ken Schwaber publiceerde verschillende boeken over Scrum.3 Kent Beck publiceerde een boek over eXtreme Programmering, ofwel XP.4 Het effect van de toepassing van deze nieuwe ideeën was echter bescheiden, vooral omdat ze zich concentreerden op slechts één van de fasen van de softwareontwikkelingscyclus – de eigenlijke programmering – terwijl het probleem groter was. De end-to-end softwareontwikkelingscyclus moest worden vereenvoudigd en versneld.

In 2001 kwamen Schwaber en Beck samen met vijftien andere experts bijeen om de bestaande problemen te bespreken en een oplossing uit te werken. Het resultaat van de bijeenkomst was het zogenoemde Agile Manifesto5. Dit is ontworpen om de kloof tussen bedrijfs- en softwareontwikkelaars te overbruggen. Een van de auteurs van het manifest, Robert C. Martin, legt uit:6

‘Vertrouwen tussen ontwikkelaars en bedrijven kan ontstaan en zich ontwikkelen wanneer de juiste disciplines en het juiste minimale proces worden gebruikt. Bedrijven zullen de ontwikkelaars gaan vertrouwen in plaats van te denken dat ze luie, corrupte, vervelende wezens zijn, en de ontwikkelaars zullen aandacht gaan schenken aan de business en beseffen dat het redelijke en rationele wezens zijn, in plaats van iemand van een andere planeet.’

De daaropvolgende ontwikkeling en toepassing van Agile methoden door de gemeenschap van programmeurs en projectmanagers heeft de ontwikkeling van software enorm versneld en geherstructureerd.

Agile Manifesto

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door het te doen en door anderen ermee te helpen. Daarmee komen we tot de volgende waardestatements:

Mensen en hun onderlinge interactie

boven

processen en tools

Werkende software

boven

allesomvattende documentatie

Samenwerking met de klant

boven

contractonderhandelingen

Inspelen op verandering

boven

het volgen van een plan

Dat wil zeggen dat hoewel de items aan de rechterkant waardevol zijn, wij toch aan de items aan de linkerkant meer waarde hechten.

We volgen deze principes:

1. Onze hoogste prioriteit is de klant tevreden te stellen door het vroegtijdig en voortdurend opleveren van waardevolle software.

2. Verwelkom veranderende behoeften, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.

3. Lever frequent werkende software op. Liefst elke paar weken, ten minste elke paar maanden, met een voorkeur voor een korte tijdsperiode.

4. Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het project.

5. Bouw projecten rond gemotiveerde individuen. Geef hun de ondersteuning en omgeving die ze nodig hebben, en vertrouw erop dat ze de klus klaren.

6. De efficiëntste en effectiefste manier om informatie te delen in en met een Development Team is een face-to-facegesprek.

7. Werkende software is de primaire maatstaf voor voortgang.

8. Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten in staat zijn om een constant tempo te handhaven.

9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken Agility.

10. Eenvoud – de kunst van het maximaliseren van werk dat niet gedaan hoeft te worden – is essentieel.

11. De beste architecturen, eisen en ontwerpen komen voort uit zelforganiserende teams.

12. Op regelmatige tijdstippen onderzoekt het team hoe het effectiever kan worden en past het vervolgens zijn gedrag daarop aan.

De belangrijkste elementen van Agile ontwikkeling zijn: nauwere interactie tussen de klant en de ontwikkelaar, vermindering van de batchgrootte, producten die met korte tussenpozen worden geleverd (cycli) en beperkte omvang van de teams.

Met behulp van een Agile benadering brengt het softwareontwikkelteam om de twee tot vier weken een nieuw levensvatbaar (deel)product uit. Eindgebruikers zijn nauw betrokken bij de ontwikkeling en zorgen voor snelle feedback, wat op zijn beurt tot snellere veranderingen leidt.

In veel bedrijven was het effect echter kleiner dan verwacht, toen men het watervalmodel losliet ten gunste van Agile ontwikkeling. Het niet profiteren van Agile in veel bedrijven heeft vaak weinig te maken met de voordelen van het watervalmodel of de nadelen van Agile. Het probleem komt voort uit het feit dat de ontwikkeling van de code slechts een van de schakels in een lange waardeketen is.

Sterker nog, voorafgaand aan de ontwikkeling moeten er nog steeds belangrijke stappen gezet worden die gericht zijn op het identificeren van zakelijke behoeften, hun uitwerking, analyse, prioritering, enzovoort. Bovendien moeten applicaties na ontwikkeling snel worden geïmplementeerd in de productieomgeving, zodat de klanten alle voordelen te zien krijgen die hun waren beloofd, en feedback kunnen geven aan de ontwikkelaars.

De IT-infrastructuur van vrijwel elke organisatie die voor 2010 is opgericht, is echter gebaseerd op rigide, dure hardware die lang geleden is aangeschaft; budgetten daarvoor werden met grote moeite verkregen en het budgetteringsproces voor nieuwe aanbestedingen is lang. Ook is de IT-infrastructuur vrij fragiel in een groot aantal organisaties. Een van de factoren die aan deze kwetsbaarheid bijdragen, is dat de gebruikte IT-oplossingen uiterst complex zijn. Er zijn vele duizenden onderling verbonden items in de infrastructuur. Een andere factor is het gebrek aan documentatie over IT-systemen en de snelle veroudering van de documentatie. Dit laatste wordt noodzakelijkerwijs voortdurend versterkt door het verlies van kennis als gevolg van het personeelsverloop.

In veel organisaties is het onveilig om de IT-infrastructuur te veranderen. Wijzigingen zijn het grootste kwaad voor de operationele activiteiten van de IT-afdeling en een constante grote stroom van wijzigingen kan tot catastrofale gevolgen leiden. Geavanceerde methoden voor softwareontwikkeling worden dus opgehouden door obstakels aan de kant van operationele IT-activiteiten, waardoor het mogelijke positieve effect van het toepassen van Agile benaderingen wordt verminderd.

Om met fragiliteit van de IT-infrastructuur om te gaan, gebruiken sommige organisaties een geformaliseerd change management proces dat ontworpen is om de stroom van wijzigingen te structureren en de risico’s verbonden aan hun implementatie te minimaliseren.

1.1.2 Het managen van de IT-infrastructuur als code

De opkomst van het managen van de IT-infrastructuur als code werd voorafgegaan door de ontwikkeling van twee technologieën: virtualisatie en cloud computing.

De geschiedenis van virtualisatie van software- en hardwareomgevingen begon redelijk lang geleden, in 1964, met het begin van de ontwikkeling van het IBM CP-40-besturingssysteem7. Tijdens de jaren van constante ontwikkeling op dit gebied is aanzienlijke vooruitgang geboekt. De eerste in de handel verkrijgbare systemen voor mainframes verschenen in de jaren zeventig, en die voor later meer gebruikelijke machines op basis van de Intel x86-architectuur verschenen in de jaren tachtig.8 Figuur 1.5 toont een aantal belangrijke gebeurtenissen gerelateerd aan virtualisatie tussen 1964 en 2008 (de grafiek stopt niet per ongeluk in dat jaar, zoals u later zult zien).

Figuur 1.5 Belangrijke virtualisatiegebeurtenissen verdeeld in de tijd

Virtualisatie maakte het niet alleen mogelijk om dure en krachtige hardware efficiënter te gebruiken, maar ook om een extra niveau van abstractie te introduceren tussen de uitvoerbare code (de businessapplicatie) die iets nuttigs biedt voor de klant en de onderliggende systeemsoftware. Er is een belangrijke stap gezet in de richting van het scheiden van de competenties en verantwoordelijkheden van, zo te zeggen, application engineers en system engineers, in de brede zin van deze concepten.

Cloud computing technologie is nog sneller ontwikkeld. Tot het midden van de jaren negentig boden telecommunicatiebedrijven hun klanten de Wide Area Network service (WAN-service) aan door de relevante eindpunten met elkaar te verbinden: voor elke klant met directe bekabeling, de zogenoemde ‘huurlijnen’. Met de opkomst van private virtuele netwerktechnologie (VPN, Virtual Private Network) werd het echter mogelijk om datapakketten van verschillende klanten via dezelfde datatransmissiekanalen te verzenden, waarbij ook het vereiste niveau van beveiliging, privacy en servicekwaliteit werd geboden. In die tijd begonnen aanbieders het cloudsymbool te gebruiken om de grens te laten zien tussen het privé-netwerk van de klant en het gedeelde netwerk, en de respectieve scheiding van verantwoordelijkheid.

Met de nieuwe mogelijkheid om gegevens over lange afstanden over te zetten, begonnen klanten deze technologieën niet alleen te gebruiken voor de informatie-uitwisseling tussen hun externe systemen, maar ook voor het distribueren van de computerberekeningen tussen verschillende knooppunten van hun netwerken. De opkomst van een technologie om deze interactie te vereenvoudigen en in te regelen, werd ingegeven. Kleine providers namen de eerste stappen, maar echt belangrijke veranderingen vonden plaats in 2006, toen Amazon EC2 (Elastic Compute Cloud) presenteerde. Al snel, in 2008, lanceerde Microsoft zijn service, Azure, en introduceerde Google de Google App Engine, die vervolgens is geëvolueerd naar het Google Cloud Platform. Dit zijn natuurlijk niet de enige voorbeelden van het verhuren van computercapaciteit, maar het zijn de grootste.

Virtualisatie en cloudtechnologieën hebben het computerlandschap aanzienlijk veranderd. Middelen aangeboden door commerciële aanbieders zijn betaalbaar en betrouwbaar geworden; ze hebben ook gezorgd voor het nodige beveiligingsniveau. De houding van de klant ten opzichte van de cloud en het gebruik ervan is veranderd van: ‘Iemand anders beheert mijn hardware ergens’ naar: ‘Ik heb een infrastructuur die ik op afstand kan beheren.’

Het Amerikaanse National Institute of Standards and Technology (NIST) heeft vijf essentiële kenmerken van cloud computing geïdentificeerd:9

1. On demand zelfbediening. Een consument kan eenzijdig en automatisch computercapaciteiten, zoals servertijd en netwerkopslag, toewijzen, zonder dat er menselijke interactie met een serviceprovider nodig is.

2. Brede netwerktoegang. Computerresources zijn beschikbaar via het netwerk en toegankelijk via standaardmechanismen die het gebruik door heterogene dunne of dikke klantenplatforms bevorderen.

3. Gedeeld gebruik. De computerresources van de provider worden samengevoegd om meerdere consumenten te bedienen met behulp van een multi-tenant model, waarbij verschillende fysieke en virtuele resources dynamisch worden toegewezen en opnieuw toegewezen op basis van de consumentenvraag.

4. Snelle elasticiteit. Mogelijkheden kunnen elastisch worden ingesteld en in sommige gevallen automatisch worden vrijgegeven, om snel naar buiten en naar binnen toe af te stemmen op de vraag. Voor de consument lijken de beschikbare mogelijkheden voor IT-capaciteit vaak onbeperkt en kunnen op elk gewenst moment in elke hoeveelheid worden toegewezen.

5. Meetbare service. Cloudsystemen besturen automatisch en optimaliseren het gebruik van resources door gebruik te maken van een monitoring- en meetsysteem op een abstractieniveau dat geschikt is voor het soort dienst.

Wat betekent het op afstand beheren van de infrastructuur? Denk eens terug aan een van de belangrijkste paradigma’s van UNIX-systemen: alle noodzakelijke acties met het systeem moeten toegankelijk zijn vanaf de command line (dus met behulp van een script). Grafische gebruikersinterfaces zijn mooi, maar optioneel.

Laten we nu de virtuele cloud technologieën en de command line interface combineren voor alle taken. Daardoor konden IT-professionals de onderdelen van de IT-infrastructuur creëren die ze nodig hadden, inclusief servers, opslagsystemen en netwerkcomponenten, en alle interfaces daartussen; alle instellingen en configuraties door middel van tekstcommando’s.

De mate van de automatisering is aanzienlijk toegenomen, net als de snelheid van de implementatie van de wijziging. Voorheen moest men om een IT-infrastructuur te implementeren op basis van interne hardware:

■ een begroting rechtvaardigen en overeenkomen (weken en maanden);