DevOps - Sample
My Account List Orders

DevOps

Inhoudsopgave

  • Inleiding
  • Hoofdstuk 1: Wat is DevOps? De kernfilosofie begrijpen
  • Hoofdstuk 2: Belangrijkste principes van DevOps: CALMS-framework
  • Hoofdstuk 3: Traditionele SDLC vs. Agile vs. DevOps
  • Hoofdstuk 4: Essentiële versiebeheer: Aan de slag met Git
  • Hoofdstuk 5: Continuous Integration (CI): Builds automatiseren
  • Hoofdstuk 6: Populaire CI-tools: Een overzicht (bijv. Jenkins, GitLab CI, GitHub Actions)
  • Hoofdstuk 7: De rol van geautomatiseerde tests in CI/CD
  • Hoofdstuk 8: Continuous Delivery (CD): Software betrouwbaar releasen
  • Hoofdstuk 9: Continuous Deployment: De volgende stap in automatisering
  • Hoofdstuk 10: Infrastructure as Code (IaC): Omgevingen programmatisch beheren
  • Hoofdstuk 11: Inleiding tot configuratiebeheertools (bijv. Ansible, Puppet, Chef)
  • Hoofdstuk 12: Containers begrijpen: Docker voor beginners
  • Hoofdstuk 13: Inleiding tot container-orchestratie: Kubernetes-fundamenten
  • Hoofdstuk 14: Monitoring en logging: Inzicht in uw systemen
  • Hoofdstuk 15: Belangrijkste monitoring-tools en -praktijken
  • Hoofdstuk 16: Het belang van feedbacklussen in DevOps
  • Hoofdstuk 17: Cloudcomputing en DevOps: Cloudplatformen benutten
  • Hoofdstuk 18: DevSecOps: Beveiliging integreren in de DevOps-levenscyclus
  • Hoofdstuk 19: Een DevOps-cultuur opbouwen: Samenwerking en communicatie
  • Hoofdstuk 20: Microservices begrijpen in een DevOps-context
  • Hoofdstuk 21: Value Stream Mapping: Uw leveringspijplijn optimaliseren
  • Hoofdstuk 22: DevOps-succes meten: Belangrijkste metrics en KPI's
  • Hoofdstuk 23: Veelvoorkomende DevOps-anti-patronen en hoe ze te vermijden
  • Hoofdstuk 24: Uw eerste eenvoudige DevOps-project: Een stapsgewijze handleiding
  • Hoofdstuk 25: De toekomst van DevOps en continuous learning

Inleiding

Welkom in de wereld van DevOps! Als u dit boek heeft opgepakt, bent u waarschijnlijk benieuwd naar wat dit "DevOps" precies inhoudt, of misschien heeft u de term rondhangen horen en wilt u de praktische implicaties begrijpen. U bent misschien een softwareontwikkelaar die zat is van de metaforische muur tussen uw team en de operations-collega's, een operations-engineer gefrustreerd door laatst-momenten code-"bommen", of een zakelijk leider die zich afvraagt hoe nieuwe functies en producten sneller en betrouwbaarder bij klanten te krijgen. Wat uw uitgangspunt ook is, u bent op de juiste plek.

Dit boek, "DevOps: Een gids voor beginners," is ontworpen om DevOps te demystificeren, door de kernconcepten, principes en praktijken op te breken in verteerbare stukjes. We verkennen hoe DevOps erop gericht is de historische kloof te overbruggen tussen hen die software bouwen (Development) en hen die het draaiende houden (Operations). Het is een reis in een culturele en professionele beweging die nadruk legt op samenwerking, automatisering en continue verbetering.

In het niet-verre verleden, en in sommige organisaties nog steeds vandaag de dag, was de softwareontwikkelcyclus vaak een gefragmenteerd en inefficiënt proces. Ontwikkelaars schreven code en "gooiden het dan over de muur" naar het operations-team voor implementatie en beheer. Dit leidde vaak tot een schuldspel wanneer dingen misgingen, waarbij ontwikkelaars de infrastructuur wijzen en operations-teams weer wijzen naar foutieve code. Deze silobenadering creëerde significante wrijving, vertraagde releases en beïnvloedde uiteindelijk de capaciteit van het bedrijf om te reageren op marktveranderingen en klantbehoeften.

Denk aan enkele van de veelvoorkomende frustraties in traditionele softwareontwikkeling. Herinner u die marathon-weekendreleasecycli, vol angst en noodrollbacks? Of de oneindige heen-en-weer tussen development en operations om een productieprobleem te diagnosticeren? Misschien heeft u de pijn van het "het werkt op mijn machine"-syndroom ervaren, waarbij code die perfect functioneert in de geïsoleerde omgeving van een ontwikkelaar, instort in de productieomgeving. Dit zijn geen geïsoleerde incidenten; ze zijn symptomen van een systeemprobleem dat DevOps probeert op te lossen.

De kosten van deze inefficiënten worden niet alleen gemeten in verspilde tijd en gefrustreerde ingenieurs. Slechte softwareontwikkelpraktijken kunnen leiden tot verhoogde ontwikkel- en onderhoudskosten, aangezien teams meer tijd besteden aan het oplossen van problemen dan aan het bouwen van nieuwe waarde. Vertraagde projecten kunnen resulteren in gemiste marktkansen, waarmee concurrenten vooruit komen. Beveiligingskwetsbaarheden, vaak over het hoofd gezien in overhaaste of slecht gecoördineerde processen, kunnen leiden tot catastrofale inbraken, die de reputatie en het resultaat van een bedrijf schaden. Feitelijk hebben studies aangetoond dat ineffectieve softwarelevering bedrijven miljoenen, zelfs honderden miljoenen, dollars per jaar kan kosten.

De realiteit is dat in de huidige digital-first wereld, software het hart is van bijna elk bedrijf. Het vermogen om snel en betrouwbaar software van hoge kwaliteit te leveren is geen luxe meer, maar een fundamentele vereiste voor competitiviteit en groei. Klanten verwachten frequente updates, nieuwe functies en een naadloze gebruikerservaring. Bedrijven moeten agile zijn, in staat om snel te schakelen als reactie op veranderende marktvraag en klantfeedback. Hier stapt DevOps in, door een pad te bieden om softwarelevering te transformeren van een knelpunt naar een strategisch voordeel.

Wat is deze transformatieve benadering dan precies? In zijn kern is DevOps een culturele filosofie. Het is meer dan alleen een set tools of een specifieke functietitel; het is een verandering in mindset die samenwerking, communicatie en gedeelde verantwoordelijkheid bevordert over de gehele softwareleveringcyclus. Het gaat om het afbreken van de traditionele silos tussen development, operations, quality assurance (QA), en zelfs security-teams, hen aanmoedigend om samen te werken naar gemeenschappelijke doelen.

Deze culturele shift wordt ondersteund door een set sleutelprincipes en praktijken. U zult veel horen over automatisering in de context van DevOps, en niet zonder reden. Het automatiseren van herhalende taken zoals bouwen, testen en deployen van software vrijmaakt waardevolle menselijke tijd, verlaagt het risico op handmatige fouten en versnelt de hele leveringspijplijn. Concepten zoals Continuous Integration (CI) en Continuous Delivery/Deployment (CD) zijn hier centraal in, waarmee teams software sneller en betrouwbaarder kunnen releasen.

Maar DevOps gaat niet alleen om snelheid; het gaat ook om kwaliteit en stabiliteit. Door testen te integreren door het hele ontwikkelproces en robuuste monitoring- en feedbackmechanismen te implementeren, helpt DevOps teams om issues eerder te vangen, risico's te verminderen, en te waarborgen dat de geleverde software niet alleen snel is, maar ook betrouwbaar en veilig.

Door dit hele boek zullen we deze concepten in detail uiteenzetten. We beginnen met het formeel definiëren van DevOps en het verkennen van de kernfilosofie. We duiken dan in de sleutelprincipes, vaak samengevat door het CALMS-framework (Culture, Automation, Lean, Measurement, Sharing). We zullen traditionele softwareontwikkelcycli vergelijken met Agile-methodologieën en zien hoe DevOps op deze ideeën voortbouwt en ze uitbreidt.

Een significant deel van het boek zal gewijd zijn aan de praktische tools en technieken die DevOps mogelijk maken. We zullen essentiële versiebeheer met Git behandelen, een hoeksteen voor collaboratieve ontwikkeling. We zullen Continuous Integration verkennen en de populaire tools die het faciliteren, zoals Jenkins, GitLab CI en GitHub Actions. We zullen de cruciale rol van geautomatiseerd testen bespreken in het waarborgen van kwaliteit binnen CI/CD-pijplijnen.

Vanaf daar gaan we over naar Continuous Delivery en Continuous Deployment, begrijpend hoe software betrouwbaar te releasen en in sommige gevallen volledig automatisch. We zullen Infrastructure as Code (IaC) introduceren, een revolutionaire benadering voor het beheren en provisioneren van infrastructuur met behulp van code, en kijken naar populaire configuratiebeheertools zoals Ansible, Puppet en Chef.

Containers, met name Docker, zijn een onmisbaar onderdeel geworden van moderne software-implementatie, dus we zullen een beginnersvriendelijke introductie tot containerisatie en de voordelen ervan bieden. We zullen ook containerorchestratie met Kubernetes aanraken, een krachtig platform voor het beheren van gecontaineriseerde applicaties op schaal.

Geen DevOps-reis is compleet zonder focus op zichtbaarheid. We zullen monitoring en logging verkennen, essentiële praktijken voor het begrijpen hoe uw systemen presteren en voor het snel diagnosticeren en oplossen van problemen. We zullen ook kijken naar sleutelmonitoringtools en best practices. Het belang van feedback loops, een terugkerend thema in DevOps, zal benadrukt worden, aantoonend hoe ze continue verbetering drijven.

We zullen onderzoeken hoe cloud computing platforms krachtige enablers zijn geworden van DevOps-praktijken, schaalbaarheid en managed services biedend die veel aspecten van softwarelevering en operations vereenvoudigen. Beveiliging is een ander kritisch aspect, en we zullen DevSecOps bespreken – de praktijk van het integreren van beveilgingsoverwegingen door de gehele DevOps-lifecycle, in plaats van het te behandelen als een nadenkje.

Naast de tools en processen, bouwt een succesvolle DevOps-omgeving zwaar op het bevorderen van de juiste cultuur. We zullen een hoofdstuk wijden aan het bouwen van een DevOps-cultuur, met nadruk op het belang van samenwerking, communicatie, vertrouwen en gedeelde verantwoordelijkheid. We zullen ook architectuurpatronen als microservices aanraken en hoe ze passen in een DevOps-context, evenals technieken zoals Value Stream Mapping voor het identificeren en elimineren van knelpunten in uw leveringspijplijn.

Om ervoor te zorgen dat u op het juiste spoor bent, zullen we bespreken hoe DevOps-succes te meten met behulp van sleutelmetrieken en Key Performance Indicators (KPI's). We zullen ook veelvoorkomende valkuilen en anti-patronen behandelen om u te helpen ze te vermijden op uw DevOps-reis.

Ten slotte, om alles samen te brengen, zullen we u doorlopen door een simpel, stapsgewijs DevOps-project, waardoor u deze principes en praktijken in actie ziet. En omdat de wereld van technologie zich constant verder ontwikkelt, zullen we afsluiten met een kijk op de toekomst van DevOps en het belang van continuous learning.

Dit boek vergt geen voorafgaande diepe technische expertise in alle behandelde gebieden, hoewel een basiskennis van softwareontwikkelconcepten behulpzaam zal zijn. Ons doel is om u een stevige basis te bieden, u uitgerust met de kennis en het vertrouwen om DevOps-principes toe te passen in uw eigen context, of u nu deel uitmaakt van een kleine startup of een groot bedrijf.

De overgang naar DevOps is een reis, geen bestemming. Het vereist geduld, volharding en de bereidheid om verandering te omarmen. Er zullen uitdagingen op uw pad komen, zoals het overwinnen van weerstand tegen nieuwe manieren van werken of het navigeren door de complexiteiten van nieuwe tools. Toch wegen de voordelen – snellere levering, verbeterde kwaliteit, verhoogde efficiëntie, verbeterde samenwerking, en uiteindelijk grotere zakelijke waarde – de moeite zeker.

Dus, span de riemen op en maak u klaar om te verkennen hoe DevOps de manier kan transformeren waarop u en uw organisatie software bouwt en levert. Laten we samen beginnen met deze spannende reis!


HOOFDSTUK EEN: Wat is DevOps? De kernfilosofie begrijpen

Welkom bij het eerste hoofdstuk van uw reis om DevOps te begrijpen. De term zelf is in de tech-wereld alomtegenwoordig, vaak losgeslingerd in vacatures, bedrijfsmissies en softwareontwikkelconferenties. Maar onder de hype, wat betekent "DevOps" eigenlijk? Is het een functietitel, een specifiek team, een verzameling softwaretools, of iets dieperliggends? In dit hoofdstuk schillen we de lagen af en verkennen we de fundamentele filosofie die deze transformatieve benadering van softwareontwikkeling en IT-operations ten grondslag ligt.

De term "DevOps" is een portaalwoord, een linguïstische samenvoeging van "Development" (Ontwikkeling) en "Operations" (Operaties). Deze simpele combinatie geeft al een hint naar het kernidee: het bijeenbrengen van deze twee historisch gescheiden, en vaak conflicterende, werelden. Traditioneel waren ontwikkelteams gefocust op het bouwen van nieuwe functionaliteiten en het uitbrengen ervan, terwijl operationele teams belast waren met het waarborgen van de stabiliteit en betrouwbaarheid van productiesystemen. Dit creëerde vaak een natuurlijke spanning, een "muur van verwarring" waar code metaforisch over de muur werd gegooid van de ene kant naar de andere, wat leidde tot misverstanden, vertragingen en frustratie.

DevOps ontstond als antwoord op deze uitdagingen. Het is niet iets wat u kopen of installeren kunt; het vertegenwoordigt eerder een culturele en professionele beweging die benadrukt op samenwerking, communicatie en integratie tussen softwareontwikkelaars en IT-operationsprofessionals. Het primaire doel is het automatiseren en stroomlijnen van de processen die betrokken zijn bij het bouwen, testen en releasen van software, waardoor organisaties sneller en betrouwbaarder waarde kunnen leveren aan hun gebruikers. Het probeert de traditionele silos af te breken, waarbij een gedeeld gevoel van eigenaarschap en verantwoordelijkheid wordt bevorderd gedurende de gehele softwareleveringscyclus.

Een van de eerste dingen om te begrijpen is dat DevOps geen rigide, één-maat-past-alle-methodologie is met een strikte set regels. Het is eerder een filosofie of een benadering die organisaties aanpassen aan hun specifieke context en behoeften. Verschillende bedrijven kunnen DevOps op iets verschillende manieren implementeren, gefocust op specifieke praktijken of tools die het beste passen bij hun omgeving. De onderliggende principes van samenwerking, automatisering en continue verbetering blijven echter consistent.

U hoort misschien mensen DevOps omschrijven als "Agile systeembeheer" of "Agile toegepast op operations". Hoewel er sterke verbanden zijn met Agile-methodologieën, met name wat betreft iteratieve ontwikkeling, continue feedback en aanpasbaarheid, breidt DevOps deze principes uit verder dan alleen het ontwikkelteam. Het streeft ernaar een naadloze stroom te creëren van ideeënvorming tot productiedeployment en actief onderhoud, met betrokkenheid van iedereen die betrokken is bij de levenscyclus van het product.

De oorsprong van DevOps kan teruggevolgd worden tot het midden/tot einde van de jaren 2000, een periode waarin verschillende industrietrends en ideeën begonnen te convergeren. Agile-softwareontwikkelpraktijken kregen wijdverspreide adoptie, wat de voordelen van snelle iteratie en responsiviteit op verandering benadrukte. Tegelijkertijd worstelden IT-operationalteams met de toenemende complexiteit en schaal van webgebaseerde applicaties en infrastructuur. Visionairs zoals Patrick Debois, die de term "DevOps" in 2009 bedacht, en anderen begonnen te pleiten voor een meer geïntegreerde benadering.

De pijnpunten werden in veel organisaties steeds duidelijker. Lange en infrequente releasecycli betekenden dat nieuwe functies en bugfixes te lang durenden voordat ze de gebruikers bereikten. Deployments waren vaak hoogrisico, handmatige en foutgevoelige gebeurtenissen, die soms aanzienlijke downtime vereisten. De kloof tussen development en operations leidde tot een "blame game" telkens er problemen ontstaan, waarbij beide kanten de schuld aan de ander toekenden. Deze omgeving was niet bevorderlijk voor innovatie of snelle reactie op marktvraag.

Overweeg het al te veelvoorkomende scenario waarbij software perfect werkte op de laptop van een ontwikkelaar, maar spektakulair faalde in de productieomgeving. Dit "het werkt op mijn machine"-syndroom was een klassiek symptom van de kloof tussen development en operations, waar verschillen in omgevingen, configuraties en aannames tot significante problemen konden leiden. DevOps streeft ernaar dergelijke discrepanties te elimineren door consistentie en samenwerking te bevorderen vanaf de vroegste stadia van de ontwikkeling.

Daarom is DevOps in zijn hart een culturele shift. Het gaat om het veranderen van mindsets en het creëren van een omgeving waarin development- en operationele teams zichzelf zien als onderdeel van een enkele, cohesieve eenheid die werkt naar gedeelde doelen. Dit vereist het opbouwen van vertrouwen, het aanmoedigen van open communicatie en het promoten van empathie tussen teamleden. Het gaat om het begrijpen van elkaars uitdagingen en samenwerken om ze te overwinnen.

Het is cruciaal om DevOps te differentiëren van simpelweg een nieuwe naam voor een operations-engineer die scripts kan schrijven, of een ontwikkelaar die zijn eigen code kan deployen. Hoewel vaardigheden in automatisering en breder begrip waardevol zijn, creëert een "DevOps engineer"-titel niet magisch een DevOps-cultuur. De cultuurverandering is van het grootste belang; zonder het heb je wellicht individuen met nieuwe vaardigheden, maar die nog steeds opereren binnen de oude, gesiloode structuren.

Deze culturele transformatie richt zich op gedeelde verantwoordelijkheid. In plaats van dat ontwikkelaars hun werk gedaan achten zodra de code geschreven is, en operations het daarvandaan oppakt, moedigt DevOps een "you build it, you run it"-mentaliteit aan, of ten minste een "you build it, you help run it"-benadering. Dit betekent dat ontwikkelaars een beter begrip krijgen van de operationele implicaties van hun code, en operationele teams vroeger in de ontwikkelcyclus betrokken raken om feedback te geven over deploybaarheid en beheerbaarheid.

Denk er aan als een sportteam. Voor het team om te slagen, moet elke speler zijn rol begrijpen, effectief communiceren met anderen en werken naar het gemeenschappelijke doel van het winnen van de wedstrijd. Als aanval en verdediging niet coördineren of, erger nog, elkaar de schuld geven bij mislukkingen, is het onwaarschijnlijk dat het team goed presteert. DevOps brengt dezezelfde collaboratieve, teamgerichte geest naar softwarelevering.

Deze filosofie heeft direct impact op hoe teams gestructureerd zijn en hoe ze interacteren. In plaats van grote, geïsoleerde afdelingen, ziet u misschien kleinere, cross-functionele teams die ontwikkelaars, operations-medewerkers, QA-engineers, en soms zelfs beveilingsspecialisten en business-stakeholders omvatten. Deze teams worden geempowerd om de volledige levenscyclus van een service of applicatie te eigen maken, van ontwerp en ontwikkeling tot deployment en actief beheer.

De nadruk op het afbreken van silos gaat niet alleen over Development en Operations. Echt DevOps-denken strekt zich uit tot Quality Assurance (QA), beveiliging (wat leidt tot het concept van DevSecOps, wat we later zullen verkennen), en zelfs het bedrijf zelf. Wanneer iedereen die betrokken is bij het leveren en ondersteunen van software afgestemd is en effectief communiceert, wordt het hele proces efficiënter en responsiever.

Samenwerking en communicatie zijn het levensbloed van deze filosofie. Reguliere vergaderingen, gedeelde communicatiekanalen (zoals chatplatformen) en collaboratieve tools zijn belangrijk, maar nog belangrijker is de bereidheid om te luisteren naar verschillende perspectiefen en constructief te werken aan oplossingen. Het gaat om het afstand nemen van een cultuur van "wij tegen zij" naar een van "wij".

Empathie speelt een verrassend significante rol in de DevOps-filosofie. Wanneer ontwikkelaars de druk en uitdagingen begrijpen waarmee operations-teams te maken hebben (zoals het handhaven van uptime en het afhandelen van productie-incidenten), bouwen ze waarschijnlijker software die gemakkelijker te deployen en beheren is. Omgekeerd, wanneer operations-teams de behoefte van de ontwikkelaar waarderen om te innoveren en snel functies te releasen, zullen ze waarschijnlijker samenwerken aan oplossingen die snelheid mogelijk maken zonder in te boeten op stabiliteit.

Waarom dan deze filosofie adopteren? Wat zijn de tastbare voordelen die organisaties drijven om DevOps te omarmen? Een van de meest aangehaalde voordelen is verhoogde snelheid en agiliteit. Door processen te stroomlijnen en herhalende taken te automatiseren, stelt DevOps teams in staat om software vaker en met kortere doorlooptijden te releasen. Dit betekent dat bedrijven nieuwe functies en verbeteringen sneller op de markt kunnen brengen, sneller reageren op klantfeedback en competitieve druk.

DevOps gaat echter niet alleen om snel gaan; het gaat om veilig snel gaan. Verbeterde kwaliteit en betrouwbaarheid zijn ook kernresultaten. Door testen te integreren door de gehele ontwikkelcyclus (een praktijk bekend als Continuous Testing) en robuuste monitoring- en feedbackmechanismen te implementeren, kunnen teams problemen eerder identificeren en oplossen, wat de kans vermindert dat bugs de productie bereiken. Geautomatiseerde deploymentprocessen minimaliseren ook het risico op menselijke fouten tijdens releases.

Verhoogde efficiëntie en verminderde verspilling zijn verdere voordelen. Automatisering elimineert handmatige plakwerk, wat ingenieurs vrijmaakt om zich te richten op hogere-waarde activiteiten. Door samenwerking te verbeteren en herwerk te verminderen, helpt DevOps om verspilde inspanning te minimaliseren. Dit kan leiden tot lagere operationele kosten en verbeterde productiviteit over de hele lijn.

Uiteindelijk streeft de DevOps-filosofie ernaar softwarelevering nauwer af te stemmen op de zakelijke doelen. Wanneer IT functies sneller, betrouwbaarder en met hogere kwaliteit kan leveren, is het bedrijf beter gepositioneerd om te innoveren, klanten tevreden te stellen en haar strategische doelen te bereiken. Softwareontwikkeling en IT-operaties transformeren van kostenposten naar waardedrijvers voor de organisatie.

Een ander, vaak over het hoofd gezien voordeel is verbeterde teammorale en betrokkenheid. Werken in een collaboratieve, hoge-vertrouwensomgeving waar bijdragen gewaardeerd worden en er een gedeeld doel is, kan veel meer voldoening geven dan opereren in een gesiloode, schuldgerichte cultuur. Het verminderen van de stress geassocieerd met hoogrisico-deployments en brandblussen draagt ook bij aan een gezonder en duurzamere werkomgeving.

Het is belangrijk te erkennen dat het adopteren van DevOps een reis is, geen bestemming. Er is geen magische schakelaar die u kunt omleggen om een "DevOps-organisatie" te worden. Het vereist toewijding aan continue verbetering, de bereidheid te experimenteren en te leren van fouten, en lopende inspanning om de gewenste cultuur te voeden. Het is een evolutionair proces.

U vraagt u misschien af hoe DevOps zich verhoudt tot Agile-methodologieën, die veel ontwikkelteams al praktiseren. Agile richt zich op iteratieve ontwikkeling, klantsamenwerking en reageren op verandering, primair binnen de scope van het ontwikkelteam. DevOps neemt deze principes en breidt ze uit over de gehele serviceleveringscyclus, inclusief operations. Het probeert de knelpunten weg te nemen die vaak optreden nadat het Agile-ontwikkelproces voltooid is, met name rond deployment en release.

Zie Agile als het optimaliseren van het "Dev"-gedeelte van de vergelijking. DevOps kijkt dan naar het grotere plaatje, het optimaliseren van de stroom helemaal door "Ops" heen en weer terug via feedback loops. De twee zijn hoogst complementair en werken vaak het beste wanneer ze samen geïmplementeerd worden. DevOps biedt de mechanismen om ervoor te zorgen dat de snel ontwikkelde software van Agile-teams net zo snel en betrouwbaar aan gebruikers geleverd kan worden.

De filosofie van DevOps stelt dus de basis voor alle praktijken, tools en technieken die we in de volgende hoofdstukken van dit boek zullen verkennen. Deze kernfilosofie begrijpen – de nadruk op cultuur, samenwerking, gedeelde verantwoordelijkheid en continue verbetering – is essentieel voordat we duiken in de specificaties van versiebeheer, continuous integration, infrastructure as code, of containerisatie. Deze tools en praktijken zijn enablers van de filosofie, geen substituten voor het.

Zonder een echte toewijding aan de onderliggende culturele shift is het simpelweg adopteren van een paar DevOps-tools onwaarschijnlijk om de gewenste resultaten op te leveren. U kunt wellicht eilanden van automatisering bereiken, maar u ontgrendelt niet het transformerende potentieel van echte DevOps. Het is de combinatie van culturele verandering, procesverbetering en geschikte tooling die tot succes leidt.

Overweeg bijvoorbeeld de praktijk van Continuous Integration (CI), die we later in detail zullen behandelen. CI omvat dat ontwikkelaars hun codewijzigingen frequent samenvoegen in een centrale repository, waarna geautomatiseerde builds en tests draaien. De tools voor CI zijn gemakkelijk beschikbaar. Echter, voor CI effectief te zijn, vereist het een filosofische toewijding van ontwikkelaars om vroeg en vaak te integreren, geautomatiseerde tests te schrijven, en gebroken builds prompt aan te pakken. Dit is waar de filosofie de praktijk ontmoet.

Op dezelfde manier is Infrastructure as Code (IaC) een krachtige praktijk voor het beheren en provisioneren van infrastructuur via machine-leesbare definitiebestanden. De tools bestaan, maar het succesvol implementeren van IaC vereist dat operations-teams ontwikkelaars-praktijken omarmen (zoals versiebeheer en testen voor infrastructuurcode) en dat ontwikkelaars en operations samenwerken aan het definiëren van infrastructuureisen.

De kernfilosofie van DevOps moedigt ook een data-gedreven benadering van verbetering aan. Door sleutelmetrieken met betrekking tot de softwareleveringspijplijn te meten (zoals deploymentfrequentie, doorlooptijd voor wijzigingen, wijzigingsmislukkingsratio, en gemiddelde hersteltijd), kunnen teams knelpunten identificeren, voortgang bijhouden, en geïnformeerde beslissingen nemen over waar ze hun verbeterinspanningen op moeten richten. Dit past bij het bredere thema van continue leren en aanpassen.

Een veelvoorkomend misverstand is dat DevOps betekent dat het operationele team afgeschaft wordt of dat ontwikkelaars nu al het operationele werk moeten doen. Dit is zelden het geval. Hoewel rollen kunnen evolueren en vaardigheden zich kunnen verbreeden, blijft de expertise van operations-professionals cruciaal. Wat verandert is hoe deze teams samenwerken. Operations-expertise wordt eerder in de cyclus ingesloten, en ontwikkelaars worden meer bewust van en betrokken bij de operationele aspecten van hun applicaties.

Het idee is om een symbiotische relatie te creëren. Ontwikkelaars profiteren van de operationele expertise die ervoor zorgt dat hun applicaties soepel en betrouwbaar in productie draaien. Operations-teams profiteren van applicaties die met operabiliteit in gedachten zijn ontworpen, wat ze makkelijker te deployen, beheren en monitoren maakt. Deze wederzijdse winst is een sleuteldriver van de collaboratieve geest.

Een ander aspect van de kernfilosofie is het omarmen van falen, of nauwkeuriger, het behandelen van fouten als kansen om te leren en te verbeteren. In complexe systemen zijn fouten onvermijdelijk. In plaats van te zoeken naar wie de schuld is, moedigt een DevOps-cultuur een "blameless post-mortem"-benadering aan, waarbij de focus ligt op het begrijpen van de hoofdoorzaken van een incident en het implementeren van veranderingen om herhaling te voorkomen. Dit bevordert psychologische veiligheid, wat mensen aanmoedigt te experimenteren en te innoveren zonder vreze voor repriezen als dingen misgaan.

Deze benadering sluit aan bij het idee van het bouwen van veerkrachtige systemen. Door fouten te verwachten en systemen te ontwerpen die ze netjes kunnen afvangen (of snel ervan kunnen herstellen), kunnen organisaties de impact van incidenten minimaliseren. Praktijken zoals geautomatiseerd testen, geleidelijke rollouts (bijv. canary releases of blue-green deployments), en robuuste monitoring dragen allemaal bij aan deze veerkracht, en ze zijn allemaal uitingen van de onderliggende DevOps-filosofie.

De shift naar kleinere, vaker releases is een direct gevolg van deze filosofie. Grote, infrequente releases zijn inherent riskant. Ze bundelen veel wijzigingen, wat het moeilijk maakt de oorzaak van eventuele problemen te identificeren. Kleine, frequente releases reduceren de scope van verandering, maken deployments minder riskant en troubleshooting makkelijker. Als een probleem zich voordoet, is het eenvoudiger de oorzaak te achterhalen en een kleine wijziging terug te draaien indien nodig.

Deze capaciteit om kleine wijzigingen snel en betrouwbaar te releasen verbetert niet alleen de stabiliteit, maar versnelt ook de feedbackloop van gebruikers. Bedrijven kunnen nieuwe ideeën en functies sneller in handen van klanten krijgen, feedback verzameln, en sneller itereren. Deze agiliteit is een significant competitief voordeel in het huidige snelle digitale landschap.

De DevOps-filosofie bevordert ook een holistisch beeld van het systeem. In plaats van dat individuele teams hun eigen kleine puzzelstukje in isolatie optimaliseren, moedigt DevOps iedereen aan te denken over de end-to-end waardestroom – van het initiële zakelijke idee tot de levering van waarde aan de klant en het actieve beheer van de service. Deze systemische denkwijze helpt knelpunten te identificeren en elimineren die kunnen optreden bij de overdrachtspunten tussen verschillende teams of fasen.

Uiteindelijk gaat de kernfilosofie van DevOps over het maken van softwarelevering menselijker en duurzamer. Het streeft ernaar de stress, burnout en frustratie te verminderen die vaak geassocieerd worden met traditionele, gesiloode benaderingen. Door samenwerking te bevorderen, plakwerk te automatiseren, en teams in staat te stellen om waarde effectiever te leveren, kan DevOps leiden tot gelukkigere, meer betrokken ingenieurs en een positiefere werkomgeving.

Terwijl u door dit boek voortgaat, houd deze fundamentele ideeën in gedachten. Wanneer we specifieke tools of praktijken bespreken, onthoud dan dat ze allemaal in dienst zijn van deze overkoepelende filosofie. Het "hoe" van DevOps (de tools en technieken) is belangrijk, maar het "waarom" (de culturele en filosofische onderbouwing) is wat duurzame transformatie echt drijft. Deze kern begrijpen stelt u in staat om kijken voorbij de hype en de diepgaande impact van DevOps te waarderen op individuen, teams en gehele organisaties.


This is a sample preview. The complete book contains 27 sections.