Auteur: Gilbert Smulders ● gilbert.smulders@viqit.nl
Op dit moment doe ik een opdracht binnen een DevOps team. Een paar jaar terug is dit al eens gefaald. In de meest recente poging lijkt het nu wel wat beter te werken. Toch blijft er regelmatig discussie over hoe we hiermee verder moeten gaan. Toen ik tijdens mijn zoektocht voor een nieuwe video review tegen deze video van Brandon Kolybaba over DevOps aanliep, leek me dit een mooi onderwerp voor een review.
De Spreker
Brandon Kolybaba is een Canadees die zich heeft gespecialiseerd in cloud infrastructuren. Hij is oprichter en eigenaar van CloudBrewery en CloudA. Via deze bedrijven levert hij IAAS oplossing voor diverse klanten in Canada. Hij is een aanhanger van ‘The Five Dysfunctions of a Team’ methode van Patrick Lencioni. Deze probeert hij ook in zijn teams steeds het hoofd te bieden.
De Presentatie
Brandons presentatie geeft wat meer inzicht in wat DevOps nu eigenlijk is. Daarbij begint hij met aan te geven wat het niet is. Het is namelijk niet het samenvoegen van Development en Operations. Het is ook geen product dat je zo maar even implementeert. Maar het is zeker ook geen mythe.
Maar wat is het dan wel? En waarom hebben we het dan nodig? Brandon begint met die laatste vraag. Naar zijn idee zijn er drie drijfveren. Een kortere ‘time-to-market’, hogere kwaliteit, lagere kosten en opheffen van ‘vendor lock-in’. Voordat DevOps zijn intrede deed, was er een hele andere situatie. Er werd gewerkt in silo’s, waardoor ontwikkeling duur was, lang duurde en er vertrouwensproblemen waren. IT-organisaties worstelden hiermee en waren op zoek naar alternatieven om weer business-waarde te kunnen leveren.
Brandon vervolgt zijn verhaal met zijn definitie van DevOps. Naar zijn idee is het een combinatie van Development, Operations en Proces. Waarbij Quality Assurance voor een goedlopend proces zorgt die de business-waarde waarborgt. Binnen DevOps onderscheidt Brandon drie fasen van competentie-ontwikkeling. De eerste fase is de basis. Daarin ziet hij de Agile methodiek en testautomatisering als de belangrijkste elementen. De volgende stap is Continuous Integration. Als je de testen hebt geautomatiseerd, dan is het belangrijk om deze te automatiseren in je bouwproces. De laatste fase is Continuous Delivery. Deze fase detailleert hij wat meer omdat je hier je echte business-waarde behaalt.
Bij Continuous Delivery gaat het niet alleen om het automatiseren van je bouw- en testactiviteiten. Er komen ook zaken als releasen, deployen, de operatie en het monitoren naar voren. Bovendien komen er steeds meer mogelijkheden om code portable te maken, zodat ook allerlei cloud-oplossingen mogelijk zijn. Waarde leveren duurt dan geen maanden meer, maar slechts enkele minuten.
Brandon vat dit samen met een overzicht van de mate van samenwerking en de business-waarde. Oplopend van Agile Development, via Continuous Integration en Continuous Delivery naar DevOps. Daar bereik je de uiteindelijke doelen van snellere ‘time-to-market’, hogere kwaliteit, lagere kosten en oplossen van ‘vendor lock-in’.
Ter afsluiting geeft Brandon aan waarom DevOps bij organisaties vaak faalt. Zo ziet hij vaak dat er geen vertrouwen is. Geen vertrouwen in het proces en geen vertrouwen in elkaar. Bovendien vraagt het een échte verandering in je organisatie. Het is namelijk een methode- en cultuurverandering en geen kant-en-klaar product of project dat je kunt implementeren. Het belangrijkste is het besef dat dit tijd kost vanwege die cultuurwijziging.
Mijn visie
Naar mijn idee is de uitleg van Brandon wat mager en soms wat tegenstrijdig. Testautomatisering, Continuous Integration en Continuous Delivery zijn inderdaad belangrijke elementen om snellere ‘time-to-market’ en lagere kosten te realiseren. Maar zijn dit de doelen van DevOps? Naar mijn idee is DevOps primair bedoeld om ook de, veelal ‘non-functional’, eisen vanuit beheer de juiste aandacht te geven in het softwareontwikkelproces. Om daarmee de muur tussen ontwikkeling en beheer te slechten. Daarom zie ik ook niet de genoemde fasen in DevOps competentieontwikkeling. Dit zijn logische stappen voor Agile teams om de kortere ‘time-to-market’ die zij via het iteratieve proces realiseerden nog korter te maken. Als organisaties daarbij tot de conclusie komen dat zij functionaliteit weliswaar sneller kunnen opleveren, maar dat deze functionaliteit steeds lastiger is te beheren, dan is DevOps een optie. Door het team niet alleen verantwoordelijk te maken voor het realiseren van nieuwe functionaliteit, maar ook voor het beheer ervan, zullen zij dit aspect vanzelf meer aandacht geven. Daarmee krijg je een hogere kwaliteit software met échte business-waarde.
Al met al een video van Brandon Kolybaba die niet echt nieuwe inzichten geeft. Wat mij betreft dus geen aanrader. Maar bekijk hem eens gerust (hij duurt maar 9 minuten) en vorm je eigen mening.
Bekijk de video hier
NieuwsMagazine