Het klonk veel softwareontwikkelaars als muziek in de oren toen ze hoorden over het concept van agile devops-teams: zelf bepalen wanneer je waaraan werkt, vrijheid in de keuze welke tools je daarvoor gaat inzetten, en zelf extra capaciteit uit de cloud kunnen bijschakelen op het moment dat dat nodig is. Wie wil dat niet?
Wat zij, en ook hun managers, zich onvoldoende realiseerden, is dat vrijheid samengaat met verantwoordelijkheid. Verantwoordelijkheid op het gebied van de snelheid waarmee bepaalde functionaliteiten worden opgeleverd en ten aanzien van de stabiliteit van de applicatie. Maar ook verantwoordelijk op het gebied van de kosten. Want als devops-teams zelf kunnen bepalen welke resources wanneer nodig zijn, kom je niet meer weg met een jaarbudget dat vooraf is bepaald.
Omslag
Deze nieuwe denkwijze vraagt om een behoorlijke omslag in het denken van zowel het management als van de devops-teams. Het management moet begrijpen dat je vooraf niet precies weet hoe hoog de kosten zullen zijn. Je it wordt agile, maar je kostenstructuur ook. Dat is niet erg als die hogere kosten worden terugverdiend door een hogere omzet, zo lang de kosten ook maar mee naar beneden schalen op het moment dat je omzet daalt. Dit betekent dat je op een andere manier moet gaan sturen op kosten.
Inschatting
De belangrijkste wijziging is dat de verantwoordelijkheid voor de kosten lager in de organisatie komt te liggen, en wel bij de devops-teams zelf. Zij moeten het businessmodel begrijpen, zodat ze een inschatting kunnen maken welke kosten verantwoord zijn en welke niet.
In een vorige blog heb ik beschreven dat niet elk devops-team dezelfde mate van autonomie en daarmee dezelfde mate van verantwoordelijkheid hoeft te hebben. In omgevingen die minder agility nodig hebben, kun je behoorlijk veel zaken van tevoren vastleggen. Maar in omgevingen die zich snel moeten kunnen aanpassen aan veranderende klantwensen, wil je dat de teams zelf de autonomie hebben om snel te kunnen schakelen. Daar hoort echter bij dat ze ook zelf in de gaten houden of de kosten die ze daarvoor maken in lijn zijn met de omzet(verwachtingen).
Kostenbewustzijn
Nu is er in de meeste devops-teams al een behoorlijk kostenbewustzijn aanwezig, vooral bij de ops-specialisten. Zij waren immers van oudsher gewend om investeringen in nieuwe hardware te budgetteren. Voor ontwikkelaars is deze manier van denken wat nieuwer, die hoefden zich voorheen niet bezig te houden met wat een otap-straat kost. Terwijl ze nu wel moeten nadenken over de kosten die ze maken in hun ci/cd-pipeline.
Grote cloud-infrastructuurproviders zoals Azure en AWS bieden veel tools die inzicht geven in de kosten. De uitdaging ligt dus niet op het gebied van transparantie – die is er voldoende – het gaat er om dat de devops-teams verantwoordelijkheid nemen over hun inkoop: wanneer kiezen we voor pay-per-use en wanneer sluiten we een contract af voor langere tijd (met de bijbehorende lagere kosten)? Want hoe flexibeler je capaciteit inkoopt, hoe hoger de kosten zijn. Waar dit vroeger een managementbeslissing was waar techneuten zich niet mee bezighielden, wordt het nu een beslissing die door techneuten wordt gemaakt. De teams moeten zich dus bewust zijn van de kosten die verbonden zijn aan bepaalde technische keuzes die zij maken. En van de hogere omzet die het bedrijf kan realiseren door deze keuzes. Want het gaat niet alleen om de kosten, maar ook om de opbrengsten.
Logisch nadenken
Ingewikkeld is dit spel niet en met een beetje logisch nadenken kom je een eind. Wat moeilijker is, is dit gedachtengoed tussen de oren krijgen bij zowel het management als de devops-teams. Het management legt beslissingen lager in de organisatie neer. Dat betekent dat ze het moeten loslaten, je kunt het niet meer vooraf budgetteren.
Het betekent ook dat ze moeten accepteren dat er soms een foute inschatting wordt gemaakt. Als een team verwacht dat de omzet redelijk stabiel blijft en daarom voor de bestelomgeving een jaarcontract afsluit, maar een maand later keldert de omzet door een lock-down, dan schalen de kosten niet mee naar beneden. Met deze kennis achteraf had je liever gekozen voor pay-per-use. Dat snappen de medewerkers in het devops-team zelf ook wel. Ze hebben geen manager nodig die hier stampij over maakt. Wat ze beter kunnen gebruiken is een goed gesprek om te analyseren hoe ze dit een volgende keer kunnen voorkomen. Zijn er bijvoorbeeld signalen die wijzen in een bepaalde richting?
Kortom, wie wil dat de kosten voor it in lijn blijven met de omzet en winst, ontkomt er niet aan een groot deel van die verantwoordelijkheid neer te leggen in de devops-teams. Geef ze de verantwoordelijkheid, maar ook de vrijheid om hun eigen keuzes te maken.
Benieuwd wat spuit elf van Computable te zeggen heeft, de term ops-specialisten is wel wat cryptisch voor wat naar ik aanneem de klassieke beheerders van de infrastructuur zijn. En de klassieke beheerders zijn inderdaad gewend om met de gebruikelijke TCO van lineaire afschrijvingen te rekenen terwijl de cowboy taal-specialisten nog veel moeten leren. De moderne beheerders kennen naast de kosten van eigendom ook de huur en weten dat met name de grote cloudspelers NIET transparant zijn in de kosten omdat commerciële belang van de providers ligt in de verrassing achteraf.
Wat betreft de jij-bak refereer ik alvast naar voorgaande reactie want ik ben benieuwd of het een goed idee is om een DevOps-teams zelfstandig met budgetverantwoordelijkheid in de hiërarchie van een organisatie te laten functioneren. Een DevOp-team als business unit lijkt me tot een verdergaande verzuiling te leiden met nog meer uitdagingen in de keten.