Artikel

De economie van de cloud

Twee kanten van een verhaal

"We gaan ons met de cloud flink wat kosten besparen!". Nou, dat is duidelijk dan. Als je kosten wilt besparen (en wie wilt dat niet) dan dit is de cloud de weg te gaan, niet waar? Uiteindelijk, kijkend naar de kosten van (bijv.) Amazon Web Services, daar kun je een server instance starten voor niet meer dan $ 0.02. Twee dollar cent! Dat klinkt natuurlijk fantastisch, maar zoals vaak is de realiteit iets minder rooskleurig. "Wow, dat Amazon is echt wel prijzig!" Deze niet ongebruikelijk reactie hoor ik regelmatig als de genoemde applicatie in de cloud draait en de echte kosten uiteindelijk zichtbaar worden. En het is niet voor het eerst dat dit als een vervelende verrassing komt op het moment dat de eerste rekening op de mat valt.

Inzicht

Vanuit mijn perspectief komen deze twee genoemde extremen voort uit een gebrek aan inzicht, met name in:

  • wat heb ik precies nodig voor het ondersteunen van mijn cloud omgeving;
  • wat is de total cost of ownership van de oplossing in mijn eigen data center.

 
In dit artikel zal ik proberen een aantal handvatten te geven en wat nuancering aan te brengen die bruikbaar zijn in het vergelijken van de kosten van beide oplossingsrichtingen.

Context

Maar eerst wat context. Cloud computing is natuurlijk een zeer breed begrip en wordt te pas en te onpas gebruikt voor een brede varieteit aan diensten. Om de zaken eenvoudig te houden richten we ons in dit artikel op één bepaalde tak van sport: de cloud waarbij je basis IT infrastructuur resources als computer- en opslagcapaciteit kunt huren, bekend als Infrastructure as a Service [1]. Dit is het type cloud computing met het laagste abstractieniveau, wat betekent dat je een relatief groot deel van de technologie stack zelf zult moeten beheren.

Het grote voordeel van deze vorm van cloud computing is echter dat het zeer flexibel is en relatief weinig migratie vereist. Eigenlijk wat je in je eigen data center kunt draaien, kun je meestal ongewijzigd in een IaaS cloud draaien, tenminste vanuit een technisch perspectief. Deze lage drempel maakt IaaS op dit moment dan ook de meest populaire vorm van cloud computing.

Hoe zit het nu met dat rooskleurige plaatje?

Wanneer een IaaS als deployment platform onderzocht wordt, is het erg makkelijk om verblind te raken door die ogenschijnlijk bizar lage prijzen, zoals bijv. de $0.02 per uur voor een Micro server instantie. Dit is echter maar een deel van het verhaal.

Voor niets gaat de zon op

Neem Amazon Web Services als voorbeeld (wat we zullen doen gedurende het gehele artikel). Het wordt als snel duidelijk dat (bijna) niets voor niets is. Naast de genoemde server zijn er meer kostcomponenten waar rekening mee gehouden moet worden.

Data die blijft bestaan als de server getermineerd wordt? Betalen maar! En wil je die data opslag dan ook nog eens gebruiken? Hier is de rekening! Backups? Natuurlijk, maar dit zijn de kosten. En wil je die backup ook nog eens terugzetten? Ook daar hebben we een prijs voor. Monitoring alerts? Nou ja, de boodschap is duidelijk.

Al deze kosten zijn zeer redelijk geprijsd, maar zorgen er met elkaar wel voor dat de totale kosten aanzienlijk hoger kunnen uitvallen dan je op het eerste gezicht zou denken wanneer je over die 2 cent per uur leest.

Dus: zorg dat je een goed begrip hebt van alle kost componenten.

Een server instance is geen server

Waarschijlijk een van de minst begrepen zaken bij Amazon Web Services (AWS) is hoe een bepaalde server type te vergelijken met haar fysieke tegenhanger. Bijvoorbeeld AWS vermeldt de processor capaciteit in ECU [2], wat een fictieve eenheid is die vergelijkbaar is met de capaciteit van een CPU als een 1.0-1.2 GHz 2007 Opteron of 2007 Xeon processor. Dus een processor van let wel 2007, niet echt te beschouwen als een state-of-the-art CPU. IO capaciteit (benodigd voor netwerk taken, benaderen van storage etc.) wordt nog vager aangeduid met behulp van indicators als ‘Moderate’ of ‘High’, zonder daar enige verdere specificatie van vrij te geven wat voor bandbreedte dat nu werkelijk inhoudt.

Aanvullend hierop dient gerealiseerd te worden dat een cloud platform per definitie multi-tenant [3] is, en dus gebruikt wordt door meerdere klanten (tenants) tegelijkertijd. Deze multi-tenancy kan in bepaalde situaties een negatieve invloed hebben op de daadwerkelijk geleverde performance van de server instance. Dit is te adresseren door bijv. een beperkter aantal grotere eenheden (server types of opslag) te alloceren in plaats van meerdere kleine eenheden, maar dit heeft uiteraard ook consequenties voor de daarmee gemoeide kosten.

Kort samengevat: als een server instance opgestart wordt, kun je wellicht niet de capaciteit krijgen die je verwacht te krijgen wat als gevolg heeft dat je meer zult moeten alloceren dan begroot.

Dus: zorg dat je de capaciteit van de verschillende services begrijpt en kunt afwegen ten opzichte van de fysieke tegenhangers.

Elasticiteit is moeilijker dan je denkt

Het meest genoemde voordeel van cloud computing is de mogelijkheid om de capaciteit van je systeem dynamisch aan te passen aan de vraag. In tegenstelling hiervan, meer traditionele systemen worden vaak berekend op de ingeschatte piekvraag, wat nogal eens resulteert in dramatisch onderbenutte systemen. Het virtualiseren van servers is begonnen met het adresseren hiervan, en cloud computing is daar het meest geavanceerde voorbeeld van. Met grote kostenbesparingen als resultaat. Toch?

Nou, ja, mogelijk wel ja. Dat dynamisch (al dan niet automatisch) schalen van systemen is een zeer bruikbare mogelijkheid maar het zou wel eens moeilijk kunnen zijn om er echt goed gebruik van te kunnen maken. Voordat je dit kunt toepassen zijn er een aantal drempels te nemen:

Is de applicatie in staat om de vraag over een variabel aantal server te verspreiden? En kan het ook omgaan met veranderingen daarin zonder de gebruiker daarmee lastig te vallen? Voor een gemiddelde web applicatie is dit meestal niet een al te groot probleem maar meer complexe applicaties of servers die gegevens bevatten (bijv. databases, stateful applicatie servers) wordt dit toch al een stuk lastiger.

  • Hoe zorg je ervoor dat die servers die spontaan gelanceerd worden ook zonder interventie geconfigureerd worden en actief aan de workload processing kunnen deelnemen?
  • En hoeveel tijd is met die configuratie gemoeid? Is dat dan snel genoeg om op een zinvolle manier pieken in vraag op te kunnen vangen?
  • Hoeveel tijd zit er tussen de pieken zelf? Is dat dan lang genoeg om op een zinvolle manier te kunnen terugschalen?
  • Hoe zorg je ervoor dat je grip houdt op de servers die daadwerkelijk draaien, als dat automatisch aangepast kan worden? Bijv. een fout in de configuratie van een opgestarte server zou ervoor kunnen zorgen dat de server zelf wel draait (en kosten met zich meebrengt) maar nooit actief bijdraagt in het verwerken van de vraag.
  • Om fijnkorrelig de capaciteit op de vraag te kunnen aanpassen is het gebruik van kleine capaciteitunits het makkelijkst. Alleen, als gezien in het vorige hoofdstuk, brengen kleine units haar eigen nadelen met zich mee. Een afweging zal dus gemaakt moeten worden.

 
Dus: zorg dat je zeker weet hoe je gebruik kunt maken van het dynamisch schalen, voordat je je rijk rekent.

Allocatie vs. Gebruik

Cloud computing wordt typisch geassocieerd met het Betalen naar gebruik paradigma. Als je iets nodig hebt, betaal je ervoor.

Niet zo snel. Dit gaat op voor een fors aantal elementen maar lang niet altijd. Bijvoorbeeld opslagcapaciteit wat aan een server gekoppeld wordt, is op voorhand gealloceerd en je betaalt daar echt voor de volledig gealloceerde capaciteit en niet voor wat je daadwerkelijk ervan gebruikt hebt.

Een ander voorbeeld is het gebruik van de zogenoemde reserved instances [4], waarmee je capaciteit reserveert voor een lagere prijs voor een periode van één of drie jaar. Hoe meer je initieel betaalt, hoe hoger de korting op het daadwerkelijk gebruik. Echter, voor een variant van deze reserved instances, de Heavy Utilisation variant, betaal je voor elk uur van de maand het tarief voor gebruik, ongeacht of je de server nu gebruikt of niet.

Dus: realiseer je dat er nuances zitten aan de toepassing van het Betalen naar Gebruik principe en voor welke kostcomponenten dit wel en niet geldt.

Dat is helder dan, de cloud is inderdaad te duur.

Wacht even, dit is nu ook weer niet precies wat ik probeer te beargumenteren. Sterker, ik geloof wel degelijk in de beloften van cloud computing en ik denk zelfs dat we daarmee getuige zijn van een fundamentele verandering van hoe wij met informatie technologie omgaan. Wordt cloud computing daarmee overal toepasbaar. Natuurlijk niet. En betekent dit dat de kosten van IT opeens een fractie worden van wat ze waren. Onmogelijk.

Maar als die hogere dan verwachte rekening aan het eind van de maand binnenkomt is het eenvoudig om te vergeten welke service daarmee afgenomen is en daarmee blijft het vaak appels met peren vergelijken.

Wat zijn de kosten van het alternatief dan?

Zoals eerder gemeld, bijna alles komt met een prijs bij Amazon. Uiteindelijk leveren ze een dienst om er zelf iets mee te kunnen verdienen en als uitbater van één van de grootste IT infrastructuren kun je verwachten dat Amazon een goed begrip heeft van de kostendrijvers van zo’n infrastructuur.

Bij het in rekening brengen van deze componenten als afzonderlijke kosten wordt daarmee ook een goed inzicht verkregen in de total total cost of ownership (TCO) [5] van zo’n IT infrastructuur. Daarmee wordt het detailniveau van die rekening misschien wel een soort geluk bij een ongeluk.

Het komt nogal eens voor dat een dergelijk inzicht in de kosten van bijv. een in huis geplaatste oplossing niet voorhanden is. Het risico bestaat dat deze verborgen kosten niet meegenomen worden, waarmee een vergelijking eigenlijk niet heel waardevol meer is.

Ik ben er van overtuigd dat er meer dan voldoende scenario’s zijn waarbij een in huis (of gehoste) oplossing goedkoper is dan een een cloud oplossing, maar ik denk ook dat de verschillen niet spectaculair zullen zijn. En dat dit ook alleen gehaald met een zeer goed georganiseerd IT organisatie.

Dus: zorg dat je een begrip hebt van de TCO van de bestaande oplossing voordat het op kosten vergeleken wordt met een cloud alternatief.

Appels en Appels?

Het lijkt wel een populair tijdverdrijf (tenminste, onder IT professionals) om de kosten van een off-the-shelf server te vergelijken met de terugkerende kosten van een equivalent bij bijv. Amazon. En man, wat is dat Amazon dan duur.

Behalve dat deze vergelijking weinig waarde heeft. Om te beginnen zijn er veel meer kosten dan de aanschaf zo’n fysieke server alleen. Je hebt infrastructuur nodig als opslag, backup equipment, switches, firewalls enz. De server moet gehuisvest worden, in een rack geplaatst, gekoeld, stroom wordt geconsumeerd en tijd zal besteed moeten worden de fysieke instalallatie van dat ding.

En wat gebeurt er als die server de geest geeft (en dat gebeurt). Nou, op zijn best is een reserve server beschikbaar of een bruikbare SLA afgesloten, maar zelfs dan duurt het nog wel even voordat de vervanging klaar is om te gaan. Hoeveel is het je dan waard dat in een cloud scenario zo’n vervanger opgebracht kan worden in minuten, en zelfs automatisch als de configuratie zo ingericht is? En wat betekent het dat, bij een majeur probleem, je de oplossing kan migreren naar een disaster recovery site zonder dat je op voorhand enorme kosten moet maken# en zonder dat een tijdrovende interventie van de cloud provider noodzakelijk is?

In wezen vergelijk je een service met hardware, dat op zijn best slechts een stukje van de puzzel is. Appels met peren.

Dus: bereken de kosten van de IT diensten in plaats van enkel te kijken naar de hardware kosten.

De voordelen van Capaciteit on Demand

Als eerder besproken, het automatisch schalen van een oplossing kan nog wel eens lastiger zijn dan gedacht. Dit betekent echter niet dat dit geen waarde heeft. Dat heeft het absoluut wel, en veel ook! Een systeem wat ontworpen is voor elastisch gebruik in wisselende belastingen kan je veel geld besparen. Hoe meer fluctuaties in de belasting, hoe beter de cloud kan dienen als deployment platform.

Maar er zijn veel meer toepassingen te bedenken waarbij het Capaciteit on Demand paradigma uitermate zinvol blijkt. Wat denk je van het opzetten van een tijdelijk test systeem? Het draaien van een performance test op een representatieve systeem setup? Het testen van een disaster recovery procedure? Het opschalen van systeemcapaciteit voor een grote data migratie dat normaliter dagen dan wel weken zou duren?

Dit zijn slechts enkele voorbeelden, en de kosten van dergelijke toepassingen zijn vaak wel extreem laag omdat hier sprake is van systemen die slechts enkele dagen of weken draaien, en vaak ook nog niet eens 24/7.

Het moge duidelijk zijn dat deze flexibiliteit erg waardevol is en het zijn vaak toepassingen die in een in huis omgeving niet of erg lastig te realiseren zijn.

Dus: probeer in te schatten hoeveel deze flexibiliteit je waard is.

OPEX vs. CAPEX

Wanneer over kosten gesproken worden is het verleidelijk om simpelweg de som van de maandelijkse kosten te vergelijken met een scenario waarbij een grotere initiele investering nodig is, maar met lagere operationele kosten. Maar dat is natuurlijk niet hetzelfde. Iedere financiele specialist kan je haarfijn het verschil tussen Operational Expenses (OPEX) [6] en Capital Expenses (CAPEX) [7] uitleggen. Het is uiteindelijk vanuit financieel perspectief erg aantrekkelijk om de betaling van een groot bedrag uit te smeren over meerdere jaren in plaats van het bij aanvang te betalen. Een principe wat stevig door bijv. credit card en lease maatschappijen uitgenut wordt.

Dus: bij het vergelijken van operationele en eenmalige kosten, neem de aantrekkelijkheid daarvan en eventueel benodigde kapitaalkosten mee in de afweging.

En de conclusie is...

Bewust heb ik getracht te focussen op met name de financiele aspecten van cloud computing in vergelijking met de meer traditionele tegenhangers, en heb me daarbij de Advocaat van de Duivel’s rol aangemeten. En als daarbij de boodschap overgekomen is dat er meer bij komt kijken dan je op het eerste gezicht zou denken voel ik me in mijn opdracht geslaagd.

Maar de economische aspecten zijn slechts één kant van de vergelijking. In plaats van het exploiteren van je eigen data centres met eigen equipment, cloud computing brengt de mogelijkheid om een deel daarvan bij een ander te beleggen met meer focus op je eigen core business. Vanuit dat perspectief is cloud computing veel meer (onderdeel van) een strategische keuze en niet slechts gebaseerd op de harde cijfers.

En soms is cloud niet geschikt, in andere (en ik geloof een groeiend aantal) gevallen wel. Maar dat laat onverlet dat in alle gevallen een goed begrip van de voor- en nadelen benodigd is.

Een paar referenties

Als je googlet voor economic benefits of the clouds krijg je een groot aantal hits, en een aantal daarvan vond ik erg interessant. Een artikel dat in de community aardig wat rumour opleverde was het AWS vs. Self-Hosted artikel [8], inclusief de response van Amazon's Jeff Bar [9]. Een ander interessant alhoewel meer kwalitatief dan kwantitatief artikel is Is cloud computing really cheaper [10]? Als laatste een interessante (cloud powered) interactieve spreadsheet [11] dat een vergelijking maakt tussen cloud en colo kosten is de moeite waard om eens te bekijken.

 

Categorie:   
Auteur(s)
afbeelding van gercograndia
Gerco Grandia
4Synergy - Enterprise / Solutions Architect

Gerco Grandia is een Enterprise / Solutions Architect met een jarenlange ervaring in grootschalige systeem integratie projecten. Gerco is bij uitstek een generalist met diepgang en heeft ervaring met tal van disciplines in de informatie technologie. Hij is werkzaam bij 4Synergy, een netwerkorganisatie voor en door zelfstandige professionals.

 
Reacties
Edekkinga op donderdag 4 oktober 2012 14:02

Gerco,

Een goed artikel dat de verschillende kanten van Cloud Computing belicht want het is namelijk inderdaad niet altijd goud dat er blinkt. Maar helaas ook een beetje eenzijdig omdat je voorbij gaat aan de realiteit en dus met een enigzins conservatieve blik naar Cloud Computing kijkt. Want hoewel er verschillende definities van Cloud Computing zijn spreekt mij persoonlijk die van Chellappa het meeste aan: "Cloud Computing is een computerparadigma waarbij grenzen worden vastgesteld door economische aspecten in plaats van technische limieten."

Maar de werkelijkheid is weerbarstiger omdat het de applicaties zijn die de mogelijkheden bepalen en deze zijn lang niet allemaal ontworpen voor nieuwe computerparadigma. Cloud Computing is in mijn optiek een convergentie van Grid computing en virtualisatie. Hierbij zorgt eerste voor federatie van middelen, uniforme API’s maar ook generieke toegangsmechanismen en de laatste voor dynamisch schaalbare resources. Twee dingen waar veel applicaties uit oude computerparadigma van netwerk computing nimmer voor ontworpen zijn.

Zo wordt schaalbaarheid vaak ingevuld door servers te klonen en een vorm van loadbalancing toe te voegen en hetzelfde wordt gedaan om de betrouwbaarheid te vergroten. Dit 'box' denken heeft ervoor gezorgd dat het aantal servers explosief gestegen is. Virtualisatie van het serverpark werd dan ook als een zegen gezien om de kosten drastisch te verlagen hoewel daarmee feitelijk alleen een verschuiving plaats vond tussen CapEx en OpEx. Want daarmee werden de totale kosten nog niet inzichtelijk en veel 'Private Cloud' oplossingen komen dan ook niet verder dan het in rekening brengen van de server in plaats van de service.

De berekening van de TCO beperkt zich 9 van de 10 keer dan ook tot de CapEx en vergeet allerlei facilitaire kosten als koeling, stroom e.d. maar ook vaak de investeringen in netwerk, opslag, beveiling, software en beheer. Kosten die een Cloud leverancier wel in rekening brengt waardoor het bedrag onder de streep duurder lijkt maar niet altijd is. Vergelijk het maar met het rijden van een oude eend waar je geen onderhoud meer aan doet en die alleen WA verzekerd is of het leasen van een BMW met mobiliteitsgarantie en all-risk verzekering.

Gerco Grandia op dinsdag 9 oktober 2012 13:35

Ik heb gepoogd wat nuance te brengen in de kosten discussie, eerst vanuit het idee dat cloud computing veel kostenbesparing gaat opleveren en daarna vanuit het tegengestelde perspectief, op basis van ervaringen uit de praktijk. In hoeverre dit dan voorbijgaat aan de realiteit ontgaat me.

Wat jij beschrijft als de vergelijking tussen een oude eend en een geleasde BMW komt terug in het 'Appels en Appels' stukje en daar ben ik het uiteraard mee eens. Al zou ik de on-premise variant niet als een oude eend willen bestempelen.

Mijn ervaring is overigens dat de vrij veel applicaties zonder al te veel wijzigingen kunnen draaien op een IaaS (al dan niet public) oplossing. Besluiten hieromtrent blijven vaak hangen op sentimenten en een gebrek aan echte ervaring met dit onderwerp.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.