'Van de cloud resources wordt 40 procent niet, niet optimaal of helemaal niet meer gebruikt.' Deze uitspraak kregen wij vorige week te horen op een seminar over it-management software. Ik heb bij deze stelling geen onderbouwing, modellen of magische quadranten van wereldwijde onderzoeksbureaus gevonden. Zonder al te veel wederhoor of bevestiging geloof ik deze cijfers wel. Waarom: het is herkenbaar gedrag.
In de ‘oude’ wereld kocht je hardware: teveel omdat je uitging van groei en piek performance. In de wereld van gisteren had je alles virtueel: hardware delen en je leerde een nieuw woordje, ‘sprawl‘: de ongekende groei van virtuele machines. Had je wat nodig: drie keer klikken en je hebt een nieuw machientje tot je beschikking. Opruimen kost, net als bij pepernoten in de een of andere hoek, te veel tijd, dus maken we maar weer wat aan.
Nu met de ‘nieuwe werkelijkheid’ en in de tijd van ‘alles wordt anders’, ‘zonder cloud ben je out’, heb je geen last meer van hardware of eigen virtuele farms. Eindelijk rust in het beheer en concentreren op innovatie. Time to market is alles. De basis van cloud diensten is dat je alleen betaalt voor wat je gebruikt. En dan het simpele bericht dat rond de 40 procent van deze diensten niet of nauwelijks gebruikt wordt. Dan donder je wel een beetje van je geloof. Of was mijn geloof in die goedheilige oplossing een beetje te onnozel? Ik weet ook wel dat of je een cloud resource nou niet, een beetje of optimaal gebruikt, die factuur zijn weg naar je brievenbus toch wel vindt.
Hoe is dit, ondanks het weinige veldwerk, te verklaren? Wat zit er aan de andere kant van de cloud? Juist: de mens. We kunnen onze manier van werken sneller en eenvoudiger maken door geavanceerde tooling en portals. Ons gedrag is echter weerbarstiger. Als je een applicatie aanvraagt en je krijgt een vraag die gekoppeld is aan Life-Cycle-Management (wanneer mag het weer weg?), dan ga je voor zekerheid. Dus wat langer dan bedoeld. Of anders, ik weet het niet en doe dan maar heel lang of oneindig. Vervolgens eindigt deze applicatie waarschijnlijk ongebruikt maar ruimte innemend, net als die surprise die je vorig jaar kreeg maar waar zichtbaar zoveel werk in zat dat het zonde zou zijn om weg te gooien.
Ik relateer het aan mijzelf. Als ik deze eenvoudige manier van werken heb; zullen andere dat ook wel hebben. En als je al deze kleine beetjes bij elkaar optelt, zal dat flink aantikken. Dat je dan snel richting de 40 procent gaat geloof ik dan ook wel. Boeren-eigen-wijsheid heet dat toch?
Als je zonder controle resources afneemt kan je er dus niet zeker van zijn dat je de budgetten goed besteed en zonder controle weet je niet of de gemaakte kosten ook gelijk staan aan de gebruikte resources. Cloud resources reken je immers af op basis van reservering en gebruik. Als je reserveert en wat data opslaat gebruik je resources. Tot in lengte van dagen als je geen actie onderneemt.
Hoe doorbreek je dit? Als je weet wat je afneemt is dat zeer interessant om te combineren met wat je gebruikt. Maar ook hoe je dit gebruikt. De top tien zwaarste applicaties of virtuele machines zijn snel bekend. De top tien laagst performende ook. De uitersten zijn vaak bekend. Door het middengebied te analyseren kun je veel wegfilteren of optimaliseren. Dat je dit met mooie it-management software kan doen zal geen surprise zijn. Dit monitoren en analyseren is eenvoudig wanneer je vanuit de it-organisatie alle resources inzichtelijk hebt. Maar niet alle resources worden door de it-organisatie aangevraagd, beheerd of zijn inzichtelijk. Afdelingen kunnen zelfstandig resources afnemen. De financiële afdeling is dan je beste bron. Uiteindelijk levert een dienst een factuur op. Dat kan het begin zijn van verzamelen van resource- en gebruikinformatie.
Ik weet: het is lastig om alle gegevens te vinden maar loont wel de moeite. En de samenwerking? Juist in deze periode kent men vast wel de term: we zijn toch zeker Sinterklaas niet!
tja, de facturen zijn niet virtueel he. Business aan de knoppen heeft natuurlijk ook zijn nadelen. Krijgen we straks Cloud monitoring specialisten of cloud architecten. Technisch beheer op remote cloud systemen. Ik dacht dat men daar juist vanaf wilde. Cloud consultant ? Ook niet gratis vast. Cloud security consultant, want het gaat natuurlijk keertje fout met BYOCloud.
Jeroen, je slaat de spijker op zijn kop. Doordat het vanuit de cloud bestellen van capaciteit nu door de business unit zelf gedaan kan worden via allerlei mooie self service portals is de controle verdwenen. De factuur komt terecht bij de CFO en de onderbouwing (gespecificeerde nota)zal in detail onderzocht moeten worden om een showback of chargeback naar de business te kunnen doen. Een heel nieuw fenomeen duikt op; waar vroeger middels een ouderwets proces met inkoopbonnen (purchase orders) gewerkt moest worden voor bestellingen wordt dat nu dikwijls overgeslagen. Ik adviseer mijn gesprekspartners om een dergelijk proces voor de cloud ook goed in te richten. Voorkom VM sprawl door duidelijke afspraken te maken over het configureren van servers, de lifecycle daarvan en spreek duidelijk een cost-control mechanisme met de provider af.
Succes met het implementeren.
Ps. als het niet lukt kun je altijd nog teruggrijpen op ouderwetse Role-Based-Access-Control, dan maar geen Cloud Administrator privileges 🙂
@JeroenvanYperen Dit is inderdaad een probleem. Hier zit ik ook wel eens te denken als het over de cloud gaat en virtualisatie. Het gemak waarmee nieuwe machines en applicaties aangemaakt kunnen worden gaat ongetwijfeld zorgen voor een oerwoud aan machines en applicaties waar het lastig is om het overzicht te houden. Veel machines zonder baasje en een hele beheer klus.
Jeroen,
Dat hosting – al dan niet in cloudvorm – vaak niet erg efficiënt omgaat met de resources is voor sommigen misschien nieuws maar hoort nu eenmaal bij het businessmodel. Een provider heeft nu eenmaal profijt bij het verkopen van resources en dus zal deze je niet snel helpen om daar zuiniger mee om te gaan, integendeel zelfs want dat ondermijnt zijn investeringen. Denk dat slide 8 heel aardig die paradox weergeeft:
http://www.slideshare.net/edekkinga/get-your-house-on-order
Aangaande idee om via de financiële afdeling resource gebruik inzichtelijk te maken moet ik je teleurstellen want boekhoudingen zijn even mistig als de cloud. En het vergif van BYO helpt ook niet echt om efficiënter met resources om te gaan, individuele efficiency is trouwens niet altijd effectief samenwerken. En het is mooi dat afdelingen zelf hun keuzen maken maar vaak hebben ze geen strategische kijk op de organisatie en kiezen dus primair op functionaliteit waardoor aantal puntoplossingen alleen maar groter worden.
Terug naar mijn presentatie op slideshare waar slide 11 het heeft over business effectiveness en IT efficiency, een delicaat evenwicht wat dus NIET verkregen zal worden met alleen het meten van techniek door de wet van Mo(o)re. Het analyseren van resource gebruik laat verspilling in de vorm van ‘dubbel op’ nog vaak buiten beschouwing. Cloud storage providers profiteren hier trouwens van door met behulp van deduplicatie de werkelijk benodigde opslag drastisch te verkleinen. De kijk op het resource verbruik kan dus weleens behoorlijk misleidend zijn.
Betreffende kostenmodellen heb ik al eens wat geschreven in ‘Het zorgpremiestelstel van de ICT’ want investeringen in netwerk en beveiliging stijgen ondertussen behoorlijk. In het kader van lifecycle – systeem of data – stel je de vraag wanneer iets weg mag maar deze vraag is naar mijn opinie niet compleet. Het is namelijk simpel om data naar de cloud te repliceren maar veel moeilijker om deze daaruit weer te verwijderen, hoewel het met providers zoals MegaUpload, Nirvanix en een aantal kleinere spelers eigenlijk automatisch ging. Een back-up lokaal kan dus handig zijn want er gaat nogal wat data verloren, niet door diefstal maar gewoon doordat de rekening niet betaald is.
Voordat ik die cloud evangelist op mijn dak krijg, cloud computing is niet alleen maar kommer en kwel maar het ‘ontzorgen’ valt nog weleens tegen. Maar die zorgen liggen niet zo zeer bij de resources in de infrastructuur maar vooral in de applicaties, bij utility computing gaat het dus meer om de kraan dan de pomp.