Geleidelijk aan oriënteren steeds meer organisaties zich op het gebied van cloud computing. Niet vreemd, want cloud is de toekomst. Zonder gedegen voorbereiding loop je echter al snel met je hoofd in de wolken. Goede voorbereidingen zijn cruciaal bij een overstap naar cloud. Doe je het niet goed als organisatie, dan kan het erg mistig worden in de wolken.
In dit artikel wil ik ingaan op de transitie van data naar de cloud. Bij IaaS (Infrastructure as a Service) en BRaaS (Back-up and Recovery as a Service) is het snel beschikbaar hebben van je data cruciaal. En juist daar gaat het nog wel eens fout. Waar moet je op letten voordat je je data in de wolken gooit? Hoe voorkom je wazige situaties in die wolken? In de onderstaande checklist geef ik een aantal tips & tricks.
Patriot act
De Patriot Act, een serie van wetswijzigingen in de bestaande Amerikaanse wetgeving op grond waarvan Amerikaanse inlichtingen- en veiligheidsdiensten gegevens mogen opvragen, was in mijn ogen bangmakerij, die vooral gevoed werd door tegenstanders van cloud computing of cloud-leveranciers die geen banden met de VS hadden. Want hoeveel gevallen van afluisteren waren er nu eigenlijk echt in Nederland bekend? Er beginnen echter steeds meer concrete voorbeelden te komen en het wordt nu toch wel echt iets waar we serieus over na moeten gaan denken. Het nieuws omtrent PRISM is op zijn minst eng te noemen. En de waarschuwing van het CBP dat de Safe Harbor Principles niet veel voorstellen, dragen ook niet positief bij aan de beeldvorming.
Exit scenario
Data in de cloud hebben is één ding, maar wat als je weer uit de cloud wilt, of als je mogelijk naar een andere leverancier wilt gaan? Of erger nog: je leverancier gaat failliet. We leven natuurlijk wel in crisistijden op dit moment. Het hebben van een duidelijk exit-scenario is van cruciaal belang: hoe krijg je jouw data weer uit de cloud en hoeveel tijd neemt dat in beslag?
Performance
Performance is op te delen in drie aandachtsgebieden: Netwerk, disk en applicatie performance.
Netwerk: Bandbreedte en de beschikbaarheid hiervan is vaak nog een ondergeschoven kindje. Data naar de cloud migreren en vice versa kan een tijdrovende zaak zijn. Te vaak wordt hier nog onnodig op bespaard en teveel besparen gaat je na verloop van tijd echt pijn doen. Want te weinig bandbreedte kan frustrerend zijn op het moment dat je veel data in of uit de cloud wilt gaan halen. Dit kan er voor zorgen dat sla’s niet gehaald worden. Ook het tegenovergestelde komt voor. Teveel bandbreedte is te duur en onnodig. Een burstable of pay for use oplossing kan hier uitkomst bieden. Natuurlijk moet hier wel een boven- en een ondergrens worden afgesproken, om onduidelijkheid te voorkomen. Wan-optimalisatie of acceleratie is een technologie die hier steeds vaker ingezet wordt.
Disk performance: Hier zie ik het erg vaak fout gaan. Er wordt nog te vaak naar opslagcapaciteit gekeken. Zeker belangrijk, maar je moet de data natuurlijk ook snel terug kunnen halen of wijzigen. Hier komt disk i/o om de hoek kijken. Caching technologie kan hier uitkomst bieden en zal net als wan-optimalisatie op de langere termijn kostenverlagend werken.
Applicatie performance: De performance van een applicatie is afhankelijk van meerdere factoren. Zaken zoals het netwerk, servers en de storage-laag hebben hier invloed op. Breng daarom vooraf goed in kaart wat er voor resources nodig zijn om het optimaal te laten functioneren. Dan ben je er echter nog niet. Een applicatie zelf moet natuurlijk wel goed geschreven zijn en ook om kunnen gaan met de transitie naar de cloud. Een programmeerfout kan ervoor zorgen dat resources nutteloos worden verbruikt en zo een onnodige kostenpost opleveren.
Multi-tenant
Veel cloud-omgevingen worden multi-tenant aangeboden. Het is belangrijk om te bedenken of je last van de overige huurders wilt hebben. Voor sommige situaties is het helemaal niet problematisch om zaken als hardware en bandbreedte te delen. Voor andere situaties wil je dit absoluut niet. Ook dit dient weer vooraf duidelijk te zijn en in kaart gebracht te worden. Hoe vangt de leverancier dit af? Wat zijn de risico’s en wat is het kostenplaatje als ik mijn eigen verdieping wil hebben?
Quality of service
QoS is een zeer belangrijk onderdeel van een multi-tenant omgeving. Het delen van resources is goedkoper, maar je wilt natuurlijk niet iedere keer in de rij staan en moeten wachten. Natuurlijk is dit per omgeving verschillend. Gaat het om een statisch archief wat slechts periodiek geraadpleegd wordt, dan is dat minder spannend. Maar gaat het om een DR-omgeving of een bedrijfskritisch crm-pakket, dan ligt dit heel anders. Stel daarom altijd de vraag of je leverancier een gegarandeerde performance kan bieden. En hoe dit achter de schermen ingeregeld wordt.
Classificeer
Niet alles hoeft in de cloud. Dus breng vooraf goed in kaart wat er aan data in de cloud komt. Classificeer je data (bijvoorbeeld: goud, zilver, of brons) en stel per type data randvoorwaarden op. Tijdens het definiëren van de randvoorwaarden kom je er vaak achter dat niet alles even bedrijfskritisch is. Bepaal dus goed wat je wel of niet in de cloud wilt hebben. Alles in de cloud zetten kan namelijk nog wel eens een dure aangelegenheid worden.
Security
Wie kan er bij jouw data? Hoe is het datacenter van je leverancier beveiligd? Moet de data door middel van encryptie beveiligd worden? Zo ja, hou dan vooraf rekening met de gevolgen. Wat voor impact heeft dit? En wat zijn de consequenties op het gebied van performance? Encryptie is leuk, maar levert altijd een performance penalty op. En encrypted data bij een escalatie weer op een nieuwe omgeving aan de praat krijgen is ook een uitdaging. Vergeet ook de certificeringen van je leverancier niet. Ondanks dat dit een momentopname is, krijg je wel een beter beeld over het professionalisme van je leverancier.
Voorbereiding
Last, but surely not least: het succes van een transitie naar de cloud staat en valt bij de voorbereiding. Alles oppakken en het zomaar in de cloud gooien, levert vaak een teleurstellend resultaat op. Neem hier dus de tijd voor en raadpleeg waar nodig een specialist. Iemand met ervaring, kan veel bijdragen aan een positief eindresultaat. Ook hier geldt: meten is weten. Als je vooraf weet wat er nodig is, dan is de kans op succes groter.
Niet alleen ijzer maar ook sla
Voorbereiding dient niet alleen op het gebied van het ijzer (hardware, bandbreedte et cetera), maar ook op strategisch, financieel en logistiek gebied plaats te vinden. Wat zijn de wensen en eisen vanuit de business? Hoe gaat de Cloud onze business helpen? Zaken zoals beschikbaarheid, schaalbaarheid en de mogelijk financiële besparingen, spelen hier een grote rol. Hoe zit het met de business case, tco en roi, om maar eens een paar buzzwoorden te gebruiken? Maar ook het logistieke aspect mag zeker niet uit het oog verloren worden. Wie doet wat? Wie is er nu eigenlijk verantwoordelijk?
Het ijzer-aspect van de voorbereiding is makkelijk af te vangen. Meet eerst de delen die je naar de cloud wilt gaan brengen. Wat zijn de eigenschappen? Past het wel in de cloud? Wat is er nodig qua netwerk, performance en security? Maak gedegen keuzes. Het is geen verplichting om alles meteen in de cloud te zetten. Vaak is het juist verstandiger om klein te beginnen en zo kennis en ervaring op te doen.
Of dit is ook wel een aardige
http://aws.typepad.com/aws/2013/05/provision-up-to-4k-iops-per-ebs-volume.html
Als je 4k IOPS niet genoeg vind, dan koppel je er een toch bij en stripe je over meerdere volumes.
Goede toevoeging Henri waarvoor dank. En ik ga zeker even de blog lezen.
Ruud,
Misschien moet je een nieuwe ‘samenvatting’ schrijven. Door alle reacties wordt deze opinie nogal mistig.
Betreffende je vraag, zie mijn eerdere reactie over managed hosting, de ‘cloud washed’ oplossingen.
@ Henri,
Stripen over meerdere volumes is natuurlijk leuk maar mijn ervaring met zo genaamde Meta Luns is dat je wel een performance penalty gaat betalen.
Klopt dat?
@ Ewout,
Multi-tenancy en QoS zijn zeker onderwerpen om verder op in te haken. Daarom waren ze ook onderdeel van mijn checklist.
En ja je hebt gelijk dat dit weer een interessante discussie is. Ik ben wel erg benieuwd naar ieder zijn ervaring met QoS en multi-tenancy in de Cloud. Dit kan weer mooi als inspiratie dienen voor een vervolg stuk.
Dus heren kom maar op 🙂 Wat hebben jullie tot nu toe met QoS in de Cloud gedaan? En wat voor ervaringen hebben jullie met multi-tenancy?