Prijsdifferentiatie voor hostingplatform

[orf]

Wij (internetbureau) hebben een shared hostingplatform waarop we veel van onze klanten hosten. Dat platform bestaat uit loadbalancers (2), webservers (3), proxies/cachers (2), databases (3), shell, memcached (2), mail, offsite backup, etc.

Storage voor de webservers komt van shared storage (netapps).

Nu vinden we het lastig om prijsdifferentiatie toe te passen voor onze klanten. Natuurlijk kun je het een en ander differentiëren met SLA's, maar het gaat vaak ook om resources. en dat laatste is lastig meetbaar op het shared platform.

Traditioneel wordt differentiatie vaak gedaan op schijfruimte en dataverkeer, maar daar zitten nu juist de kosten niet in. Storage nemen we gewoon per GB af en dataverkeer per mbit.

Als voorbeeld: We hebben enkele scholenwebsites. Deze websites hebben veel foto's en gebruiken relatief veel schijfruimte, maar de websites zijn niet complex en verantwoorden geen hoge prijs.

2e voorbeeld: Een API die complexe berekeningen doet. Weinig schijfruimte, weinig dataverkeer, maar gebruikt (opnieuw relatief) veel resources in ram en processor.

Iemand goede ideeën om dit goed en eerlijk te beprijzen? Eventueel met een schatting vooraf en een daadwerkelijke afrekening achteraf zoals bijvoorbeeld energiemaatschappijen doen.

[Bl@ckbird]

Kijk eens hoe Amazon dat doet:
http://aws.amazon.com/ec2/pricing/

Amazon heeft ook een calculator waarmee je kan berekenen hoeveel je per maand ongeveer kwijt bent:
http://calculator.s3.amazonaws.com

[orf]

Voor een prijsmodel kan ik daarnaar kijken, bedankt.
Het is natuurlijk wel lastig om erachter te komen hoe Amazon dat berekent en meet. Ik kan niet zien hoeveel ram of processor een klant gebruikt. Ik kan nu hoogstens bij piekbelasting enkele pieken eruit pakken, maar dat geeft niet het gemiddelde gebruik aan.

[Dutch2007]

2 betaal methodes introduceren? betalen per CPU cycle of per storage...

Iets van FUP in contract? en bij teveel gebruik (aka jullie maken dr geen winst op....) voorstel voor de andere methode? of natuurlijk zoals amazon het doet.. alleen voor de cpu cycles een factuurtje maken....

[Bl@ckbird]

Eerst ff een disclaimer dat ik alleen met Cisco werk en je dus alleen daarover een antwoord krijgt.

Fabrikanten als Netapp, Cisco (Met Cisco UCS blade omgeving) en VMware hebben een API waar je tegenaan kan programmeren. Je hebt orchestration software die de hele datacenter stack kunnen managen. (Compute, storage, netwerk, hypervisor, applicaties, etc.)

Klanten kunnen inloggen in een portal en dan kiezen uit een beperkt aantal "instances." Dit zijn een aantal typen VM's met x aantal cores, storage, etc. (Een soort S, L, XL, XXL aan VM's waar men uit kan kiezen.) Om een VM x aantal uur te runnen, staan er x aantal credits tegenover. Aan deze credits kan je weer een prijs hangen in concrete Dollars of Euro's.

In de opensource wereld wordt OpenStack veel gebruikt. Cisco heeft UCS Director. (Wat voorheen Cloupia was.) Daarnaast heeft Cisco Intelligent Automation for Cloud (Cisco CIAC).

UCS Director / Cloupia support ook Dell en HP servers, maar nu het van Cisco is verwacht ik niet dat hier veel geld in development gestoken wordt. Soms heeft een derde partij simpel weg geen API en houdt automatisering ook op.

UCS Director heeft veel processen al out-of-the-box. (Zoals het provisionen van een LUN op een NetApp storage array.) Maar het is meer een kant en klare oplossing. Cisco CIAC is veel meer te customizen en vereist een veel langere installatie en integratie. Met UCS Director kan je bijvoorbeeld een virtual desktop in een VDI omgeving provisionen. Met Cisco CIAC kan je bijvoorbeeld ook de telefooncentrale voor een nieuwe gebruiker inregelen. (Als deze telefooncentrale een API heeft.) Je kan bijvoorbeeld ook een workflow creëren waarbij je frontend servers, backend servers, database servers, netwerk (VLAN's, etc.), storage (LUN's, FC zoning, etc.) Loadbalancing, etc. kan provisionen. Dus niet alleen een enkele VM, maar meerdere VM's zodat je een service kan provisionen via een portal.

[orf]

Dank voor je uitgebreide antwoord.
We gaan niet helemaal naar betalen per tik/gebruik/credit. Voor onze klanten kiezen wij de setup en doen we het beheer.

Ik kan hier wel iets mee, wat gaan we meten en vervolgens afrekenen en wat rekenen we aan vaste kosten.

[Bl@ckbird]

Aan de ene kant is betalen naar gebruik één van de aardige dingen aan cloud-diensten. Aan de andere kant willen klanten ook graag weten waar ze aan toe zijn. ( Dus geen onverwachte kosten hebben / fixed bedrag per maand afrekenen. ) Ik denk dat je daar een beetje een evenwicht in moet zoeken.

Mocht je meer willen weten, DM me dan even. Ik hou dit topic niet continue in de gaten.