Het is moeilijk om de kern te vangen als we het over DevOps hebben? We hebben voor jou levendige analogieën, krachtige formuleringen en adviezen van experts verzameld die zelfs niet-specialisten helpen om tot de essentie door te dringen. Aan het einde een bonus – de eigen DevOps van medewerkers van Red Hat.
De term DevOps ontstond 10 jaar geleden en is geëvolueerd van een hashtag op Twitter tot een krachtige culturele beweging in de IT-wereld, een ware filosofie die ontwikkelaars aanmoedigt om sneller resultaten te behalen, te experimenteren en vooruitgang te boeken via iteraties. DevOps is onafgebroken verbonden geraakt met het concept van digitale transformatie. Maar zoals vaak het geval is met IT-termen, heeft DevOps in de loop van een decennium talloze definities, interpretaties en misvattingen gekregen.
Daarom hoor je vaak vragen over DevOps, zoals is het hetzelfde als agile? Of is het een specifieke methodologie? Of is het gewoon een synoniem voor samenwerking?
DevOps omvat veel verschillende concepten (continue levering, continue integratie, automatisering, enzovoort), waardoor het moeilijk kan zijn om de kern eruit te halen, vooral als je betrokken bent bij het onderwerp. Dit vermogen is echter zeer nuttig, of je nu je ideeën aan je leidinggevenden wilt overbrengen of gewoon over je werk vertelt aan familie of vrienden. Laten we daarom de terminologische nuances van DevOps voorlopig opzijzetten en ons concentreren op het algemene plaatje.
Wat is DevOps: 6 definities en analogieën
We hebben experts gevraagd om de essentie van DevOps zo eenvoudig en kort mogelijk uit te leggen, zodat de waarde ervan duidelijk wordt voor lezers met elk niveau van technische kennis. Op basis van deze gesprekken hebben we de meest levendige analogieën en krachtige formuleringen geselecteerd, die je helpen jouw verhaal over DevOps te vertellen.
1. DevOps is een culturele beweging
“DevOps is een culturele beweging waarbij beide partijen (softwareontwikkelaars en IT-systeembeheerders) erkennen dat software geen echte waarde heeft totdat iemand het begint te gebruiken: klanten, cliënten, medewerkers, wat ertoe doet – zegt Eveline Oehrlich, senior analist-onderzoeker bij het DevOps Institute. – Daarom zorgen beide partijen samen voor snelle en kwalitatieve softwarelevering.”
2. DevOps is wat ontwikkelaars empowerment geeft
«DevOps geeft ontwikkelaars de macht om applicaties te bezitten, deze te lanceren en het leveren ervan van begin tot eind te beheren»
«Gewoonlijk wordt DevOps gezien als een manier om de levering van applicaties naar productie te versnellen door geautomatiseerde processen op te zetten en toe te passen», zegt Jai Schniepp, directeur van DevOps-platforms bij verzekeringsmaatschappij Liberty Mutual. «Maar voor mij is het iets veel fundamentelers. DevOps geeft ontwikkelaars de macht om applicaties of specifieke delen van software te bezitten, deze te lanceren en het leveren ervan van begin tot eind te beheren. DevOps elimineert verwarring rond verantwoordelijkheden en leidt alle betrokkenen naar het creëren van een geautomatiseerde en door ontwikkelaars beheerde infrastructuur».
3. DevOps is samenwerking bij het creëren en leveren van applicaties
«In eenvoudige bewoordingen, DevOps is een benadering van softwareproductie en -levering waarbij iedereen samenwerkt», merkt Gur Staf op, president en hoofd van de digitale businessautomatisering bij BMC.
4. DevOps is een productieproces
«Productie in een proces is alleen mogelijk als alle onderdelen op elkaar aansluiten».
«Ik zou DevOps vergelijken met een assemblagelijn voor auto's», gaat Gur Staf verder. «Het idee is om alles van tevoren te ontwerpen en te maken zodat de onderdelen later zonder aanpassing kunnen worden samengevoegd. Productie in een proces is alleen mogelijk als alle onderdelen op elkaar aansluiten. Degenen die de motor ontwerpen en maken, moeten nadenken over hoe deze aan de carrosserie of het frame kan worden bevestigd. Degenen die de remmen maken, moeten rekening houden met de wielen, en zo verder. Evenzo moet het bij software zijn.»
Een ontwikkelaar die zakelijke logica of een gebruikersinterface maakt, moet nadenken over de database die klantgegevens opslaat, over de beveiligingsmaatregelen voor het beschermen van gebruikersgegevens, en over hoe dit allemaal zal werken wanneer de service een groot publiek bedient, mogelijk zelfs miljoenen gebruikers».
«Mensen laten samenwerken en na te denken over de delen van het werk die door anderen worden uitgevoerd, in plaats van zich alleen te concentreren op hun eigen taken – dat is het grootste obstakel dat overwonnen moet worden. Als dat lukt, krijgt u uitstekende kansen voor digitale transformatie», voegt Gur Staf toe.
5. DevOps is de juiste combinatie van mensen, processen en automatisering
Jayne Groll, uitvoerend directeur van het DevOps Institute, gaf een uitstekende analogie om DevOps uit te leggen. Volgens haar is «DevOps net als een kookrecept, waarbij drie hoofdcategorieën van ingrediënten komen kijken: mensen, processen en automatisering. Het merendeel van deze ingrediënten kan uit andere gebieden en bronnen worden gehaald: Lean, Agile, SRE, CI/CD, ITIL, leiderschap, cultuur, tools. Het geheim van DevOps, net als van elk goed recept, is hoe je de verhoudingen goed selecteert en deze ingrediënten mengt om de snelheid en effectiviteit van het creëren en uitbrengen van applicaties te verhogen».
6. DevOps is wanneer programmeurs als een Formule 1-team werken
«De race wordt niet van start naar finish gepland, maar andersom, van finish naar start».
«Als ik spreek over wat te verwachten van een DevOps-initiatief, geef ik het voorbeeld van een NASCAR- of Formule 1-raceteam», zegt Chris Short, Chief Marketing Manager van Red Hats cloudplatforms en uitgever van de nieuwsbrief DevOps’ish. «Het doel van de leider van zo’n team is om het hoogst mogelijke resultaat te behalen met de beschikbare middelen en uitdagingen waar het team mee te maken heeft. Daarbij wordt de race niet van start naar finish gepland, maar andersom, van finish naar start. Eerst wordt er een ambitieuze doelstelling gesteld, waarna de wegen naar die doelstelling worden gedefinieerd. Daarna worden deze opgedeeld in sub-taken en gedelegeerd aan teamleden».
«Gedurende de hele week voor de race perfectioneert het team de pitstop. Ze doen kracht- en cardiotraining om in vorm te zijn op de zware racedag. Ze trainen gezamenlijk om problemen op te lossen die zich tijdens de race kunnen voordoen. Evenzo moet het ontwikkelingsteam hun vaardigheden in het frequent uitbrengen van nieuwe versies trainen. Met deze vaardigheden en een goed beveiligingssysteem kunnen nieuwe versies ook sneller in productie worden gebracht. In dit wereldbeeld betekent een toename van snelheid een toename van veiligheid», zegt Short.
«Het gaat er niet om de 'juiste dingen' te doen, - voegt Short toe, - maar om zoveel mogelijk dingen te elimineren die de weg naar het gewenste resultaat blokkeren. Werk samen en pas je aan op basis van de feedback die je in real-time ontvangt. Wees voorbereid op anomalieën en werk aan kwaliteitsverbetering om hun impact op de vooruitgang naar je doel te minimaliseren. Dit is precies wat ons te wachten staat in de wereld van DevOps».
Hoe DevOps te schalen: 10 tips van experts
Gewone DevOps en massale DevOps zijn absoluut verschillende zaken. We zullen uitleggen hoe je de barrières kunt overwinnen om van het eerste naar het tweede te gaan.
Voor veel organisaties begint de weg naar DevOps gemakkelijk en plezierig. Kleine gepassioneerde teams worden gevormd, oude processen worden vervangen door nieuwe, en de eerste successen laten niet op zich wachten.
Helaas is het slechts een schijnbare glans, een illusie van vooruitgang, zoals Ben Grinnell, managing director en hoofd digitale technologie bij het adviesbureau North Highland, zegt. Vroege overwinningen zijn natuurlijk bemoedigend, maar helpen niet om het uiteindelijke doel te bereiken, namelijk grootschalig gebruik van DevOps binnen de organisatie.
Het is gemakkelijk te zien dat er daardoor een cultuur van splitsing ontstaat tussen 'wij' en 'zij'.
"Vaak starten organisaties met dit soort pioniersprojecten in de veronderstelling dat ze de weg zullen banen voor grootschalige DevOps, zonder zich af te vragen of anderen ook werkelijk deze weg willen bewandelen," legt Ben Grinnell uit. "Teams voor de uitvoering van dergelijke projecten worden meestal samengesteld uit zelfverzekerde 'buitenlanders' die iets dergelijks elders hebben gedaan, maar nieuw zijn binnen uw organisatie. Ze worden aangemoedigd om de regels te breken en af te breken die voor iedereen verplicht blijven. Het is makkelijk te zien dat er zo een cultuur van scheiding ontstaat tussen 'wij' en 'zij', wat de overdracht van kennis en vaardigheden belemmert."
„En dit culturele probleem is slechts een van de redenen waarom het moeilijk is om DevOps op te schalen. DevOps-teams worden geconfronteerd met een toename van puur technische complexiteit, kenmerkend voor snelgroeiende bedrijven die inzetten op IT-technologieën," zegt Steve Newman, oprichter en voorzitter van Scalyr.
„In de moderne wereld veranderen diensten onmiddellijk zodra de noodzaak zich aandient. Constant nieuwe functies implementeren is natuurlijk geweldig, maar het coördineren van dit proces en het oplossen van problemen is een echte hoofdpijn," voegt Steve Newman eraan toe. „In zeer snelgroeiende organisaties strijden ingenieurs in cross-functionele teams om de mogelijkheid te behouden om wijzigingen te volgen en de cascade-effecten ervan op het niveau van afhankelijkheden te begrijpen. Bovendien zijn ingenieurs absoluut niet blij wanneer ze deze mogelijkheid verliezen, wat het voor hen moeilijker maakt om de essentie van opkomende problemen te begrijpen."
Hoe overwin je de hierboven beschreven moeilijkheden en ga je over op grootschalig gebruik van DevOps binnen een groot bedrijf? Experts adviseren geduld te hebben, zelfs als uw uiteindelijke doel is om de softwareontwikkelingscyclus en bedrijfsprocessen te versnellen.
1. Vergeet niet dat veranderingen in de cultuur tijd nodig hebben
Jayne Groll, uitvoerend directeur van het DevOps Institute: Naar mijn mening moet de uitbreiding van DevOps net zo geleidelijk en iteratief zijn als agile ontwikkeling (en evenzeer de cultuur betreffen). In Agile en DevOps ligt de focus op kleine teams. Maar naarmate het aantal en de integratie van deze teams toeneemt, krijgen we steeds meer mensen die nieuwe werkmethoden toepassen, wat leidt tot een ingrijpende culturele transformatie.
2. Besteed voldoende tijd aan planning en platformkeuze
Eran Kinsbruner, hoofd technische evangelist bij Perfecto: Om schaalbaarheid te laten werken, moeten DevOps-teams in het begin leren traditionele processen, tools en vaardigheden te combineren, en vervolgens elke afzonderlijke fase van DevOps langzaam opbouwen en stabiliseren. Alles begint met zorgvuldige planning van gebruikersverhalen en waardestromen, waarna de fase van softwareontwikkeling en versiebeheer volgt met behulp van trunk-based development of andere methoden die het beste zijn voor het takken en samenvoegen van code.
Daarna volgt de fase van integratie en testen, waar al een schaalbaar platform voor automatisering vereist is. Hier is het belangrijk voor DevOps-teams om het juiste platform te kiezen dat aansluit bij hun vaardigheidsniveau en de uiteindelijke doelstellingen van het project.
De volgende fase is de implementatie in de productieomgeving, die volledig geautomatiseerd moet zijn met behulp van orkestratie- en container tools. Het is belangrijk om virtualiseerde omgevingen te hebben in alle fasen van DevOps (simulator van de productieomgeving, kwaliteitscontrole omgeving, en de productieomgeving zelf) en altijd alleen de meest recente gegevens voor tests te gebruiken om actuele inzichten te krijgen. De analyse moet intelligent zijn en in staat om big data te verwerken met snelle en effectieve feedback.
3. Verwijder de verantwoordelijkheid van schuldgevoelens
Gordon Haff, evangelist bij RedHat: «Het creëren van een systeem en een sfeer die experimenten toestaan en aanmoedigen, maakt het mogelijk om de zogenaamde succesvolle mislukkingen in agile softwareontwikkeling te realiseren. Dit betekent niet dat niemand meer verantwoordelijk is voor mislukkingen. In feite wordt het aanwijzen van een verantwoordelijke zelfs gemakkelijker, aangezien ‘verantwoordelijk zijn’ niet langer betekent ‘de schuldige zijn’. Met andere woorden, de essentie van verantwoordelijkheid verandert kwalitatief. Hierbij worden vier factoren uiterst belangrijk: de omvang van de mislukking, de benaderingen, de productieprocessen en de prikkels». (Meer over deze factoren is te lezen in het artikel van Gordon Haff ‘DevOps lessons: 4 aspects of healthy experiments’.)
4. Ruim de weg vrij
Ben Grinnell, managing director en hoofd digitale technologieën bij het adviesbureau North Highland: «Om schaling te bereiken, raad ik aan om samen met de pioniersprojecten een programma voor ‘het vrijmaken van de weg’ te lanceren. Het doel van dit programma is om het afval op te ruimen dat achterblijft bij de pioniers van DevOps, zoals verouderde regels en andere soortgelijke zaken, zodat de weg naar voren vrij blijft».
«Geef mensen organisatorische ondersteuning en geef een impuls via communicatie die ver buiten de groep van pioniers reikt, door de successen van nieuwe werkmethodes breed te vieren. Train de mensen die betrokken zijn bij de volgende golf van DevOps-projecten en die nerveus zijn omdat ze DevOps voor het eerst gebruiken. En onthoud dat deze mensen sterk verschillen van de pioniers».
5. Maak de tools toegankelijker
Steve Newman, oprichter en voorzitter van Scalyr: «Tools moeten niet verborgen zijn voor mensen en ze moeten relatief eenvoudig zijn om te leren voor iedereen die bereid is daar tijd in te investeren. Als de mogelijkheid om logs op te vragen alleen beschikbaar is voor drie mensen die ‘gecertificeerd’ zijn om met een bepaalde tool te werken, hebt u altijd maximaal drie mensen die het probleem kunnen begrijpen, zelfs als u een zeer grote computingomgeving heeft. Met andere woorden, hier ontstaat een bottleneck die ernstige (zakelijke) gevolgen kan hebben».
6. Creëer ideale omstandigheden voor teams
Tom Clark, hoofd Common Platform bij ITV: «Je hebt de vrijheid om alles te doen, maar niet alles tegelijk. Stel daarom grote doelen, begin klein en ga vooruit met snelle iteraties. Na verloop van tijd bouw je een reputatie op als team dat het goed doet, zodat anderen ook willen gebruikmaken van jouw methoden. En jaag niet op het creëren van een hooggepresteerd team. Zorg in plaats daarvan voor ideale werkomstandigheden en de effectiviteit komt vanzelf».
7. Vergeet de wet van Conway en kanban-borden niet
Logan Daigle, directeur softwarelevering en DevOps-strategie bij CollabNetVersionOne: «Het is belangrijk om de gevolgen van de wet van Conway te begrijpen. In mijn vrije vertaling zegt deze wet dat de producten die we creëren en de processen die we gebruiken, inclusief DevOps, op dezelfde manier zijn ingericht als onze organisatie».
«Als een organisatie hoog fragmentarisch is en het management tijdens het plannen, creëren en uitbrengen van software meerdere keren van handen verandert, zal het effect van opschaling nul of van korte duur zijn. Maar als de organisatie cross-functionele teams vormt rond producten die met een marktgerichte financiering zijn opgezet, dan groeit de kans op succes aanzienlijk».
«Een ander belangrijk aspect van opschalen is om alle werkprocessen (WIP, work in progress) op kanban-borden weer te geven. Wanneer er in een organisatie een plek is waar mensen dit kunnen zien, stimuleert dat de samenwerking enorm, wat een positieve invloed heeft op het opschalen».
8. Zoek naar oude littekens
Manuel Pais, DevOps-consultant en co-auteur van het boek 'Team Topologies': «Het toepassen van DevOps-praktijken buiten de daadwerkelijke Dev en Ops en proberen deze toe te passen op andere functies kan zeker niet de optimale benadering worden genoemd. Dit zal zeker enige effecten hebben (bijvoorbeeld door handmatige controle te automatiseren), maar je kunt veel meer bereiken door te beginnen met het begrijpen van de leveringsprocessen en feedback».
Als er in het IT-systeem van een organisatie oude littekens zijn – procedures en beheersmechanismen die zijn ingevoerd naar aanleiding van eerdere incidenten, maar die hun relevantie hebben verloren (door veranderingen in producten, technologie of processen) – dan moeten deze zonder twijfel worden verwijderd of gladgestreken, en mogen geen ineffectieve of overbodige processen geautomatiseerd worden.
9. Creëer geen varianten van DevOps
Antony Edwards, directeur productie bij Eggplant: „DevOps is een zeer vage term, waardoor elk team zijn eigen variant van DevOps heeft. Niets is erger dan wanneer er binnen een organisatie 20 verschillende variaties van DevOps ontstaan die niet goed samenwerken. Het is niet acceptabel dat elk van de drie ontwikkelteams zijn eigen unieke interface heeft tussen ontwikkeling en productbeheer. Evenmin mogen producten hun eigen unieke verwachtingen hebben wat betreft feedbackverwerking bij de overgang naar een gesimuleerde productieomgeving. Anders zul je DevOps nooit kunnen opschalen.”
10. Predik de waarde van DevOps voor het bedrijfsleven
Steve Newman, oprichter en voorzitter van Scalyr: „Werk aan het erkennen van de waarde van DevOps. Leer en schaam je niet om te vertellen over de voordelen van wat je doet. DevOps bespaart ongelooflijk veel tijd en geld (denk maar eens: minder uitvaltijd, kortere gemiddelde herstelperiode), en DevOps-teams moeten onvermoeibaar de belangrijkheid van deze initiatieven voor het succes van het bedrijf benadrukken (en prediken). Zo kun je je kring van aanhangers uitbreiden en de invloed van DevOps binnen de organisatie versterken.”
BONUS
Op Op 13 september komt onze eigen DevOps – ja, bij Red Hat, als softwareproducent, hebben we onze eigen DevOps-teams en praktijken.
Onze engineer Mark Birger, die interne automatiseringsdiensten ontwikkelt voor andere teams in de hele organisatie, vertelt in gewoon Nederlands zijn eigen verhaal – hoe het DevOps-team van Red Hat applicaties migreerde van virtuele omgevingen beheerd door Ansible naar een volledig containerformaat op het OpenShift-platform.
Maar dat is nog niet alles:
Nadat organisaties hun werkbelastingen naar containers hebben overgebracht, functioneren traditionele methoden voor applicatiemonitoring mogelijk niet meer. In dit tweede rapport zullen we onze motivatie voor het veranderen van onze registratiemethoden uitleggen en de voortgang tonen die ons naar moderne technieken voor logging en monitoring heeft geleid.
Bron: habr.com
