'Betalen naar gebruik' staat op gespannen voet met door cfo's gewenste voorspelbaarheid. In de consumentenwereld gaan we massaal voor 'flat fee'. Toch is er een hele 'game theory' wereld die een overvloed aan prijsstrategieën en -modellen heeft bedacht. Naar mate de vergelijkbaarheid van cloud diensten toeneemt (en daar is nog een flinke weg te gaan), zal het prijsmodel als onderdeel van de marketingmix een belangrgijkere rol gaan spelen.
Afgelopen week las ik wat financiële persberichten van beursgenoteerde bedrijven. Het viel me weer eens op hoeveel belang er wordt gehecht aan voorspelbaarheid van resultaten. Bij voorspelbaarheid hoort van tevoren weten wat onder andere je kosten gaan zijn, en dat staat veelal op gespannen voet met ‘betalen naar gebruik’. Vaste maandelijkse kosten voor ict passen dan eigenlijk veel beter bij die gewenste voorspelbaarheid. Het is niet voor niks dat wij ‘cloud evangelisten’ regelmatig ons best doen om financieel georiënteerde managers te overtuigen. Ze worden weliswaar aangesproken door ‘lagere kosten’, en ‘van Capex naar Opex’, maar betalen naar gebruik is wel .. een beetje onvoorspelbaar.
Voorkeur
Diezelfde week las ik wat marktanalyses voor data- en telefoniediensten. Het is overduidelijk: consumenten hebben een voorkeur voor flat fee. Van tevoren weten wat je die maand kwijt bent. Lekker veilig, en dus niks ‘betalen naar gebruik’. Een opvallend verschil met een van de kenmerken die we toedichten aan cloud dienstverlening. Wel blijkt dat ‘light users’ toch vaker terugvallen op betalen naar gebruik terwijl de ‘heavy users’ een voorkeur voor de flat fee blijven houden.
In de zakelijke wereld kom je prijsmodellen voor cloud diensten tegen die spelen met bijvoorbeeld gereserveerde versus niet-gereserveerde capaciteit, met verschillende dienstenniveaus (met de welbekende smaken goud, zilver, brons), met volume kortingen, non-lineaire prijsstelling, multi-tiered pricing en natuurlijk prepayment discounts. Sommige cloud diensten kennen een beperkte set van prijsparameters, terwijl andere diensten er een sport van lijken te maken om zoveel mogelijk “keuzeknopjes” te bieden. Dat geeft je als klant veel keuzemogelijkheden, maar voor niets gaat de zon op: net als met veel software licentie prijsmodellen moet je dan wel de moeite voor nemen om erin te duiken, om het snappen en om de juiste keuzes te maken.
In de consumentenwereld komen we vaak het prijsmodel (al lijkt dat in dit geval een groot woord) ‘gratis’ tegen. Door economen vertaald in de ‘freeconomy’. Dit prijsmodel wordt veelal toegepast in social media diensten, zoals Facebook en LinkedIn. In ruil voor informatie over wie je bent, wat je voorkeuren zijn, et cetera, kun je hier, vaak tot een bepaalde bovengrens qua consumptie c.q. afname, gratis gebruik van maken. En wie meer wil, moet gaan betalen. Ook Dropbox en Angry Birds zijn voorbeelden van diensten c.q. producten die gratis te gebruiken zijn. In het geval van Angry Birds verdienen de makers vervolgens goed geld met t-shirts, koffiemokken, pluche vogels en speciale flip-flops.
Prijsmodellen cloud wereld
En zo liet ik mijn gedachten eens gaan over de verschillende prijsmodellen die we in de cloud wereld zo al tegenkomen. Wat zouden er nog meer voor prijsmodellen mogelijk zijn, in de zakelijke en/of de consumentenwereld?
‘Spot pricing’ is zo oud als de weg naar Rome. Door het matchen van vraag en aanbod, populair gezegd door de markt haar werk te laten doen, wordt bepaald wat op moment X de prijs van product of dienst is. Morgen kan het anders zijn. Dit mechanisme zien we veelal in “commodities, in bv. de grondstoffenhandel. Maar ook de aandelenmarkt werkt in feite volgens dit principe. Voor cloud dienstverlening geldt dat naar mate de vergelijkbaarheid van diensten groter wordt, een dergelijk marktmechanisme steeds meer voor de hand ligt. Overigens is er, zelfs op infrastructuurniveau, nog wel een weg te gaan voordat we appels met appels kunnen vergelijken. Een nuttige bron van informatie in deze is bv. Cloud Spectator.
En dan hebben we natuurlijk de wereld van de veilingen. Ebay, marktplaats, afijn, voorbeelden genoeg. Ideaal voor koopjesjagende consumenten. Maar voor op stabiliteit gerichte bedrijven? Enerzijds neig je dan naar ‘nee’, maar het verschil tussen spot pricing en veilingen is uiteindelijk zo groot niet meer.
Overigens zijn er de nodige variaties binnen het thema veilingen mogelijk. De pure vorm waar je het eerst aan denkt namelijk een open veiling met zichtbare bieders die publiekelijk hun bod kenbaar maken, wordt ook wel de ‘English auction’ genoemd. Dan is er ook bijvoorbeeld de ‘Vickrey auction’ waarbij de prijs die de winnaar betaalt gelijk is aan het bod van de hoogste niet-winnaar. En natuurlijk is er een ‘Dutch auction’, want wij Nederlanders hebben de afgelopen eeuwen op het gebied van gehaaidheid in internationaal handelen ons steentje wel bijgedragen. Een ‘Dutch auction’ is een veiling waarbij de veilingmeester begint met een hoge vraagprijs die telkenmale een stapje verlaagd wordt totdat iemand zegt ‘ja, ik wil’. Dit type veiling wordt vaak gebruikt als de verkopende partij snel van zijn goederen af wil. In theorie zijn de strategie en de resultaten van deze veiling gelijk aan die voor de ‘first-price sealed-bid auction’. Hierbij doen alle bieders een eerste bod in een gesloten enveloppe. Deze biedingen worden vergeleken en degene met het hoogste bod wint. Deze methode hebben we diverse malen, met kleine of grotere variaties, teruggezien bij veiling van bandbreedtespectra.
Of wat te denken van de ‘Paris metro pricing’, waarbij gelijke resource pools verkocht worden tegen verschillende prijzen? Biedende partijen dienen een afweging te maken tussen de prijs die men bereid is te betalen versus het risico dat een ander er mee van door gaat.
Veelvoud
Afijn, zo is er een hele ‘game theory’-wereld die een veelvoud aan prijsstrategieën en modellen heeft bedacht, en nog steeds nieuwe bedenkt. Ik zie daar echter nog niet veel van terug in de wereld van cloud dienstverlening. Financieel getinte concurrentie tussen cloud diensten(aanbieders) vindt veelal nog steeds plaats op basis van de prijs, en minder op basis van het prijsmodel. Ook al omdat het vergelijken op basis van prijs al moeilijk genoeg is. De term ‘commoditizing’ wordt weliswaar vaak gebruikt om de toekomst van cloud computing te omschrijven, maar de realiteit vandaag de dag is dat het gebrek aan standaardisatie het vergelijken van cloud diensten en bijbehorende prijzen en prijsmodellen er niet eenvoudiger op maakt. Een van de redenen dat het eerder genoemde Cloud Spectator bijvoorbeeld de performance van twintig van de grootste IaaS service providers monitort, op basis van meer dan veertig tests die kijken naar zaken als cpu, ram, storage, netwerk en database prestaties. Drie keer per dag, elke dag weer, om grip te krijgen op eventuele variabiliteit in de prestaties van een multi-tenant omgeving.
Het wordt interessant om te zien hoe dit zich ontwikkelt. De ervaring van de afgelopen 25 jaar professionalisering en uitbesteding van ict-dienstverlening leert ons dat vergelijkbaarheid zal toenemen, waardoor ruimte zal ontstaan voor concurrentie op prijsmodellen in plaats van op prijs alleen. Maar hoe zich dat gaat verhouden tot de behoefte van cfo’s aan voorspelbaarheid …?
Marc,
Spot pricing en veilingen vind ik wel een interessant idee in combinatie met ‘cloud bursting’ voor tijdelijke en non-sensitive workloads. Tenminste als je deze in een koffertje kan stoppen en eenvoudig ergens anders weer uit kunt pakken. Op die manier hoef je eigen omgeving niet te sizen voor piekbelastingen maar moet je nog wel de workload ‘commoditizen’ Maar is dat is eigenlijk niet veel anders dan virtuele appliances maken en waar DevOps uiteindelijk om gaat?
Betreffende de informatie van Cloud Spectator vraag ik me af in hoeverre deze doelbepalend is, hoe benchmarks te vertalen naar behoefte.
Ewout,
Yep, portabiliteit van workloads en interoperabiliteit van cloud dienstverlening/platforms, en dan spot pricing, da’s het (althans “een”) idee. Dat is gelieerd aan DevOps, aan virtuele appliances, maar gaat verder en vereist gebruik van open standaarden op infraniveau (zoals OpenStack) en platformniveau (zoals TOSCA en OSLC). En het valt me toch op hoe weinig daar, in verhouding, over gesproken wordt. Je kunt zeggen dat dat voer voor architecten is en dus voor anderen niet interessant, maar … juist het onderwerp hoe te kunnen schakelen tussen verschillende cloud diensten zou toch voor niet-architecten een zeer business-relevant onderwerp moeten zijn. Hmmm, misschien wel iets om daar eens wat over te gaan schrijven.
T.a.v. de vertaalslag van benchmarks naar behoeften moet ik zeggen dat ik ook nog wat worstel. Komend uit de “oude” outsourcingswereld heb ik jarenlang geacteerd in een wereld die zich kenmerkte door op een steeds meer businessniveau interacteren tussen klant (demand) en leverancier (supply). Kort door de bocht: “vertel me functioneel je wensen en ik ga kijken of het op onze standaarddienstverlening past, en daar waar dat niet het geval is, praten we over de kosten van maatwerk.” Nu in de ontwikkelingen onder de noemer “cloud” merk je dat je op infrastructuurniveau als klant vrij veel technsiche kennis moet hebben om de 184 keuzemogelijkheden in het menu van je IaaS leverancier op de juiste manier te selecteren. Los van dat in veel gevallen OS management niet in de cloud dienstverleningstack zit. Op zich prima, maar dat is dus weer een duik terug in de techniek, voor klanten die de afgelopen 15 jaar juist steeds minder “techniek gingen praten”. (Opmerking: op PaaS niveau is het gat tussen “business praat” en de supply kant al weer kleiner.) Beetje paradoxaal, niet? Maar dat kan o.a. betekenen dat er een rol is voor partijen die tussen die niets-meer-van-techniek-wetende klanten en IaaS leveranciers, en wellicht is dat nou juist de rol in de keten voor veel lokale dienstverleners. Ga niet klrampachtig proberen om je eigen super geoptimalsieerde energiecentrale te bouwen, want daar heb je de schaalgrootte en de financien niet voor. Richt je op het gebruik maken van die ketelhuizen van de grote spelers, en zorg voor de warme vertaalslag tussen lokale klanten en dat grote ketelhuis. Anyway, stof voor later.
Groet, goed weekend,
Marc
Bij een pricemodel voor een flexibel product zoals cloud computing (betalen naar gebruik) lijkt me het prettig dat het begrijpelijk en doorzichtig is. Zodat de klant na kan gaan wat hij kan verwachten. De klant moet wel inzicht in zijn eigen gebruik moeten hebben. Niet eenvoudig Moest denken aan de telefonie abonnementen, niet altijd eenvoudig te doorgronden en vol verrassingen.
@Ewout @Marc De relatie met DevOps vind ik moeilijk te begrijpen. DevOps gaat toch over de samenwerking tussen ontwikkeling en beheer en dat het handig is beheer te betrekken in een ontwikkelings traject? Ik ben benieuwd misschien heb ik het niet begrepen, ik ben geen DevOps Certified Engineer…..
@Louis
Om het heel simplistisch te zeggen is DevOp een soort van Configuration Management op steroïds hoewel dit misschien een beetje te krap en teveel vanuit mijn eigen beroepsdeformatie gedefinieerd is. Maar zoals je zelf al aangeeft moet je eerst inzicht hebben in eigen gebruik voordat je kunt bepalen wat voordeliger is, het meten is weten principe.
Laat dit nu vaak achterwege blijven waardoor we telkens proberen vierkante blokjes door ronde gaatjes te slaan. Want we meten misschien dan wel de belasting van de resources maar vaak zegt dat niet zoveel over de service. Vandaar ook mijn vraag hoe de benchmark van Cloud Spectator te interpreteren omdat als we over prijsmodellen spreken de kosten per transactie vaak onduidelijk blijven. Commercieel gezegd: “Hoe betaalbaar is schaalbaar”
@Ewout De Cloud Spectator is een leuke site al moet je wel betalen op het moment dat het over tarieven gaat. Wat betekent die vergelijking als, zoals @Marc schrijft, niet alle cloudproviders dezelfde technieken gebruiken? Ik denk aan de andere kant de cloud voor de meeste klanten vooralsnog een model voor het afnemen van machines en infrastructuur en misschien een enkele service. Dat maakt vergelijken eenvoudiger. Vraag me ook af hoeveel klanten werkelijk al gebruik maken van geavanceerdere cloudtechnieken voor het omgaan met gedistribueerde data en computing. Het lijkt me al heel wat als de klant er in slaagt dat hij ongeveer weet wat hij kwijt is en niet verrast wordt door een konijn uit de hoed van het prijsmodel. Ik kan soms denken dat transparantie niet altijd het doel is van een prijsmodel… Moet toch weer denken aan de telecom markt.
Nog even DevOps. Als de ontwikkelafdeling eindelijk klaar was na vele maanden werk dan werd het eindproduct overgedragen worden aan de beheerafdeling. Neeeee, zeiden die dan, dit voldoet niet aan onze standaard, wij verwachten iets anders, de logs deugen niet noem het maar. Dan moest de ontwikkelafdeling weer terug aan de slag. Wat ik schrijf is heel gechargeerd maar uit dit probleem komt die DevOps trend vandaan naar mijn mening. Ook beheer (operations) als deelnemer van het ontwikkeproces om dit soort verrassingen te vermijden. Het is die lopende band benadering van de software ontwikkeling en het komt voort ook uit de Agile (Scrum) beweging (religie). Continously delivery en integration zijn de trefwoorden die bij DevOps horen. Dus in een korte sprint worden de nieuwe features geimplementeerd, alles wordt uiteraard geautomatiseerd getest waarna ook de automatisch de deployment wordt uitgevoerd zodat je je wijziging meteen live hebt. De bedrijfszekere nimmer falende software productie straat die levert op bestelling en altijd op tijd. De management droom lijkt me. Ik hoorde vorige week nog zeggen, de klant wilde iedere dag een nieuwe versie van de software ivm continous delivery policy van het bedrijf. Ik dacht alleen, he wat onrustig en de klant heeft er niets van begrepen. Wat moet je ermee? De werkelijkheid is weerbarstiger.
Volgens mij zijn er (ook binnen de IT) te veel elementen die van invloed kunnen zijn op de prijs.
In het geval van Cloud computing hebben we al te maken met netwerk, bandbreedte, servercapaciteit, geheugen, onderhoud, beheer etc. En daarvoor geldt dat je alles goedkoop kunt hebben ingekocht, maar dat als – bijvoorbeeld – bandbreedte schaars is de prijs toch nog fors op kan lopen.
Wie garandeert mij dat alle beschikbare bandbreedte ook daadwerkelijk beschikbaar wordt gesteld en dat er dus niet een kunstmatig tekort aan bandbreedte wordt gecreëerd om de prijs op te drijven? Dit gebeurt al eeuwenlang met andere producten en diensten dus waarom niet in de Cloud.
Welk prijsmodel je daarom ook kiest, zolang het (op onderdelen) beïnvloedbaar is, is nauwelijks te controleren of je de juiste prijs betaalt.
Dat de service modellen wijzigingen onderaan in een cloud tijdperk lijkt mij evident. Dat vergt dus ook wijziging van mensen en CFO’s zijn mensen.
Het beheersen van prijzen valt gewoon onder een stukje governance. Je hebt budgetten die ingeschat worden door de juiste mensen en daarop stel je alerts in voor als er grote afwijkingen ontstaan. Kosten breng je omlaag door voorruit te betalen en het onzeker stukje vast te pinnen op betalen naar gebruik. Als je een case maakt waarin je aan kunt tonen dat de kosten zullen dalen bij een flexibel betaalmodel zul je echt de kans wel krijgen van een CFO. Het blijft wel mensenwerk.
Maar vasthouden aan de oude manier van werken zal steeds lastiger houdbaar zijn.
Ook het kunnen koppelen van kosten aan groei en krimp (betalen per medewerker) zal een CFO aanspreken. Bij veel diensten is dit ook te realiseren.
Charge back van IT middelen intern, zie ik nog steeds niet goed van de grond komen. Juist met cloud services zou dit goed te realiseren moeten zijn.
Competitie op prijsmodellen in plaats van prijs is wat mij betreft geen of/of vraag. Ik verwacht dat de ontwikkeling van de clouddiensten net zo gaat verlopen als andere nieuwe diensten.
In de beginfase worden de prijs en prijsmodellen vooral gedicteerd door de aanbodkant. Vanuit de aanbodkant is een pay-per-use model verreweg het handigst, zodat alle resources die de leverancier nodig heeft om zijn dienst te kunnen leveren betaald worden. De afnemer draagt al het risico.
Daarna gaat onder druk van de gebruikers het risico verschuiven naar de leverancier. Die heeft de middelen om het gebruik van grote groepen klanten te voorspellen en daar zijn resources op in te richten. De klant wil voorspelbaarheid.
Uiteindelijk gaat de leverancier met zijn klant meedenken hoe deze met de dienstverlening van de leverancier zoveel mogelijk resultaat kan boeken. Met een gezamenlijk risico gaan leverancier en klant samen resultaten boeken.
De CFO moet dus nog even de onvoorspelbaarheid van het pay-per-use uitzitten, maar uiteindelijk is ook hij in de wolken met de clouddienstverlening. En dat moment komt snel dichterbij.