Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Zo houd je grip op kosten in devops-omgeving

Dit artikel delen:

Computable Expert

Jochem van Lierop
CTO, Conclusion Mission Critical. Expert van Computable voor het topic Cloud Computing.

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

"Het management moet begrijpen dat je vooraf niet precies weet hoe hoog de kosten zullen zijn"

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

"Grote cloud-infrastructuurproviders zoals Azure en AWS bieden veel tools die inzicht geven in de kosten"

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.
x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

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.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden
Nieuwsbrief

Wil je dagelijks op de hoogte gehouden worden van het laatste ict-nieuws, trends en ontwikkelingen? Abonneer je dan op onze gratis nieuwsbrief.

Vul een geldig e-mailadres in

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2021-10-01T11:51:00.000Z Jochem van Lierop
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.