FinOps en verantwoordelijkheid
FinOps begint eigenlijk bij de cultuur van de organisatie, maar zoals aangegeven in het FinOps State of Cloud-rapport is het in de praktijk lastig om engineers mee te krijgen in de FinOps gedachte. Hierbij gaat het vaak niet om onwil. Engineers en developers zijn simpelweg niet gefocust op het meetbaar maken van de kosten. Maar die cultuuromslag is wel nodig om FinOps succesvol te maken. Met een FinOps cultuur wordt bedoeld dat iedereen die impact heeft op de cloudkosten, zich moet gedragen als een business owner. Iedereen moet zijn uitgaven telkens baseren op geplande cases.
Ook moet de directie het belang van FinOps intern goed uitdragen. Bovendien moet iedereen zijn zakelijke en persoonlijke KPI’s op elkaar afstemmen. Idealiter helpen chargeback- en showback-modellen om die verandering daadwerkelijk te realiseren. Want in de praktijk kom je niet zonder slag of stoot tot een ideale situatie. Om intern te duiden hoe er een wildgroei aan kosten ontstaat, kun je deze oneliner gebruiken:
“Het is veel eenvoudiger voor een engineer om 10.000 euro in de cloud te spenderen dan om een muis van 10 euro te kopen.”
Om een muis te kopen moet een engineer eerst toestemming krijgen van zijn leidinggevende. Vervolgens koopt hij die muis en levert hij zijn bon in bij de financiële afdeling voor akkoord. Wordt de aankoop goedgekeurd, dan krijgt de engineer uiteindelijk die 10 euro teruggestort op zijn rekening. Ondertussen kan diezelfde engineer inloggen op zijn cloudaccount en duizenden dollars uitgeven, zonder dat hij ook maar één vraag hoeft te beantwoorden.
Veel enterprises hebben geen inkoopbeleid als het om de cloud gaat. Meestal is dit niet bewust. De cloud biedt nu eenmaal snelheid en wendbaarheid en maakt innovatie mogelijk. Er wordt daardoor niet zoveel aandacht besteed aan een eventueel risico op overbesteding. Engineers en developers kunnen dan ook simpelweg kopen wat ze nodig hebben om hun werk goed te doen zonder dat ze goedkeuring nodig hebben van een IT-manager. Ze moeten immers ook inspelen op de klanttevredenheid. En goedkopere resources voldoen nu eenmaal niet altijd aan de technische benodigdheden of de SLA’s.
Het kan natuurlijk voorkomen dat engineers en developers op bepaalde vlakken wél echt teveel besteden om de performance te verbeteren zonder dat dit echt waarde toevoegt aan je bedrijf. Een engineer verandert bijvoorbeeld de servers van een applicatie van vier CPU’s naar acht CPU’s. Daarmee verdubbelt de snelheid en verbetert de customer experience. Maar deze verbeterde performance is niet nodig als klanten al tevreden zijn en leveren bovendien niets op voor de SLA’s. In dat geval vertalen de extra resources zich niet in business resultaten.
Tip: volgens de FinOps Foundation is de participatie van engineers de belangrijkste uitdaging waarmee FinOps managers te maken hebben. Veel engineers volgen de aanbevelingen niet op als ze daar geen tijd voor hebben of als de maatregelen voor kostenoptimalisatie niet overeenkomen met hun KPI’s.