Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

In de cloud kan het wel eens mistig worden

 

Computable Expert

Ruud Mulder
Advisory Systems Engineer, Dell EMC. Expert van Computable voor de topics Cloud Computing, Infrastructuur en Loopbaan.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4760903). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Ruud,

De Patriot Act en de excessen daaruit staan nu in het nieuws door onthullingen van een klokkenluider. Hier gaat het volgens mij nog niet eens om het feit dat Amerikaanse overheid mee kan lezen maar vooral om het gemak en de omvang. Gelijk werd ook onthult dat GCHQ op grote schaal de glasvezel verbindingen aftapt en zijn er geruchten dat Nederland dezelfde plannen heeft of reeds bezig is. Op Internet is dus vooral het recht nogal wazig omdat er juridisch nogal wat verschillen zijn tussen landen, niet alleen op het gebied van privacy maar vooral door de wijze waarop het ingericht is.

Inderdaad is classificatie vooraf dus wel handig en dus komt de vraag op of we nog wel onze medische gegevens in de cloud willen hebben?

Nu ben ik geen jurist maar de discussie die op verschillende fora over dit fenomeen op gang komen zijn wel hoogst interessant om te volgen, want uiteindelijk wordt de IT al grotendeels beheerd door advocaten. Zeker als we het gaan hebben over SLA's die vaak belangrijker lijken te zijn dan gezond verstand. Performance, beveiliging en zelfs multi tenancy zijn namelijk inhoudsloze begrippen als je geen middelen hebt om dit te controleren, eventuele schade te verhalen of mogelijkheden om deze te beperken. Risico management is tenslotte meer dan proberen de schuld bij een ander te leggen.

Quality of Service bij gedeeld gebruik van resources is weliswaar in te richten maar dan kom je toch al gauw weer in een soor van private cloud oplossing. Vergelijk het met de wijze waarop meeste gebruikers op Internet aangesloten zijn, de download snelheid neemt vaak af als er meer in de straat van dezelfde centrale gebruik maken. Wil je gegarandeerde snelheden dan zul je toch al snel naar een andere - meestal duurdere - oplossing toe moeten waarbij communicatie gescheiden wordt. Ditzelfde voor de toegang tot disk, hoewel met virtualisatie nu ook QoS op IOPS gedaan kan worden. Of dit helpt als de disk zelf uiteindelijk niet hard genoeg draait is weer een andere vraag.

Samengevat zijn er dus een heleboel vragen waar op alleen antwoord gegeven kan worden als je weet wat je naar de cloud brengt en weet wat je met de cloud wilt bereiken. Momenteel zie ik echter dat vaak vooral geprobeerd wordt om organisatorische problemen op te lossen, een vlucht voorwaarts waarop later weer (gedeeltelijk) terug gekeerd wordt.

Kijkend vanuit het bredere perspectief, dus inderdaad strategisch, operationeel en functioneel, en deels juridisch, word het hele cloud verhaal een steeds 'misty' materie waarbij ik dan heel rustig weer achterover ga zitten.

Gecompliceerd zelden interessant....
My pennies worth...
IT als vehikel beschouwend, dat mij zakelijk, of privé ten dienste moet staan, moet dat een overzichtelijke en begrijpelijke zaak zijn. Wanneer het zo is dat je plots een leger aan specialisten en experts nodig hebt om zaken te verwoorden, illustreren of te verhelderen, op welke wijze dan ook, haak ik zakelijk gewoon af.

IT vs Non IT
In Computable komen we vaak genoeg de publicaties tegen van specialisten die zelf ook met regelmaat stellen de grootste moeite te hebben IT gerelateerde zaken over te brengen aan Non IT management. Als dat zo is, hoe je er dan ook tegen Non-IT management aan kijkt, heb je feitelijk de slag al een beetje verloren.

Cloud is de toekomst.... dus ...
Dat word louter uit commerciële overwegingen geroepen want cloud is in essentie absoluut niet voor iedereen het geschikte antwoord. Vooral niet als je even in overweging neemt dat men het plots is gaan hebben over 'public' of 'private' cloud. Commercieel staat dat misschien leuk, het draagt voor geen meter bij zaken helder en begrijpelijk oevr te brengen aan potentiële klanten.

Ik zou mij tenminste niet onder druk laten zitten door die opmerkingen.... Cloud is de toekomst... of je het wil of niet...
Cloud is EEN optie! Zo eenvoudig is het en het is aan mij als klant te bepalen of die optie al of niet werkt voor mij. Zo eenvoudig is het.

Migratie perikelen
Als IT professional heb ik vrijwel alle facetten van migraties gezien, meegemaakt, deel van uit gemaakt, beschreven, geadviseerd. Elke migratie, van welke orde van grootte ook, ken zo de eigen perikelen. Dat even helemaal los van de politiek die er vaak in mee speelt, of de 'eigen wijze' van andere IT professionals, die ook zo een eigen dynamiek heeft.

Dat word in dit artikel ook nog eens duidelijk verwoord dat wanneer je dus gebruik wil gana maken van cloud, je zeer goed zal moeten overwegen op welke gronden je dat zou doen want ze zeggen niet voor niets, 'Cloud.... er is geen weg terug...' Dat betekend dus ook dat wanneer je van IT dienstenleverancier zou moeten wisselen, dat je daar dan ook tegen zeer veel hobbels aan zal gaan lopen, zou je moeten migrereren.

Uiteindelijk .....
Ik zie vele commercieel, maar ook 'eigen' gekleurde flarden van meningen, ervaringen, publicaties, wishfull thinking. Maar wat ik nog steeds niet heb gezien is een succesvolle standaard beschrijving van een migratie van een platform naar cloud.

Ik zie de reacties al los barsten maar als ik de meest basale stappen nog niet eens voor me heb gezien die zouden moeten leiden tot het overwegen in de cloud te stappen, mag een ieder roepen en publiceren wat die wil, dan blijf ik inderdaad gewoon met beide benen op de grond staan en adviseer ik nog steeds aan professioneel bekenden van mij dit ook gewoon te doen.

Zo eenvoudig kan het namelijk ook.

Helder verhaal, echter ik mis een belangrijk punt. Je benoemt wel een aantal punten als een exit-strategie, security en performance maar niet het opstellen van een what-if scenario's indien er iets misgaat in de cloud.

Een simpel worst-case scenario, als de data in de cloud door wat voor reden niet beschikbaar is en niet meer beschikbaar komt, wat zijn dan de gevolgen voor de bedrijfsvoering? Hoeveel schade kan dat tot gevolg hebben, hoeveel schade kan de onderneming dragen? Vragen als, hoe erg is het als bepaalde gegevens bij mijn concurrentie terecht komt, schaad dat de bedrijfsvoering?

Op basis daarvan kan je bepalen hoe je je cloud-stategie inricht en welke maatregelen je bij voorbaat neemt. Hoe garandeer je dat je nooit data kwijtraakt, verkeerde personenen geen toegang krijgen tot bedrijfskritische informatie, sluit je een contract met andere partijen die binnen een bepaalde tijd de dienstverlening over kunnen nemen? Is encryptie voldoende om je geevens te beschermen of wil je bepaalde gegevens simpelweg niet in de cloud hebben?

Met scenario's kan je je randvoorwaarden bepalen alsvorens je leveranciers om oplossingen vraagt.

Hey Ruud,

Je artikel leest lekker weg, maar om je eigen stokpaardje in jouw reacties maar eens te gebruiken, ik heb ze al meermalen langs zien komen, haha.

Cloud of niet cloud is eigenlijk helemaal de vraag niet. Laten we eens kijken naar de huidige realiteit: Steeds minder bedrijven hebben hardware staan in eigen datacenters, of je provider failliet gaat of niet is dus niet zo zeer een cloud aangelegenheid, maar iets wat altijd speelt als je je IT ergens anders onderbrengt. Dat geldt voor meerdere argumenten die je gebruikt als bandbreedte, multi-tenancy, en bijvoorbeeld de overheids bemoeienis, allemaal zaken die niet exclusief voor "cloud" gelden.

Ook het backup-verhaal bevat weinig onderscheid tussen on-premises, uitbesteden aan een datacenter, private of public cloud. Je kan in alle gevallen je backup gewoon bij je data opslaan, dit helpt je echter niet als je leverancier failliet gaat en je backup daar ook staat. Dus al gebruik je eigen hardware in een datacenter van iemand anders, je wilt ook je data daarbuiten beschikbaar hebben voor ramp-scenario's. Daar heb je dus dezelfde propositie tussen cloud en niet cloud.

Migraties: Zelfde verhaal. Je kunt on-premises je citrix farm hebben, bij een datacenter leverancier of bij een cloud provider, je hebt in alle gevallen gewoon met migraties te maken.

Je punt is wel valide dat als je applicaties wil hosten met behulp van cloud computing (automatische schalers, load balancers, et cetera) dat je de applicatie beter opnieuw kan bouwen door een bestaande architectuur te verplaatsen, omdat de winst van naar de cloud gaan op deze manier direct discutabel is.

Niet zo zeer cloud is de toekomst als dat het gewoon lastig en onwenselijk is om alles on-premises te blijven doen. Data centers gaan beter om met stroom, schaalvoordeel en bandbreedte en dat is ook hun core business. Voor veel bedrijven is IT wel belangrijk voor de core business maar zit IT niet in de core van de business. Uitbesteden is daarom logisch. Ook omdat een gemiddeld MKB geen clue heeft van security en een hoster/datacenter/cloud dat in de regel wel is (let wel op certificeringen, audits en track record).

Nu is het nog "private" cloud wat de klok slaat, vaak met een smaakje "cloudwashing", maar als je echt vernieuwend bezig wilt zijn wil je helemaal geen infrastructuur en servers beheren, deze bieden je functioneel niets, ze faciliteren waar het echt om gaat namelijk data/informatie en grafische interfaces ook wel applicaties of apps genoemd.

Ik wil me helemaal niet bezig houden met back-up. Je moet wel! Maar het is een noodzakelijk kwaad. Je wilt helemaal geen back-up, je wilt zekerheid en controle en back-up is vooralsnog het middel (met de randvoorwaarden zoals rto, dr).

Cloud is helemaal niet mistig of net zo mistig als niet-cloud, maar wel buiten deur. Goede voorbereiding (zie intro) is altijd belangrijk, of je nu naar cloud of off-premises verhuisd...

Zo kijk ik er tegenaan.

Henri,

Telkens ga je weer over dingen beginnen die niet het probleem zijn, technische oplossingen voor organisatorische problemen.

Dat sommige data als niets zien maakt namelijk duidelijk dat het allemaal nogal mistig is omdat data voor veel organisaties toch echt een core asset is. Servers en applicaties zijn vervangbaar, hoewel migraties soms zo kostbaar zijn dat we met legacy blijven werken, het is de data die telt. De back-up is hierin ook meer een proces, een stuk risicomanagement waarbij je afhankelijk van de eisen de juiste middelen moet kiezen.

Dat de IT voor veel bedrijven geen core activiteit is wil nog niet zeggen dat ze daarom maar naar de cloud moeten, er zijn meer wegen. Ze kunnen ook voor managed hosting kiezen, misschien is dat 'cloudwashed' zoals jij het zegt maar in ieder geval nog niet 'brainwashed' En je opmerking aangaande certificeringen en audits negeer ik dan ook maar, je spreekt hier jezelf tegen als ik eerdere reacties en publicaties van je lees.

Betreffende de voorbereiding nog maar eens in de reprise:
1. Functionaliteit: welke bedrijfsprocessen worden ermee ondersteund, welke waarde hebben ze hiervoor en zijn er overlappingen?
2. Beheer: hoe liggen de verantwoordelijkheden, welke lifecycles zijn er en welke sla's gelden er per service/applicatie?
3. Techniek: systeem/applicatie karakteristieken, welke afhankelijkheden zijn er met andere systemen of bedrijven?

Slide 16: http://www.slideshare.net/edekkinga/get-your-house-on-order

Ewout/Numoquest.

Bedankt voor jullie toevoegingen.

@ Henri ( Mr. Mac Cloud )

Bedankt voor je feedback. Al vind ik je wel iets te pro-cloud.

Willem,

Valide punt. Enerzijds valt dit natuurlijk onder SLA. Het is ook moeilijk om alles te adresseren. En met ruim 1200 worden was mijn opinie artikel al ietwat aan de lange kant. Maar er is zeker genoeg stof over voor vervolgartikelen.

Henri,

Ik deel je mening dat mijn aandachtspunten ook voor niet cloud trajecten op kunnen gaan.. Maar dat maakt ze niet minder waardevol/bruikbaar. Wat ik wel opvallend vind is dat ik het gevoel krijg dat ons referentiekader ( lees omvang en type klant ) totaal verschillend is. Je refereert bij Cloud als snel aan het MKB. En ik zie het juist meer bij de grote jongens. Absoluut interessant om een keer offline verder over verder te praten.

Ewout,

Ik deel je mening dat back-up een zeer belangrijk onderwerp is. Nog te veel wordt dit niet goed aangepakt. Zoals ik schreef is classificatie en de juiste dosering key.

En ja Henri is misschien wel iets te pro-cloud. Maar dat hoort ook bij zijn rol als cloud evangelist (-; Dus dat moeten hem maar niet kwalijk nemen.

Cloud is een goed iets, dat deel ik zeker met Henri. Alleen moet je wel de plussen en minnen vooraf goed duidelijk hebben. Cloud is geen must maar een keuze. En die nuance mis ik nog wel eens in zijn feedback

Ik heb mijn reactie niet goed geschreven of hij is niet goed gelezen.

Mijn reactie is namelijk helemaal niet pro-cloud maar vooral pro-uitbesteding. Bedrijven die zo groot zijn dat hun IT in feite al een "cloud" is hoeven niet per se uit te besteden. De consequentie is dan wel dat IT een core asset geworden is van dat bedrijf en dat ze dus goed zijn in het hebben van eigen datacenters.

Dit is een artikel over cloud, dus het is logisch dat dit een onderwerp is waarop ik mijn perspectief geef, je schrijft over mist en cloud computing maar vervolgens schrijf je weinig over wat je als cloud ziet en de eigenschappen zoals deze in definities van cloud computing worden vastgelegd.

Schrijf dan over uitbesteden van IT.

Wat betreft bedrijfsgrootte en perspectief wil ik een ander artikel aanhalen wat nu ook op de voorpagina staat:

http://www.computable.nl/artikel/opinie/architectuur/4758196/2204519/architectuur-kan-ook-agile-zijn.html

Want ik denk dat daarin een waarheid staat die op ons van toepassing is: Enterprise-architectuur versus solution-architectuur.

Ik schrijf wat meer over de solution architecten en jij/Ewout schrijven wat meer over enterprise architecten. Dat zou een hoop van de frictie kunnen verklaren.

Maar om nogmaals mijn eerdere punt duidelijk te maken. Van mij hoeft niet alles cloud te zijn om goed te zijn. Ik zie dat zeer veel bedrijven eigenlijk veel IT onderdelen al uitbesteden (soms overigens in de vorm van externen), en dat dit logisch is, en dan zijn alle punten die je beschrijft van toepassing.

Het is overigens wel zo dat het kleinste bedrijf met public cloud dezelfde kracht tot zijn beschikking heeft als de grootste enterprise. En dan maakt de classificatie klein, MKB, enterprise helemaal niet zoveel meer uit. Want wat ik beschrijf is echt niet alleen voor de kleine bedrijfjes van toepassing, snap je wat ik bedoel?


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.

Goede toevoeging Henri waarvoor dank. En ik ga zeker even de blog lezen.

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.

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?

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×