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.
Henri,
Ik wilde je even uit de tent lokken. En dat is zo te zien goed gelukt. Want je hapt nog sneller dan Mr Pacman 🙂
In de 2e alinea heb ik misschien ietwat summier de scope van het artikel aangegeven. “De transitie van data naar de cloud” En ja dit is een ruim begrip waar iedereen anders tegen aan kijkt. Dat blijkt wel weer uit je reacties. En dat maakt de discussie juist zo interessant. En dit probeer ik altijd wel iets uit te lokken. Maar ik vind dat je het in je reactie wel heel erg breed trekt. Want zo is er natuurlijk in ieder artikel wel iets te vinden wat onduidelijk is of niet geadresseerd wordt.
Dit zijn gewoon wat aandachtspunten waar ik het nog geregeld fout zie gaan. Ik blijf nu eenmaal een voorstander van checklists met praktische informatie. En ja er zit wel wat herhaling in. Maar er staan zeker ook genoeg punten in die hier nog niet eerder de revu hebben gepasseerd. Dat blijkt wel weer uit de reacties.
Ik schrijf natuurlijk niet specifiek voor een Enterprise of Solution architect. Maar voor iedereen die deze info bruikbaar acht/vindt.
En er is ook genoeg stof voor een 2e artikel. Want in dit stuk kon ik helaas niet alles kwijt om het nog enigzins leesbaar te houden.
Henri,
Het is onjuist om te denken dat ik enkel over de enterprise schrijf, ik zie namelijk vooral veel multi-nationals die dezelfde problemen hebben als MKB alleen dan in een veelvoud en op andere schaal. Ik geloof ook niet erg in het idee van assimilatie met een Enterprise architectuur, het heeft mij soms teveel weg van de federatie van de borg:
“Wij zijn de Borg. Wij zullen uw biologische en technologische eigenschappen aan de onze toevoegen. Uw samenleving wordt aangepast om de onze te dienen. Verzet is zinloos.”.
Betreffende de schaalbaarheid van de cloud ben ik het dan ook niet helemaal met je eens omdat dit weinig nut heeft als business proces daar niet op ingericht is. Je kunt makkelijk een webshop beginnen maar als je logistiek aan de achterkant niet even schaalbaar is als aan de voorkant dan ontstaat er uiteindelijk wel een probleem met levering.
Net als dat er trouwens nog weleens een probleem met ondersteuning ontstaat als je in de cloud zit. Ik neem aan dat jij namelijk niet 7X24 ondersteuning levert aan klanten, in 26 talen om even wat te noemen. Dit lijkt me namelijk een VERI important punt wat nog weleens vergeten wordt.
Ruud,
Ik ga niet je eigen “stokpaardje” gebruiken maar ik ben het met Henri eens. Ik lees hier een korte samenvatting van wat er al de afgelopen maanden op deze site gepubliceerd en besproken is. Gelukkig krijgt deze saaie herhaling wat meer leven door de reacties van je collega Ewout.
Leuk dat je dit allemaal op een rijtje hebt gezet. Maar wat is je voorstel? Ik ga van een cloudmodel van Microsoft,Google of een van die grote jongens gebruik maken. Denk je dat ze met mij rond de tafel gaan zitten om deze punten te bespreken?
Klein beginnen is een leuk voorstel maar dat kan in veel situaties niet representatief zijn. Wat heb je eraan dan?
Ik zou nog even wachten tot de mist in de cloud verder opgetrokken is en dan pas mijn weg daar naartoe bewandelen.
Reza,
Bedankt voor je feedback. Ik deel je mening dat het bij Google en Microsoft bijna niet in te regelen is om “exceptions” in te regelen. Met uitzonderingen zoals Ahold daar gelaten. Maar dat is natuurlijk zelf ook een grote jongen.
Echter is er met de andere Cloud leveranciers ( TerreMark, IS, Interoute ) best veel mogelijk en zijn zij een stuk flexibeler.
En ja, enkele van mijn punten zijn al meerdere keren besproken. Maar andere ook weer niet. Dus vandaar dat ik ze in 1 artikel helder heb proberen samen te vatten. Misschien voor de doorgewinterde experts zoals jij en Henri niet zo spannend. Maar voor de overige mensen misschien wel.
@ Henri,
Hoe kijk jij tegen multi-tenancy aan?
Door de reacties in een ander artikel, werd ik weer hier geen getrokken.
Multi-tenancy.
Allereerst lijkt multi-tenancy is een helder iets. Maar er zit een hele wondere wereld achter. In feite is praktisch alles multi-tenant. We delen infrastructuur om bij onze remote servers te komen, we delen vaak bandbreedte al dan niet fysiek of virtueel gescheiden.
Multi-tenancy komt ook in zoveel verschijningsvormen. De cloud van Google is multi-tenant, onze mailboxen leven op dezelfde servers, maar toch zijn ze enorm gescheiden. Ik ken geen incidenten dat er per ongeluk mailtjes.
Sommige saas diensten zijn multi-tenant en tenants zitten zelfs in dezelfde database.
Als ik kijk naar de grote public cloud providers hebben ze multi-tenancy behoorlijk veilig gemaakt. Er zijn nagenoeg geen incidenten dat de multi-tenancy van een cloud server leidde tot veiligheidslekken.
Maar, ik heb wel eens last van andere tenants. Vooral bij Azure SQL Server had ik wel eens last van wisselende performance. Als je een goede architectuur hebt kun je dit echter makkelijk oplossen en voor virtual machines is dit nagenoeg helemaal geen probleem. Als ik zie dat een instance in een cluster slecht presteert door een buurman die continu zijn verwerkingskracht over de kling jaagt, dan knal ik die instance af en komt ie ergens anders weer tot leven. Het gaat om de overall performance versus de kosten en de aanname dat de veiligheid in ieder geval goed is.
Ook mijn storage (s3, windows azure) zal per definitie multi-tenant zijn, maar daar heb je nagenoeg helemaal geen performance degradaties.
Het zelf ontwerpen van multi-tenancy in een applicatie is echter wel een uitdaging en zeker niet triviaal.
Maar goed, je beschrijft het zelf ook al in je artikel.
Multi-tenant is een ding wat je moet onderzoeken of je nu met cloud computing of hosting te maken hebt.
Thanks Henri. Goede toevoeging.
Maar ik ben even benieuwd wat je hier onder verstaat:
Ook mijn storage (s3, windows azure) zal per definitie multi-tenant zijn, maar daar heb je nagenoeg helemaal geen performance degradaties.
Nagenoeg helemaal geen klinkt nogal vaag. Is het mogelijk om gegarandeerde IO’s op het gebied van diskperformance te reserveren? Dit is nog vaak het euvel van multi-tenant omgeving. Hoe garandeer je dat je geen overlast hebt van die lastige buurman? Afschieten van een instance is niet voor iedereen een optie.
Ik ben erg benieuwd of dit nu wel al onder SR en Azure gesupporteerd wordt.
In een eerdere reactie (naar Henri) schreef ik dat bijvoorbeeld een prefix al voor multitenancy kan zorgen, op die manier werden in de jaren 60 al resources en applicaties op het mainframe gedeeld. Hiervoor moeten dus niet alleen de applicaties geschikt zijn maar ook het onderliggende platform, een risico met shared schema’s is trouwens SQL injection.
Voorbeeld dat Henri beschrijft met lastige buurman lijkt trouwens te duiden op een clustered shared schema waarbij verschillende applicaties instances over meerdere stacks zijn verdeeld. Een oplossing voor tekortkomingen in het platform waardoor er een race voor resources kan ontstaan, overcommitting van resources is trouwens een fundamenteel onderdeel van het cloud model.
Een oplossing om te voorkomen dat je problemen ervaart in de performance door de pieken van een ander is megatenancy, een (gedeeltelijk) geïsoleerde stack waarbij echter ook bepaalde resources gedeeld kunnen worden zoals bijvoorbeeld opslag en netwerk. Hier zit natuurlijk wel een ander kostenplaatje aan en een risico dat je later alsnog naar multitenancy moet migreren.
Sommige aanbieders bieden namelijk op deze manier hun eerdere single-tenant oplossingen in cloud vorm aan maar stoppen de support hiervan zodra ze uiteindelijk een multitenant versie hebben.
Ewout,
Zijn er vormen van mega-tenancy te noemen waar een performance garantie afgegeven wordt?
Of te wel ik wil altijd 2000 iops hebben voor mijn DB. Soort van QoS dus.
Ruud,
Provisioned IOPS EBS is de dienst van Amazon waarin je voorspelbare IOPS hebt. Uiteraard erkennen cloud providers de problemen met multi-tenancy en nieuwe functionaliteit vliegt je om de oren.
Lees deze blog anders eens: http://copperegg.com/amazon-provisioned-iops-ebs/
Dan zie je de voors en tegen van de diverse storage diensten bij Amazon.
Windows Azure is nog niet zo ver, tenminste, niet dat ik weet. Als je echter een paar dagen wat performance testjes laat lopen zie je weinig pieken en dalen in de IOPS. Ze gebruiken blijkbaar een andere strategie om hier mee om te gaan.
Wat betreft afschieten van instances…. Ik sysprep een image van een VM en hiervan laat ik er twee van draaien in een availability set. Is de performance van een slecht (slechte buur), dan kan ik deze verplaatsen zonder downtime. Ja, het is niet voor iedereen *standaard* een optie, maar je kunt bepaalde goede gewoontes wel aanleren.
Ook qua beheer in een multi-tenant omgeving heb je niet alleen mogelijhkheden om dedicated instances af te nemen, maar je krijgt er gratis ook nog eens allemaal monitor tools bij. Als een server te lang te hard gebruikt wordt, krijg ik een mail of kan ik een extra instance laten starten. Is de reactietijd op een ping lang kan ik ook een trigger af laten gaan, net als dat er een schijf volloopt. Allemaal “gratis”.
En dit is mijn punt. De ontwikkelingen gaan zo rap dat het over een tijdje heel moeilijk wordt om als hoster deze mogelijkheden bij te benen. Met een rap tempo worden de “gaps” -de dingen die systeembeheerders missen- snel bijgebouwd.
IT blijft complex, hoe je het ook went of keert, maar de mogelijkheden zijn enorm.
Denk gedistribueerd. Want multi-tenancy probleem heb je vaak ook intern waarbij de ene afdeling werkzaamheden invloed heeft op de performance van andere systemen binnen een bedrijf.