Regelmatig hoor ik dat men ‘migreren naar de cloud’ ziet als dé oplossing voor allerlei problemen. Uiteraard is het een handige stap wanneer je regelmatig capaciteit wilt op- of afschalen, of wanneer medewerkers vanaf verschillende locaties werken. Maar het is niet hét antwoord op alle problemen.
Realistische verwachtingen spelen hierin een grote rol. Een verwachting is bijvoorbeeld dat de migratie veel besparingen oplevert in beheer- en hardware kosten. Men verwacht dat het beheer in handen is van de cloudleverancier. In eerste instantie lijkt deze verwachting uit te komen: de eerste gebruikers migreren en alles werkt naar behoren. Maar hoe meer gebruikers overstappen, hoe meer klagende eindgebruikers er komen. Daar had men geen rekening mee gehouden. En als de organisatie vervolgens bij de cloudleverancier aanklopt, geeft deze aan dat bij hen alles naar behoren werkt. Ze voldoen immers gewoon aan de service level agreement (sla) die eerder is getekend.
In de praktijk zien we bovenstaand scenario regelmatig en lijkt een totaaloverzicht te ontbreken wanneer delen van it worden uitbesteed. De vier meest voorkomende oorzaken van ontevredenheid na migratie naar de cloud bespreek ik in deze blog.
Onvoorziene gevolgen van de voordelen
De voordelen van werken in de cloud zijn groot. Maar soms brengen de voordelen ook onvoorziene – misschien wel nadelige – gevolgen met zich mee. Zo klinkt ‘automatisch versiebeheer’ best ideaal. Maar het gevolg van deze feature is echter dat er heel veel versies van documenten worden opgeslagen. Hoe meer wijzigingen, hoe meer documenten er bestaan. Dit neemt als snel veel capaciteit in en zorgt voor een tragere reactietijd.
Een ander voorbeeld is het voordeel dat alle werknemers overal kunnen werken, ook in het buitenland. Als een medewerker dus vanaf zijn vakantieadres in China een document bewerkt, wordt deze opgeslagen op een server in dit land zodat de reactiesnelheid geborgd blijft. Automatisch wordt de privacywetgeving van dit land toegepast. Maar komt deze wel overeen met uw privacy wensen?
Mijn advies: vraag door op de onderdelen die voor uw organisatie belangrijk zijn. Maak daarnaast niet alleen afspraken over technische prestaties, maar ook over de prestaties die de eindgebruiker ervaart. Dit kan bijvoorbeeld in een experience level agreement (xla, zie www.giarte.com).
Het delen van de omgeving
Een cloudleverancier levert doorgaans aan meerdere partijen. Door groot in te kopen worden immers kosten bespaard. Dit heeft voor de afnemende partijen wel een nadeel: wanneer veel personen tegelijk van de cloud gebruik maken heeft dit invloed op de performance. De overgang naar de cloud betekent in veel gevallen niet meer dan ‘van andermans servers gebruik maken’, waardoor de bestaande verstoringen niet weggaan en er zelfs nieuwe kunnen ontstaan. Ik vergelijk het graag met een boiler: wanneer één iemand er gebruik van maakt is er niets aan de hand. Wanneer meerdere personen deze gebruiken, is het warme water eerder op.
Mijn advies: bepaal of de kostenbesparing opweegt tegen bovenstaand risico.
Migreren wanneer een organisatie groeit
Wanneer de eigen omgeving niet groot genoeg meer is voor een organisatie, zal een nieuwe leverancier aanbieden om de omgeving ‘over te nemen’. Dit werkt voor even goed, maar de bereidheid van leveranciers om problemen op te lossen in een overgenomen en voor hen onbekende omgeving, is meestal klein. Het bestaande probleem wordt dan niet opgelost en de leverancier komt met een alternatief: overgaan op hun ‘standaard omgeving’. De oude, eigen infrastructuur migreert naar die van de leverancier. Dit brengt andere voorwaarden en extra kosten met zich mee.
Mijn advies: maak afspraken met de leverancier over de verwachtingen en mogelijkheden om in de eigen omgeving te blijven werken.
Verantwoordelijkheden zijn versnipperd
Wanneer bedrijven migreren naar de cloud verwachten ze dat ze daarbij één aanspreekpunt hebben en de cloudleverancier alles regelt. Echter, de leverancier besteedt ook delen van zijn dienstverlening uit. Zo huren ze capaciteit bij leverancier B, terwijl partij C de back-end applicaties beheert. Deze partij maakt vervolgens weer gebruik van interne hosting van afdeling D. Alle partijen controleren alleen of hun product goed functioneert. Niemand voelt zich verantwoordelijk voor de goede werking van de totale oplossing. Bij problemen geeft iedere leverancier aan dat alles bij hen naar behoren functioneert en het dus wel aan een andere schakel moet liggen.
Mijn advies: meet zelf hoe de leveranciers presteren en toon met objectieve cijfers aan dat er een probleem is.
Verstandig?
Of het verstandig is om naar de cloud te migreren moet iedere organisatie voor zichzelf bepalen. Bovenstaande overwegingen kunnen in elk geval meewegen. Het is met name belangrijk om goede afspraken met de leverancier te maken en deze objectief te meten of beoordelen zodat duidelijk wordt wie verantwoordelijk is bij eventuele verstoringen of andere verwachtingen. Kortom, houd zelf grip en controle, ook na een migratie naar de cloud!
Mijn advies : Installeer een VPN naar je kantoornet en werk door zoals je gewend bent.
Dit artikelt slaat de plank m.i. op diverse fronten mis.
Automatisch versiebeheer is wel ideaal.
Bij een nieuwe versie lever je nieuwe documentatie, waarmee de oude komt te vervallen.
Dus je laatste document telt.
Bij eventuele fouten in de software ( die zijn er altijd wel, bij waterval nog meer dan bij agile) kan je als je je pipeline hebt geautomatiseerd, veel sneller en adequater op het probleem reageren en weer veel sneller een nieuwere verbeterde versie uitrollen.
Het probleem van meerdere gebruikers, die merken dat ze performance problemen hebben is een slecht argument.
Wat als je on prem te weinig capaciteit hebt?
Dan duurt het nog veel langer eer dat je je performance weer op orde hebt en wordt het veel duurder:
Server bestellen (6 maanden wachttijd) server inrichten, server uitrollen, software installeren (oeps nieuwere versies werken niet meer samen met de bedrijfssoftware) nieuwe licenties, testen, in productie. ( ik zal vast nog e.e.a. zijn vergeten.)
Je kan natuurlijk gigantisch veel capaciteit on prem in kopen, maar dat is natuurlijk desinvesteren.
Zolang Facebook, Google, Netflix (noem ze maar op) 100den miljoenen klanten bedienen, allemaal via de cloud, met goede performance, kan het niet aan de cloud liggen dat je performance slecht is.
De alinea “Migreren wanneer een organisatie groeit”: Dit is juist een on prem probleem en geen cloud probleem, maar wordt gebracht als een cloud probleem.
De alinea “de verantwoordelijkheden zijn versnipperd” vind ik zeer warrig en begrijp ik niet.
Een firma als Amazon, heeft bij mijn weten, zijn hele infra in eigen beheer en geen contracters. Hetzelfde geldt voor Google en Microsoft.
Ik denk dat dit probleem groter is en zwaarder speelt als je je infra on prem hebt.
Kortom als je de argumenten van dhr. Wigman voor cloud en on prem naast elkaar zet, dan springt cloud er ver boven uit op alle genoemde vlakken.
Dan heb ik het nog niet eens over de niet genoemde zaken zoals security, identy management, maar ook bijvoorbeeld geldstromen.
Met cloud zijn de uitgaven en de inkomsten veel inzichtelijker te maken dan on prem.
Ik denk dat dhr. Wigman zich niet genoeg in cloudtechnologie heeft verdiept.
Marcel,
De meeste organisaties hebben ondertussen het concept van virtualisatie begrepen, de uitrol van een server kan net zo snel als in de cloud. Uiteraard moet je dan wel voldoende fysieke capaciteit hebben maar gezien de wet van Moore is dit steeds minder een probleem. Economisch is een investering in eigen infrastructuur momenteel voordeliger door een negatieve rente op vermogen dan huur hiervan in de cloud. En daar speelt – ondanks alle marketing verhalen – nog het ‘noisy neighbor’ probleem als het om de front- en back-end netwerken gaat. De oplossing van bandwidth throttling grijpt in op de netneutraliteit waardoor de cloud er voor iedereen is maar niet voor alles.
Misschien heb ik me niet genoeg verdiept in cloud technologie maar uitgaven en inkomsten zijn hier niet tranparanter dan on-prem om de simpele reden dat de meeste providers schrijven met een vork. Een jaar of 7 geleden kraakte ik al de code van de werkelijke transactiekosten in de cloud versus echte baten want Amazon, Google en Microsoft schrijven nog altijd hun cloud winsten met rode cijfers. Verdienmodellen gaan om de informatie die verkregen wordt vanuit de metadata, datastromen zijn interessanter dan de geldstromen want de bedot.com economie van de cloud staat onder druk van nieuwe wetgeving. Het wel beloven maar niet leveren is dodelijk omdat daarmee het vertrouwen onder druk komt te staan.
Je opmerking over security en identity management zijn dan ook hilarisch want beide gelden alleen als we accepteren dat de cloud geen anonimiteit kent.