Een van de grote voordelen van publieke IaaS/PaaS-diensten is de pay per use-belofte. Een mooi karakteristiek dat cloudcases zeer interessant kan maken. Pay per use kan echter ook tegenovergesteld uitpakken. In dit artikel drie praktische adviezen voor maximale efficiency en het voorkomen van onverwacht hoge kosten.
Right-size de virtuele machines. Developers en architecten die vanaf on-premise architectuur komen, hebben veelal de neiging om te ruim te schalen. Start in de cloud met een kleiner type virtual machine. Verticale opschaling is namelijk achteraf mogelijk met ‘slechts’ een reboot. Gebruik, indien de applicatie daarvoor geschikt gemaakt is, functies als auto-schaling die horizontaal schalen mogelijk maken, zonder al te veel aan de applicatie aan te passen.
Voor applicaties die slechts op bepaalde (vaste) momenten noodzakelijk zijn, is scheduling interessant. Nadat een opstartroutine/script is gebouwd, is middels een schedule script een omgeving eenvoudig uit te zetten op momenten dat deze structureel niet nodig is zoals ‘s nachts of in het weekend.
Begrijp de kostenparameters. Bij toepassing van pay per use-diensten is beheersbaarheid en voorspelbaarheid essentieel – en is inzicht nodig in de parameters die de kosten drijven. Dit lijkt evident, maar de verschillende IaaS/PaaS-providers hebben een verschillend kostenmodel. Voor IaaS zijn de belangrijkste kostenparameters het instance-type (cpu/mem) en de storage GB’s. Let bij storageverbruik op afrekening op provisioned versus used storage. Zo wordt Softlayer en Amazon EBS Storage afgerekend per provisioned GB terwijl Azure inzet op betalen naar daadwerkelijk verbruikte storage. Hoge performance op storage is bij de meeste platformen een dure optie, gebruik dat alleen als het echt nodig is.
Andere relevante kostenparameters zijn data-transferkosten en read/write actions. Vrijwel alle cloudproviders rekenen kosten voor uitgaande data (Egress). Vaak, onder meer Amazon en Azure, worden eveneens kosten gerekend voor inter-regio verkeer, terwijl bijvoorbeeld Softlayer het juist als selling point aanhaalt om binnen het platform kosteloos data te transfereren tussen regio’s. De parameter read/write actions voelt redelijk ondoorzichtig, maar in de praktijk zijn deze kosten veelal verwaarloosbaar. Cloudproviders hebben hier een parameter op staan om zich voor zeer specifieke gevallen te beschermen.
Voor PaaS-diensten zijn storage, performance type en aantal transacties relevant, dit varieert sterk per type PaaS-dienst. Essentieel dus om het gedrag van de applicatie en PaaS-service te kennen of eerst kleinschalig te testen. Let bij PaaS ook op dubbele kosten voor licenties. Als er al bestaande licenties zijn ingekocht voor bijvoorbeeld de database software, bereken dan zorgvuldig de varianten tussen het inbrengen van de eigen licentie versus het flexibel afnemen van de licentie vanuit de PaaS-dienst.
Als exact helder is wat de kostenparameters zijn, kan er op designed, gebudgetteerd, gemonitord en geoptimaliseerd worden. De diverse IaaS/PaaS-aanbieders bieden calculatietools om met scenario’s de kosten vooraf te kunnen voorspellen, zoals de ‘AWS Simple Monthly Calculator’ en ‘Azure Price calculator’.
Ook beschermt vrijwel elke IaaS/PaaS-provider de afnemer tegen onbedoelde kosten, met standaard ‘soft limits’ op een account. Dit om te voorkomen dat bijvoorbeeld een geautomatiseerd script een fout bevat, waardoor onbedoeld een extreme hoeveelheid capaciteit wordt aangeroepen die helaas wel dient te worden afgerekend. In de meeste IaaS/PaaS-diensten kunnen limits ook per account aangegeven worden als een basisbescherming tegen onbedoelde kosten.
Additioneel is monitoring van verbruik belangrijk. Eigenlijk is dit het nieuwe capacity management.
Een aantal IaaS/PaaS-providers biedt dit in hun eigen portal. Sommige providers adviseren zelfs proactief over ongebruikte capaciteit, zoals Amazon met de gratis dienst ‘AWS Trusted Advisor’.
Verder zijn diverse tools op de markt die uit meerdere platformen de kosten op actueel verbruik monitoren, grenswaarden bewaken, de afnemer over verbruik informeren en doorbelasting mogelijk maken. Denk hierbij aan producten als de ITB-module van VMware vRealize, Cloudyn of Cloud Cruiser
Selecteer zorgvuldig de kavels. Om de optimale case te realiseren voor cloud hosting, is het kiezen van het juiste model bij de juiste situatie/workload belangrijk.
Soms, bijvoorbeeld bij 24×7 verbruik, blijft immers is een fixed model interessanter dan een pay per use-variant. Overweeg ook een hybride situatie waarbij van een bepaald type dienst 24×7 als baseline in een fixed model wordt afgenomen en de pieken vervolgens flexibel worden opgevangen. Flexibiliteit hoger in de stack dient afgezet te worden tegen daadwerkelijke reductie van kosten in termen van cash out. Soms is ook gewoon de conclusie dat on-premise/private hosten goedkoper is. Daarnaast is het per kavel van belang te kijken naar indirecte kostenparameters zoals connectiviteit. Applicaties of servers die onderling veel dataverkeer hebben dienen bij voorkeur beter niet over twee regio’s geplaatst te worden als inter-regio verkeer een relevante kostparameter is.
Tot Slot
Kijk voor het ten volle benutten van pay per use in de cloud naar bovenstaande punten. Zoek voor een succesvolle businesscase naar de directe koppeling tussen kosten van verbruik en de variabele vraag vanuit de business. Denk aan het gedachtengoed zoals in de Lean wereld: ‘Voorkom verbruik van capaciteit die niet nodig is, elimineer de waste’.
Een goed verhaal waar geen speld tussen te krijgen is, tenminste betreffende de techniek want de opmerking over LEAN lijkt beperkt tot de metering van computer resources terwijl het spook van legacy vooral in de kosten van human resources lijkt te zitten. Elimineer ‘waste’ wordt vaak nog ingevuld met idee van de ijzeren operator wat inderdaad prima werkt voor de delivery maar slecht voor de support.
Oja, capaciteit versus bezettingsgraad resources zijn twee heel verschillende dingen als we kijken naar de service als geheel binnen gedachtengoed van ITIL. In verhaal mis ik nog het ‘cloud enabled’ want schaalbaarheid – naar boven of naar beneden – moet wel ingebouwd zijn in de service. LEAN gaat om de Theory of Constraints en deze zit meestal in de middleware of de daaronder liggende datalaag, de oceaan leegzuigen met een rietje duurt namelijk nogal lang.