Kostenbesparing wordt door bedrijven nog te vaak gebruikt als het belangrijkste argument om voor de cloud te kiezen. Dat kan erg interessant zijn, maar vergeet niet dat dit prijsvoordeel ergens vandaan moet komen. Uit onderzoek is gebleken dat cloud-dienstverleners dit prijsvoordeel kunnen bieden door zelf te besparen, en dan met name op zaken als dienstverlening en compliancy. Klanten blijken daar juist wél behoefte aan te hebben.
Het veronderstelde prijsvoordeel van de cloud wordt in veel gevallen waargemaakt. Maar grote organisaties die hun bedrijfs-it aan het datacenter hebben uitbesteed, zullen allemaal erkennen dat het niet per definitie goedkoper is. Tenminste, als je serieuze afspraken maakt en alle details die voor jouw organisatie relevant zijn verankert in een sla. Marktanalist Forrester publiceerde recent een onderzoek naar de dienstverlening van cloud-providers. Daaruit bleek dat 60 procent van hen wereldwijd tekortschiet op het vlak van klanttevredenheid en compliancy. Dat is vrij ernstig voor een ‘booming business’ als cloud.
Persoonlijke SLA
In het rapport van Forrester gaven alle 275 ondervraagde bedrijven aan negatieve ervaringen te hebben met de communicatie bij storingen. Dit is een heel duidelijk signaal dat cloud-dienstverleners niet echt goede service leveren. Cloud wordt meestal gezien als een standaardproduct, waarbij vooral wordt gekeken naar de techniek. Maar wijkt de gewenste dienst af van de standaard of treedt er onverhoopt een storing op, dan lopen veel dienstverleners hopeloos achter de feiten aan. Dat is misschien ook niet zo vreemd in de relatief jonge cloud-markt, waar net zo jonge en onervaren bedrijven elkaar de tent uitvechten.
Bedrijven die op zoek zijn naar goed verankerde service-levels, doen er daarom verstandig aan om verder kijken dan een standaard sla (service level agreement). Voor hen moet het mogelijk zijn een persoonlijke Sslaaf te sluiten, met garanties op de hardware, performance, de reactietijden bij problemen en bij het doorvoeren van changes. Dit soort maatwerk is noodzakelijk voor elke organisaties die voor zijn business afhankelijk is van it.
Bedrijfskritische diensten
De belangrijkste elementen in een sla zijn vaak de uptime-support-garanties, zeker als het gaat om het faciliteren van bedrijfskritische it. Er zijn echter ook allerlei compliancy-regels waar bedrijven zich aan dienen te houden. Regels op het gebied van datasecurity en rapportage bijvoorbeeld, en die verschillen per industrie of branche.
Veel dienstverleners hebben daar helemaal geen kennis van en schuiven die verantwoordelijkheid graag af naar de klant. En die wilde nu juist van al zijn operationele it-verantwoordelijkheden af! De oplossing is om een cloud-dienstverlener te zoeken, die wel kennis heeft van dit soort regels en compliancy als onderdeel van de leveringsvoorwaarden en de sla kan leveren.
Business intelligence
De grootste uitdaging voor een cloud-dienstverlener is het combineren van strakke bedrijfsprocessen en procedures met een persoonlijke dienstverlening aan klanten. Voor de eerste twee zaken zijn tal van oplossingen beschikbaar, maar bij het laatste komt nog iets ongrijpbaars kijken. Een persoonlijke aanpak vereist dat je snapt wat de behoeften zijn van je klant. Dat je goed begrijpt aan welke regels hij moet voldoen, welke services voor hem de meeste waarde hebben en aan welke communicatie hij behoefte heeft. Kortom: de cloud mag volgens mij wel wat persoonlijker worden.
Dat daar wellicht iets hogere kosten tegenover staan, lijkt me evident. Alle goede dienstverlening heeft immers zijn prijs. Ik denk dat veel meer cloud-providers op deze manier met hun klanten bezig zouden moeten zijn. Dat zou een grote stap voorwaarts zijn voor de branche.
Tijd geleden heb ik een artikel op deze site gepubliceerd: Op welke wolk ga je zitten?
https://www.computable.nl/artikel/magazine/5414163/5215853/op-welke-wolk-gaat-u-zitten.html
(Sla wat persoonlijke trekjes in de reacties over)
Ik heb geprobeerd een aantal verschillende onderwerpen rondom Cloud onder aandacht te brengen. SLA en de prijs waren er voorbeelden van.
Cloud is niet goedkoop en de prijs die je ziet is “van af” prijs. Op het moment dat je je bedrijfsprocessen daarop wilt baseren dan kom je de tekortkomingen en de aanvullende zaken tegen waarna je andere prijs onder ogen krijgt.
Pieter, in je artikel noem je “Cloud”. Ik raad je aan om wat meer gericht te zijn. Het is een groot verschil als je 1 applicatie afneemt (SaaS) of je totale infrastructuur afneemt (IaaS) De scope van je Cloudproject bepaalt deels de behoefte aan zaken zoals uitgebreid SLA of de aanwezigheid van eco-systeem rondom je cloud-oplosing.
En…….het eco-systeem dat je rondom je oplossing nodig hebt bepaalt verder de hoogte van het prijskaartje!
Pieter de Haer, het klinkt allemaal heel logisch wat je schrijft, toch wil ik wat toevoegingen en kanttekeningen plaatsen.
Door heel algemeen cloud te noemen maak je dingen wel mistig. Wat bedoel je precies met cloud? Zijn dat ook hosting partijen? Kun je een paar voorbeelden noemen van de bedrijven en diensten waarover je schrijft?
Van mij hoeft de cloud *niet* persoonlijker, als je persoonlijke hulp wilt kun je die gewoon met een dienstverlener afsluiten en juist niet met de cloud leverancier zoals bijvoorbeeld Amazon, Microsoft, Google.
Dan zijn er twee soorten verstoringen: Verstoringen door kennis gebrek en misconfiguratie ofwel inhoudelijk doet iets het niet goed. En verstoringen aan de cloud leverancier kant. Iets is niet (voldoende) beschikbaar door een grote verstoring. Ik ben met je eens dat de communicatie tijdens dit soort verstoringen vaak niet zo goed is. Gelukkig zie je dat dit steeds minder voorkomt en bijvoorbeeld Google heeft goede kanalen waarop je kunt abonneren zodat je als beheerder weet dat iets tijdelijk niet goed functioneert.
Een (persoonlijke) SLA met een cloud provider gaat je niet helpen. Als het stuk is is het stuk. Een zorg verzekering voorkomt ook niet dat je ziek word. Wat gaat een SLA dan voor je oplossen? Dat je een boete clausule uit kan laten voeren als de dienstverlening ondermaats is? In mijn ogen een ouderwetse gedachte.
In mijn ogen gaat het vaak fout bij bedrijven die alleen cloud leverancier zijn in hun marketing. Bij de goede leveranciers komt downtime door grote verstoringen nauwelijks voor en kun je daarop je architectuur op aanpassen. Hoge beschikbaarheid is veelal geen rocket science.
Veek voorbeelden zijn ook niet uniek voor cloud computing leveranciers maar gaan gelijk op voor alle IT dienstverleners, ook bij hosting and housing.
De essentie van cloud computing is on-demand selfservice. Daar komt niets persoonlijks bij kijken. Juist als je als bedrijf minder IT savvy bent neem je dus een persoonlijke dienstverlener in de arm die de brug slaat tussen cloud computing en je business. Dan houdt je de kosten en uitgaven juist zo mooi gescheiden.
Dus ik ben het niet met je eens dat cloud-providers persoonlijker moeten worden. Als laatste wil ik nog toevoegen dat je wel degelijk persoonlijke (enterprise) support kunt inhuren en die is wel degelijk goed, maar dit is een optie en dat moet ook zo blijven.
Reza je schrijft : “Cloud is niet goedkoop en de prijs die je ziet is “van af” prijs.”
Ik zou dat iets meer willen verfijnen.
“Cloud hoeft niet per se goedkoper te zijn”.
In mijn werk kom ik steeds meer voorbeelden tegen dat cloud computing veel goedkoper is dan on-premises. Door bijvoorbeeld ETL processen via AWS Lambda te laten lopen, een performant data warehouse, een statische website hosten (productie website kost me nog geen 10 cent… per maand!) met een zeer hoge uptime en snelheid en zo kan ik nog wel tien voorbeelden geven.
Waar cloud computing vaak duurder is, is als je bij je provider nagenoeg dezelfde dingen doet die je altijd al deed.
“Uit onderzoek is gebleken dat cloud-dienstverleners dit prijsvoordeel kunnen bieden door zelf te besparen”
Briljant 😛
Cloud dienstverleners zijn niet te vertrouwen. Andere dienstverleners natuurlijk ook ook niet overiens. Dus toch maar de kennis in huis halen. Maarja, welke kennis ? Die van de interne sysadmin die je net ontslagen of gedemotiveerd hebt 🙂 of de externe cloud specialisten, zelfbenoemd dan. En kies je dan Pieter, Reza of Henri ? Ik zou Henri kiezen. Ze zijn vast allemaal even duur en Cloudhandelsreiziger Henri belooft het meeste 🙂
@Henri
Voordat je ETL kunt doen moet je de data zelf verplaatsen, een batch over de ESB levert nogal wat problemen op met de bussen als we kijken naar het All People Seems To Need Data Processing verhaal. Voor alle duidelijkheid, het technische concept van cloud computing heeft evenveel met ETL te maken als de uitbesteding van een statische website naar een provider.
Ewout,
Ik ben al off-topic door in te gaan op of de cloud goedkoop is of niet, maar ik kan de verleiding niet weerstaan nog verder off-topic te gaan door te reageren op jouw reactie.
Je schrijft batch welke een onderdeel kan zijn van ETL en da’s iets anders dan (near) real-time verwerking. Batch is trager en dat is okee.
Traditioneel heb je heel wat nodig voor ETL. Opslag, ijzer voor verwerking, software voor verwerking, et cetera. Zo’n server is vaak best dik uitgevoerd en staat nagenoeg altijd aan. Ook de software licenties zijn vaak niet mals en als je tijdelijk wilt opschalen gaat dat snel in de papieren lopen. Oja, en als je een schaduw omgeving wilt om te testen kun je de kosten al bijna maal twee doen.
Meet AWS.
Alle data drop je in een S3 bucket (storage). Dit kost nagenoeg niets, is goed schaalbaar en zeker voor batch processen heeft dat mijn inziens voor veel scenario’s prima performance. Een Lambda proces is code die draait op een systeem waarvoor je alleen betaald als deze iets doet: Je hebt dus geen virtuele server nodig. Deze triggert als er een bestand in een S3 terecht komt. Er kan dan code uitgevoerd worden die bijvoorbeeld de inhoud checkt op consistentie en type inhoud (JSON / XML / CSV) en bijvoorbeeld ook wat voor data (personen, orders, transacties) en voert dat bijvoorbeeld een verwerkingingslag uit om deze data in een datawarehouse te proppen in het juiste formaat (transform / load). Ook hiervoor gebruik je de schaalbare dienst geen virtuele server. Als de data verwerkt is kun je nog allemaal logica uitvoeren zoals email versturen, push berichten, of wat dan ook. Ook hiervoor geld: Je betaald alleen de zeer tijdelijke compute, nog steeds geen virtuele server nodig. De kosten van dit proces zijn extreem lager dan een traditionele omgeving. Bovendien zeer schaalbaar, robuust en je betaald alleen voor het tijdelijke gebruik. Niets geen containers / virtuele server / dockers of wat dan ook. Uiteraard betaald je voor de ontwikkelaars die het allemaal moeten regelen, maar die kosten heb je traditioneel ook. de kosten voor de functie zelf zijn onwaarschijnlijk laag.
Wat heeft site-hosting en ETL met cloud computing te maken? Alles dus. Als je het doet zoals je het altijd hebt gedaan dan is er nu een kans om het beter, sneller en goedkoper te doen.
Oja, en je dacht natuurlijk wat moet je nu met een statische website? Dat statische was een instinker, het betekent namelijk niet dat je geen nieuwsberichten en dergelijke kunt plaatsen en dat de site dus onveranderlijk is. De manier waarop je de site dynamisch maakt is gewoon anders dan het traditionele model van de CMS-en van deze wereld.
Zoals Felix zegt : In lijk wel een Cloudhandelsreiziger 🙂 Maar goed, het duurt wellicht nog even voordat de rest beseft wat cloud computing betekent voor de technische mogelijkheden om je technische zaken te doen.
Om dan toch nog on-topic te komen.
Waarom hoeft de cloud niet persoonlijker? Ook dat heeft te maken met traditioneel versus hoe het nu kan/gaat.
@Henri & @Reza, jullie hebben natuurlijk gelijk wanneer je zegt dat “cloud” een erg breed begrip is. Het onderzoek van Forrester was gericht op de commodity public cloud services. Daar ontbreekt de persoonlijke service, wat op zich logisch is.
Ik denk dat het persoonlijke belangrijker wordt wanneer de oplossing complexer is. Bijvoorbeeld bij een bedrijfskritische applicatie die op een hybride omgeving van zowel virtuele- als fysieke servers draait. Het persoonlijke begint dan al bij het ontwerp van de omgeving. Op basis van de gewenste SLA wordt dan een architectuur opgezet. Een SLA gaat dan niet alleen over uptime, maar ook over bijvoorbeeld responsetijden, performancegaranties en security rapportages.
Als het stuk is is het stuk, maar zoals je zelf al zegt komt echte downtime bijna niet voor. Het gaat in de praktijk eerder over verminderde performance of security issues. Dat is bijvoorbeeld het geval bij ISV’s die hun applicatie draaien op een IaaS omgeving. Dan is persoonlijk contact tussen ISV en IaaS leverancier essentieel om tot een oplossing te komen.
De commodity cloud providers zullen dit niet leveren; hier is een rol weggelegd voor andere bedrijven. Dit kunnen denk ik zowel onafhankelijke adviseurs zijn als gespecialiseerde managed hosting providers.
@Henri
Hoever zijn we off-topic als we overwegen dat onpersoonlijke statische website van eenmaal schrijven en tot de macht n lezen verschilt van dynamische website met gepersonaliseerde content uit verschillende bronnen?
Het probleem van traditionele CMS-model waarover je spreekt zit in de wijze waarop je data inblikt, ‘blikopener’ van ETL aan de bovenkant met een webservice of aan de onderkant met een CLI maakt verschil. Wie het kleine niet leert doet het grote al snel verkeerd, IaaS in de meterkast in combinatie met cloud bursting:
https://www.univention.com/