We hadden het eerder over ‘agile development’, waarvan het voordeel is dat organisaties daarmee sneller kunnen inspelen op de vragen van de omgeving. De belangrijkste prestatie indicator van agile development is ‘feature velocity’: de snelheid waarmee functionaliteit aangepast kan worden. Hoe korter de tijd tussen een nieuw idee en het testen er van in de praktijk, hoe minder verspilling er ontstaat.
Agile development is een competentie van een organisatie. Eerder beargumenteerde ik dat cloud computing daarvoor een essentiële component is. Maar hoe zit dat nu precies?
Dat is waar DevOps om de hoek komt kijken. DevOps is uiteraard een hype woord dat voor van alles wordt gebruikt, maar zoals bij veel hype woorden zit er wel een harde kern in.
Ontwikkeling en beheer
Traditioneel zijn ontwikkeling en beheer gescheiden werelden. Het zijn andere processen, andere mensen, andere afdelingen, en ga zo maar door. Ontwikkelaars houden van verandering, ze worden afgerekend op de hoeveelheid nieuwe dingen die ze produceren. Beheerders daarentegen zien elke wijziging als een bedreiging, want die kan het systeem dat net een beetje lekker begon te draaien weer om zeep helpen.
In de praktijk leidt deze scheiding van ontwikkeling en beheer er toe dat mooie nieuwe features maanden op implementatie moeten wachten vanwege een of andere suffe reden. Of het nu de levertijd van een server is, een security analyse of simpelweg gebrek aan handjes om de gewenste wijzigingen in te kloppen, het duurt altijd veel langer dan je denkt. Een of andere met stroop ingesmeerde ophaalbrug tussen ontwikkelaars en beheer belet elke nuttige vooruitgang, zo lijkt het.
Taakverdeling
DevOps stelt voor dit proces anders te zien. In plaats van beheerders op het kritische pad naar productie te laten zitten, en ze af te rekenen op incidenten veranderen we de taakverdeling. Ontwikkelaars krijgen de taak om code in productie te brengen, maar worden ook afgerekend op het aantal incidenten dat daarvan het gevolg is. Beheerders stappen uit de delivery straat, maar krijgen de taak om die delivery straat optimaal in te richten zodat ontwikkelaars daadwerkelijk code in productie kunnen brengen.
Het lijkt eng. Bij DevOps kunnen praktijken horen als testen in productie, productieservers niet patchen, en het overslaan van change advisory board bijeenkomsten voor de meeste functionele wijzigingen. Voor old-school auditors zijn dit rode vlaggen die meteen leiden tot bevindingen van de hoogste categorie.
DevOps kan veiliger zijn
Maar wie een goede risico analyse maakt van de werkelijke bedreigingen ziet dat, met de juiste automatisering die door DevOps mogelijk gemaakt wordt, DevOps juist veel veiliger kan zijn.
Bij DevOps worden handmatige goedkeuringsstappen vervangen door automatische. Functionele en performance wijzigingen worden vaak getest door ze in productie op een klein percentage van de gebruikers los te laten, en onmiddellijk weer terug te draaien bij ongeschiktheid. Productieservers die niet meer actueel zijn worden binnen een paar minuten vervangen door modernere.
Vanuit de risico’s bezien zijn deze praktijken eigenlijk superieur.
Devops kan dus leiden tot betere procesbeheersing, en daarmee tot meer veiligheid.
Dit artikel is geplaatst in het Tijdschrift IT Management, een uitgave van ICT Media.