De cloudarchitectuur is rechtstreeks bepalend voor de cloudkosten, omdat elke structurele beslissing die u neemt – van de manier waarop diensten met elkaar communiceren tot de manier waarop gegevens tussen regio’s worden verplaatst – zich vertaalt in factureerbaar verbruik. De manier waarop u uw infrastructuur ontwerpt, bepaalt welke resources worden toegewezen, hoe lang deze actief blijven en hoe efficiënt ze uw workloads ondersteunen. Dit artikel gaat dieper in op de belangrijkste architecturale keuzes die uw clouduitgaven bepalen en legt uit wat u kunt doen om ontwerpbeslissingen af te stemmen op financiële verantwoordelijkheid.
Hoe beïnvloedt de cloudarchitectuur rechtstreeks de cloudkosten?
De cloudarchitectuur bepaalt de cloudkosten, omdat cloudproviders kosten in rekening brengen voor elke resource die u verbruikt, en uw architectuur bepaalt wat er wordt verbruikt, wanneer en op welke schaal. In tegenstelling tot een on-premises infrastructuur, waar hardware een vaste kapitaaluitgave is, zijn de clouduitgaven een directe weerspiegeling van architecturale keuzes: rekenconfiguraties, opslagniveaus, gegevensoverdrachtpaden en serviceafhankelijkheden genereren allemaal voortdurend kosten.
Wanneer je een workload in de cloud implementeert, neem je niet alleen een technische beslissing. Je neemt ook een financiële beslissing. Een slecht ontworpen architectuur kan kosten met zich meebrengen die veel hoger liggen dan wat de workload daadwerkelijk nodig heeft. Zo leiden het 24 uur per dag op volle capaciteit draaien van compute-instances bij een wisselende vraag, het onnodig routeren van gegevens tussen regio's of het gebruik van overgedimensioneerde databases allemaal tot vermijdbare uitgaven. De architectuur beïnvloedt niet alleen de kosten bij de lancering. Naarmate de omgeving opschaalbaar is, lopen de kosten in de loop van de tijd steeds verder op.
Daarom beheer van cloudkosten kan niet worden beschouwd als een afzonderlijk financieel proces dat pas achteraf wordt toegevoegd nadat de architectuur in gebruik is genomen. Kostenbewustzijn moet vanaf het begin worden meegenomen in architecturale beslissingen.
Welke architectuurpatronen zijn het duurst in de cloud?
De duurste architectuurpatronen in de cloud zijn die patronen die een groot uitgaand dataverkeer genereren, waarbij de rekencapaciteit tijdens piekuren continu op volle kracht moet draaien, of die complexe afhankelijkheden tussen diensten creëren waardoor de kosten voor API’s en verwerking sterk toenemen. Deze patronen zijn niet duur omdat ze op zich verkeerd zijn, maar omdat ze vaak worden geïmplementeerd zonder kostenbeperkingen.
De volgende factoren zorgen er steevast voor dat de kosten van de cloudinfrastructuur stijgen:
- Te veel toegewezen rekencapaciteit: Als je CPU- en geheugencapaciteit toewijst op basis van veronderstellingen over piekbelasting in plaats van op basis van het daadwerkelijke gebruik, betaal je voor capaciteit die het grootste deel van de tijd ongebruikt blijft.
- Gegevensoverdracht tussen regio's: Voor het verplaatsen van gegevens tussen beschikbaarheidszones of regio’s worden uitgaande kosten in rekening gebracht, die in gedistribueerde architecturen snel oplopen.
- Niet-geoptimaliseerde opslaglagen: Het opslaan van gegevens die zelden worden geraadpleegd in hoogwaardige opslaglagen in plaats van in goedkopere archiefoplossingen leidt tot onnodige kosten zonder dat dit prestatievoordelen oplevert.
- Synchrone, informele communicatie binnen de dienstverlening: Architecturen waarin services regelmatig kleine API-aanroepen naar elkaar sturen, zorgen ervoor dat zowel de latentie als de kosten per aanroep toenemen.
- Gebrek aan automatische schaalbaarheid: Statische infrastructuur die tijdens periodes met een lage vraag niet wordt teruggeschroefd, leidt tot kosten voor resources die niet worden gebruikt.
Om te bepalen welk van deze patronen op uw omgeving van toepassing is, is inzicht in de daadwerkelijke verbruiksgegevens nodig, en niet alleen in architectuurdiagrammen.
Welke invloed heeft de keuze tussen microservices en een monolithische architectuur op de cloudkosten?
Microservices-architecturen leiden op kleinere schaal doorgaans tot hogere cloudkosten dan monolithische architecturen, maar kunnen op grotere schaal kostenefficiënter worden als ze goed worden geïmplementeerd. De afweging hangt af van de mate van granulariteit waarmee services worden geïmplementeerd, hoe ze met elkaar communiceren en hoe effectief je de infrastructuur beheert die deze services ondersteunt.
Een monolithische applicatie draait doorgaans op een kleiner aantal rekeninstances met een voorspelbaar resourcegebruik. Je kunt de omvang van die instances nauwkeurig bepalen en de kosten beheren door middel van een relatief eenvoudige aanpassing van de capaciteit. Microservices daarentegen verdelen de werklast over vele onafhankelijk geïmplementeerde services. Elke service vereist zijn eigen rekenkracht, netwerkcapaciteit en vaak ook zijn eigen opslagruimte. Containerorkestratieplatforms, servicemeshes en API-gateways zorgen voor nog meer overhead in de infrastructuur.
Het kostenrisico bij microservices is wildgroei. Wanneer teams diensten onafhankelijk van elkaar implementeren zonder gezamenlijk kostenbeheer, neemt het totale aantal actieve resources snel toe, vaak zonder dat er inzicht is in wat elke dienst daadwerkelijk kost. Een dienst die slechts weinig verkeer verwerkt maar 24 uur per dag op een speciale instance draait, is een duidelijk voorbeeld van architectonische verspilling.
Het kostenvoordeel van microservices komt tot uiting wanneer je gedetailleerde automatische schaalbaarheid toepast. Een enkele service waar veel vraag naar is, kan onafhankelijk worden geschaald zonder dat de gehele applicatie hoeft te worden geschaald, wat in een monolithisch model niet mogelijk is. Om dat voordeel te benutten, zijn architectonische discipline en actieve kostenmonitoring op serviceniveau vereist.
Waarom stijgen de cloudkosten naarmate de architectuur opschaalt?
De cloudkosten stijgen naarmate de architectuur opschaalt, omdat bij opschaling alle kostenfactoren die al in het ontwerp aanwezig zijn, worden vermenigvuldigd. Meer gebruikers betekenen meer rekenkracht, meer gegevensoverdracht, meer API-aanroepen en meer opslagruimte. Als de onderliggende architectuur inefficiënt is, versterkt opschaling die inefficiëntie evenredig, en soms zelfs exponentieel.
Er zijn verschillende mechanismen die op grote schaal tot kostenstijgingen leiden:
- Groei van het datavolume: Naarmate het gebruik toeneemt, neemt ook de hoeveelheid opgeslagen, verwerkte en overgedragen gegevens toe. Voor elk van deze aspecten geldt een eigen prijsmodel.
- Afhankelijkheidsketens van services: Op grote schaal kan één gebruikersverzoek tientallen daaropvolgende serviceaanroepen in gang zetten. Elke aanroep zorgt voor extra vertraging en extra kosten.
- Overhead voor logboekregistratie en monitoring: Een observability-infrastructuur, die bij grootschalige toepassingen van groot belang is, brengt aanzienlijke kosten met zich mee door de verwerking, opslag en opvraging van logbestanden.
- Verschil in betrokkenheid: Organisaties kopen vaak gereserveerde capaciteit in op basis van gebruikspatronen in een vroeg stadium. Naarmate de architectuur zich verder ontwikkelt, sluiten die toezeggingen niet langer aan bij de werkelijke werklastpatronen, wat tot verspilling leidt.
Het kernprobleem is dat veel organisaties bij het ontwerpen in de eerste plaats naar functionaliteit kijken en pas op de kosten terugkomen als ze door een onverwachte rekening worden verrast. Op dat moment ligt de architectuur al vast en is herstructurering een kostbare aangelegenheid. Door vanaf het begin kostenbewustzijn in te bouwen in beslissingen over schaalbaarheid, kan dit patroon worden vermeden.
Welke architecturale aanpassingen hebben de grootste invloed op het verlagen van de cloudkosten?
De architecturale aanpassingen die de grootste impact hebben op het verlagen van de cloudkosten zijn het op de juiste omvang afstemmen van rekenbronnen, het implementeren van automatische schaalbaarheid, het optimaliseren van gegevensoverdrachtspaden en het kiezen van geschikte opslagniveaus. Deze aanpassingen richten zich op de kostenfactoren met het grootste volume en leveren meetbare besparingen op zonder dat een volledig herontwerp van de architectuur nodig is.
Rechtmatige dimensionering en automatische schaalbaarheid
‘Rightsizing’ houdt in dat instancetypen en -groottes worden afgestemd op de werkelijke vereisten van de werklast, in plaats van te voorzien in een theoretische piekvraag. In de praktijk draaien veel cloud-werklasten op instances die twee tot vier keer groter zijn dan nodig is. Door rightsizing te combineren met automatische schaalbaarheid, zodat de capaciteit toeneemt wanneer de vraag stijgt en afneemt wanneer deze daalt, worden de kosten van inactieve resources volledig geëlimineerd.
Optimalisatie van gegevensoverdracht en -opslag
Door te bekijken hoe gegevens binnen uw architectuur worden verplaatst, kunt u vaak aanzienlijke besparingen realiseren. Het binnen dezelfde beschikbaarheidszone houden van gegevensverwerking, het dichter bij de rekenlaag cachen van gegevens die vaak worden geraadpleegd en het verplaatsen van zelden gebruikte gegevens naar goedkopere opslaglagen zijn aanpassingen die de kosten verlagen zonder de prestaties van applicaties aan te tasten. Ook het herzien van bewaarbeleid en het verwijderen van gegevens die geen zakelijk doel meer dienen, leidt op termijn tot lagere opslagkosten.
Naast deze gerichte aanpassingen kunnen architecturale beslissingen over de plaatsing van workloads – zoals het beoordelen welke workloads daadwerkelijk baat hebben bij de cloud en welke beter geschikt zijn voor een on-premises infrastructuur – de grootste besparingen opleveren. Hiervoor is volledig inzicht nodig in de kostenvergelijking tussen de verschillende omgevingen, en juist daar speelt gestructureerd financieel beheer van de cloud een belangrijke rol.
Hoe helpt FinOps om beslissingen over de cloudarchitectuur af te stemmen op de verantwoordelijkheid voor de kosten?
FinOps helpt bij het afstemmen van beslissingen over de cloudarchitectuur op de verantwoordelijkheid voor de kosten door een gezamenlijk bedrijfsmodel te creëren waarin technische, financiële en zakelijke teams gezamenlijk beslissingen nemen over de clouduitgaven, op basis van realtime kostengegevens. Zonder deze afstemming blijven architectuurbeslissingen en financiële gevolgen los van elkaar staan, en blijft optimalisatie reactief en ad hoc.
De grootste uitdaging waar de meeste organisaties mee te maken hebben, is niet een gebrek aan inzicht in de kosten. Er zijn volop tools en dashboards beschikbaar. De uitdaging is dat inzicht niet automatisch tot beslissingen leidt. Applicatieteams beheren de architectuur en sturen daarmee de uitgaven aan, maar de financiële verantwoordelijkheid ligt elders. FinOps dicht die kloof door verantwoordelijkheid toe te wijzen, beslissingsritmes vast te stellen en kostenoverwegingen in het engineeringproces zelf te verankeren.
In de praktijk maakt FinOps een aantal belangrijke werkwijzen mogelijk:
- Technische teams krijgen een gedetailleerd overzicht van de kosten die aan de door hen beheerde diensten zijn toegewezen, waardoor de financiële gevolgen van architecturale keuzes op teamniveau zichtbaar worden.
- De afdelingen Financiën en IT werken op basis van gedeelde datasets in plaats van afzonderlijke rapportagesystemen, waardoor de wrijving bij begrotingsbesprekingen wordt verminderd.
- Beslissingen over verbintenissen, zoals gereserveerde instances en besparingsplannen, worden in onderling overleg genomen, waarbij zowel de technische als de financiële afdeling hun inbreng leveren, wat de nauwkeurigheid ten goede komt.
- De afwegingen tussen de kosten van cloudoplossingen en on-premises-oplossingen worden beoordeeld aan de hand van vergelijkbare gegevens, wat leidt tot betere beslissingen over hybride infrastructuur.
Door FinOps te integreren met Technology Business Management (TBM) wordt dit concept verder uitgebreid: de optimalisatie van cloudkosten wordt gekoppeld aan het bredere financiële beheer van de IT, waardoor ervoor wordt gezorgd dat de clouduitgaven worden begrepen in de context van de bedrijfswaarde die ze opleveren.
Hoe wij u helpen uw cloudarchitectuur af te stemmen op kostenverantwoording
Wij helpen organisaties om een stap verder te gaan dan alleen inzicht in de cloudkosten, naar een actief, op governance gebaseerd financieel beheer van de cloud. Onze FinOps-diensten zijn bedoeld voor organisaties waar architectuurbeslissingen en kostenverantwoording momenteel los van elkaar staan, en waar optimalisatie ondanks de beschikbare tools nog steeds ad hoc plaatsvindt.
Als je met ons samenwerkt, krijg je:
- Volledige kostentoerekening over computing, containers en ondersteuningskosten, zodat elk team inzicht krijgt in de kosten van de onderdelen waarvoor het verantwoordelijk is
- Analyse van de optimale personeelsbezetting binnen AWS, Azure en GCP, waarbij wordt vastgesteld waar te ruim toegewezen resources tot vermijdbare kosten leiden
- Een gestructureerd FinOps-bedrijfsmodel waarin rollen, beslissingsbevoegdheden en de frequentie van het bestuur binnen de afdelingen financiën, IT en engineering worden vastgelegd
- Integratie van TBM en FinOps die het beheer van cloudkosten koppelt aan strategische beslissingen over IT-investeringen
- Een beoordeling van de FinOps-rijpheid als praktisch uitgangspunt om inzicht te krijgen in de huidige stand van zaken binnen uw organisatie en wat de prioriteiten zijn
Als je wilt begrijpen hoe je cloudarchitectuur je kosten beïnvloedt en wat je daaraan kunt doen, neem contact met ons op om het gesprek op gang te brengen.