Het grootste probleem met DevOps is de naam

Oleg Skrynnik, Managing partner at Cleverics; EXIN DevOps Master, ITIL Expert 

Vertaling: Theo Wanders

 

Wikipedia begint met de stelling dat DevOps een geclipte verbinding is van “development” en “operations”. Dit betekent dat het een methodologie is die softwareontwikkeling (Dev) combineert met IT-operations (Ops) ofwel het dagelijks beheer. Als we de formulering en de spelling beschouwen is dit natuurlijk correct. Niemand zal beweren dat de eerste drie letters van elk van de twee woorden werden gebruikt om de term te creëren:

Helaas is dat niet genoeg om uit te leggen wat DevOps werkelijk is en hoe je het meeste er uit kunt halen. DevOps wordt als gevolg van deze term nogal vaak verkeerd begrepen. Ik zal de drie meningen over DevOps uitleggen die ik ben tegengekomen.

 

De eerste is een zeer vereenvoudigde weergave

Laten we even nadenken over Agile. Het is een bekend feit dat Agile software ontwikkelingsmethodieken gericht zijn op het oplossen van belangrijke en moeilijke kwesties die gepaard gaan met communicatie, interactie en contractuele overeenkomsten tussen twee partijen (de klant van softwareontwikkeling en de softwareontwikkelaars). Het leven zou veel eenvoudiger zijn als het mogelijk zou zijn om een vaste scope, financiering en pakket van eisen te hebben om een intern of extern IT-systeem te (laten) ontwikkelen. In dit geval kunnen de klant en de ontwikkelaar dan gezamenlijk bespreken wat nodig is, vervolgens een formeel contract opstellen met een vaste prijs en bijbehorende specificaties. Dit kan in de vorm van een overeenkomst tussen commerciële entiteiten zijn of via een projectopdracht voor een interne IT-provider. Vervolgens kan de ontwikkelaar het werk uitvoeren; meestal binnen enkele maanden terwijl de klant op de resultaten wacht. Natuurlijk zullen ze in de tussentijd een aantal interacties hebben, meestal om voortgang te controleren en geen wijzigingen aan te brengen.

Ten slotte zal de ontwikkelaar een oplossing voor de klant presenteren, wat minimale feedback krijgen, een paar kleine dingen oplossen en de betaling krijgen die ze verdienen. Dit is een al oud bekend principe van projectmanagement voor softwareontwikkeling. Deze weg is ons bekend, het is iets dat ons is geleerd en dat min of meer onder de knie is in termen van weten hoe projecten moeten worden gemanaged.

Maar nu niet meer. In een moderne wereld weet de klant vaak heel weinig over het eindproduct dat hij of zij wil hebben. We weten vrijwel zeker dat de vereisten tussentijds in het project zullen veranderen, en dat dit verschillende keren zal gebeuren met een behoorlijk aantal grote wijzigingen. Bovendien zijn deze wijzigingen erg afhankelijk van de feedback van het gebruik van het softwareproduct. Feedback is een essentieel onderdeel voor het begrijpen van het product, de beperkingen, de mogelijkheden, de waarde voor de eindklant, enzovoort. Hoe meer we ontwikkelen, hoe meer feedback we krijgen en hoe meer wijzigingen er nodig zijn voor het product dat wordt ontwikkeld. Het is niet meer mogelijk om met een vast contract te werken, anders krijgt de ontwikkelaar nooit betaald voor zijn of haar inspanningen. Er is een muur opgetrokken tussen de klant en de ontwikkelaar. De ene kant moet wekelijks het product in ontwikkeling kunnen beïnvloeden, terwijl de andere kant met rust moet worden gelaten en het werk moet doen.

De oplossing hiervoor is Agile softwareontwikkeling. Met deze aanpak werkt de ontwikkelaar in kleine stappen, increments genaamd en levert een deel van de oplossing aan de klant om daar waardevolle feedback over te krijgen en verwerkt dit in de verdere ontwikkeling volgens de nieuwe vereisten en ideeën. De meeste teams noemen deze stappen waarin een deelproduct ontwikkeld wordt “Sprints”. Iemand van de klant treedt op als “Product Owner” en geeft aan wat belangrijk is om te ontwikkelen. Aan het eind van bijvoorbeeld elke tweede week houdt het hele team een “Sprint retrospective” waarbij het team de werkwijze evalueert en zoekt naar mogelijkheden om dit verder te verbeteren. Zo werkt het in Scrum en dit is helemaal geen slecht idee, maar Scrum is niet de enige Agile methode.

Maar hoe zit het met Operations in dit scenario? Nou, maak je geen zorgen! Ontwikkelaars zullen wat mensen in de buurt hebben om de nieuwe versie van de software in de productieomgeving te plaatsen. Enkele jaren geleden werkte Operations vrij langzaam, met veel handwerk via procedures. Tegenwoordig hebben we Continuous Integration (CI), Continuous Delivery (CD), pijplijnen, clouds, containers en andere moderne modewoorden om de levering van werkende software aan de eindgebruikers te versnellen.

Bij de meeste conferenties en evenementen over Agile kom je deze simplistische en handige kijk op het onderwerp tegen:

“DevOps is gewoon het gebruik van speciale softwaretools om een CI/CD-pijplijn te maken die begint op het moment dat de nieuwe versie van de software gereed is voor implementatie.”

 

Het is geen wonder dat deze mening weinig waarde toevoegt, omdat veel Agile-teams worstelen met tijdige softwarelevering en enorme downtijd terwijl ze wijzigingen aanbrengen in een productieomgeving. Daarmee verminderen alle voordelen van snelle Agile softwareontwikkeling.

 

De tweede is een betere weergave waarin we meer kunnen doen dan de eerste weergave

Het probleem ligt tussen Development en Operations. Onze Devs en onze Ops hebben tegenovergestelde doelen, wat betekent dat het bijna onmogelijk voor hen is om samen te werken als één entiteit en één team.

Moderne ontwikkelaars willen snel software leveren en deze met elke Sprint (in geval van Scrum) of zelfs constant, elke dag of meerdere keren per dag (in geval van Kanban) vrijgeven voor productie. Hoe frequenter de releases zijn, hoe beter het werk van analisten, programmeurs en testers (eigenlijk voor het hele ontwikkelteam) zou moeten zijn. Ze hebben meestal enkele KPI’s om dat te weerspiegelen: meer wijzigingen zijn beter, het constante tempo van wijzigingen aanhouden, vaak nieuwe versies leveren en feedback snel verwerken.

Operations-mensen hebben daarentegen alles te maken met stabiliteit. Onze IT-infrastructuur is kwetsbaar; we hebben de neiging om het niet zo vaak aan te passen. Hoe minder releases we doen, hoe beter de uptime is. Elke release geeft enorme pijn, we weten uit ervaring dat er van alles fout kan gaan en dat dit blijft gebeuren. Dus Ops gaat veel tijd en moeite besteden om de release in productie te brengen en te laten werken. De gebruikelijke KPI’s voor Operations, inclusief zaken als uptime, MTBF (Mean Time Between Failures), MTTR (Mean Time To Repair) en dergelijke, helpen om het plaatje compleet te maken. Daarom – hoe minder wijzigingen we hebben, hoe beter we, Operations, zullen presteren. Dus ontwikkelaars – wacht alstublieft op de afgesproken release-datum volgend kwartaal, want we hebben een releasebeleid dat onze IT-infrastructuur bewaakt.

Laten we nu eens naar een andere muur kijken, dit keer tussen Development en Operations.

Men kan de oplossing voor dit probleem vinden in DevOps. Dus als we op de een of andere manier kunnen regelen dat Development en Operations bij elkaar kunnen zitten, en als één team samenwerken met dezelfde hulpmiddelen en dezelfde methodologieën, dan kunnen we enkele mogelijkheden vinden om niet alleen snel en vaak software te ontwikkelen, maar ook om het snel en frequent te implementeren.

 

Deze visie op DevOps kan worden samengevat als:

“DevOps is een middel voor Development en Operations om in dezelfde richting samen te werken voor snelle, frequente en betrouwbare softwarelevering.”

 

Deze opvatting is nuttiger dan de vorige, vooral gezien het feit dat het is benadrukt door een aantal gerespecteerde internationale experts.

 

Kunnen we dit echter nog beter doen? Het blijkt dat we het kunnen.

 

De laatste weergave is een holistische weergave

Er zijn twee hoofdproblemen met de vorige weergaven. De eerste is dat alles op de een of andere manier aan de rechterkant stopt bij Operations, terwijl de software in werkelijkheid wordt gebruikt door eindgebruikers en de meeste feedback komt van hen. Het is vreemd om gebruikers niet in dit plaatje op te nemen, wat betekent dat de afbeelding niet compleet is.

Het tweede probleem is nog groter. Uit onze ervaring weten we dat het erg moeilijk is om één soepel proces uit twee geheel verschillende methodieken en toolsets, Agile en DevOps, te bouwen. In het verleden zagen we hierover een aantal mislukte pogingen die veel tijd, geld en moeite hebben gekost met weinig waarde en voordelen als resultaat. Als we naar de bovenstaande afbeelding kijken, moeten we op de een of andere manier niet alleen de muren verwijderen, maar ook de pijlen zelf. We hebben één uniform en enkel proces nodig voor de ontwikkeling én levering van software.

Dit is de weergave die zegt:

“DevOps is een continue snelle flow van werkzaamheden in een waardestroom (value stream) naar eindgebruikers, gebaseerd op Agile en Lean ideeën en methodologieën, waardoor snelle feedback mogelijk is.”

 

Lean werkwijzen zijn gericht op het identificeren en elimineren van verspilling. Merk op dat noch Development, noch Operations in bovenstaande zin wordt genoemd. Naar mijn mening is het belangrijker om te beseffen dat deze flow begint bij de business en eindigt bij de business. In plaats van (alleen) Devs en Ops hierin op te nemen (ze zijn natuurlijk inbegrepen in de flow), zijn net zo goed analisten, UI/UX (user interface en user experience) ontwerpers, DBA’s (database administrators), beveiligingsmedewerkers, testers, en alle anderen betrokken die nodig zijn om moderne softwareoplossingen te bouwen.

 

Conclusie

In een notendop is het erg moeilijk om de laatste mening te zien door gewoon naar de term “DevOps” te kijken. Men moet het volledige artikel lezen om te begrijpen wat DevOps betekent en welke problemen met deze methodologie kunnen worden opgelost. Omdat ik zelf erg pragmatisch ben, behandel ik ITIL/ITSM, COBIT, PRINCE2, TOGAF, Agile, Lean en natuurlijk DevOps als hulpmiddelen in mijn toolset – afhankelijk van het probleem dat opgelost moet worden. Ik kan de beste oplossing kiezen voor mijn klanten.

Interessant genoeg duurde het een aantal decennia om ITSM (IT Service Management) te waarderen en eindelijk te begrijpen dat het niet alleen “op procesmatige wijze IT-diensten leveren en beheren” is. Bedrijven die ITSM omarmen en verder gaan dan alleen toepassen op de Servicedesk, de servicecatalogus en SLA’s, slagen erin meer profijt te trekken van de methodiek en meer waarde te genereren voor zichzelf en hun klanten.

Ik hoop echt dat de weg naar begrip en acceptatie van DevOps aanzienlijk minder tijd in beslag zal nemen, omdat deze nieuwe tool (geen speelgoed!) veelbelovend is en nu al belangrijke resultaten oplevert.

The post Het grootste probleem met DevOps is de naam appeared first on EN | Van Haren Publishing.