__.JPG "Klik voor hele profiel")
Het lijkt ook voor veel organisaties een grote stap om naar een publieke cloud te gaan. Een multicloud is daarbij misschien de overtreffende trap van iets waar men al twijfels over heeft. Er zijn echter heel goede redenen om een multi-cloud omgeving te gebruiken. Er zijn twee belangrijke drivers voor een multi-cloud, de organische en de strategische.
De organische driver gaat meestal uit van een legacy omgeving. Vaak is de kennis aanwezig binnen de organisatie en zijn er meerdere afdelingen die al geëxperimenteerd hebben met een cloud omgeving. Deze ongecoordineerde stappen leiden vaak naar een cloud omgeving die van verschillende providers wordt betrokken.
De strategische driver vindt vaak plaats door gebruik te maken van de best in class service en features van de verschillende cloud providers. De focus om nieuwe features aan te bieden is bij elke aanbieder anders. Of het nu gaat om containers, authenticatie of computer configuraties, dit kan per publieke cloud omgeving anders zijn. Een reden om dan meerdere omgevingen te hebben kan dus valide zijn om om te switchen van omgeving.
Meerdere omgevingen
Een andere strategische reden kan zijn dat een tweede cloud omgeving perfect gebruikt kan worden als disaster recovery omgeving. Een cloud omgeving is redundant ingericht. Hierdoor zou het misschien niet nodig zijn. Maar stel dat door een incident de connectie naar een publieke cloud omgeving niet meer werkt? Het zou dan prettig zijn om naar een andere cloud omgeving te kunnen gaan om die applicaties te gebruiken die de belangrijkste business processen nodig hebben.
Vendor lock-in is een overweging om een tweede publieke omgeving op te zetten. Prijzen van een aanbieder staan nu contractueel vast. Maar er zal meer en meer worden gekeken naar hoe de markt zich beweegt en in hoeverre dit invloed op de prijs heeft.
Bovenstaande lijst is zeker nog niet compleet. Waar in ieder geval bij moeten worden stilgestaan is de integratie van de diverse cloud platformen. Provisioning van servers, het management van de servers en het monitoren van de capaciteit of gebruik vragen om een broker functie tussen de verschillende cloud platformen. Op dit moment zijn de broker functies nog verschillend in functionaliteit en wordt er gedacht vanuit het platform. Een onafhankelijke leverancier heeft een andere kijk op deze broker functie. Hij is niet gebonden aan één technologie en kan zich meer focussen op het oplossen van het probleem van integratie.
Reacties
Multi-cloud is ineens het woord van de week. Kom het op veel plaatsen tegen. Als cloud adept voeg ik mijn twee centen toe.
Ik heb een kleine organisatie, maar wij gebruiken Azure, AWS en GCP (Google Cloud Platform). Natuurlijk vergt het wel wat aangezien de drie consoles (en API om ze te benaderen) verschillen. Aan de andere kant, het is weer geen rocket science en met wat aandacht is het goed te doen.
Hier zijn wat waarnemingen:
95%+ van de nieuwe klanten gebruikt Microsoft office 365, of Microsoft technologie en heeft iets in of doet iets met Azure. Bizar.
Wij gebruiken Azure voor Single Sign On met ons product en gebruiken het nog in wat legacy voor storage en soms testing. De console is het laatste jaar een stuk sneller geworden maar Azure blijft Microsoft, er zitten veel rare onverklaarbare zaken in. Het is de provider waarbij ik het minste gevoel van controle heb.
Veel bedrijven doen ook wel iets met Amazon Web Services (AWS). Dus veel klanten zijn al "multi-cloud" als is het vaak beperkt tot wat functies aan de rand van de automatisering. Wij leunen het zwaarst op AWS en hebben een groot deel van de productie hier onder gebracht. Ik ben zelf groot fan en vind het prettig dat de interfaces consistent zijn, je weet intuitief hoe iets werkt en de integratie tussen de diverse services is erg sterk. Een van de zaken die mij het meest tegen de borst stuiten zijn de data transfer kosten. Als gebruikers veel data gebruiken (en wij doen veel met video), dan lopen de kosten behoorlijk op. Een TB aan data verplaatsen kost al snel 90 euro. Ook is er een natuurlijke verleiding om tot een vendor lock-in te komen. Door de serverless functies en met name die van Lambda "plak" je heel gemakkelijk alles aan elkaar, maar dit maakt je omgeving moeilijker te verplaatsen.
Tot slot Google Cloud Platform. Over het algemeen krijg je het meeste "bang" for je buck bij Google. Een nano servertje van vijf dollar is krachtig genoeg om een dienst op te bouwen. DialogFlow is heerlijk simpel voor het maken van een chatbot en met Firebase en Cloud Functions knoop je alles eenvoudig aan elkaar. Google Kubernetes Engine (GKE) is superieur aan die van Amazon en Azure. Het nadeel van GCP is de leercurve, het is allemaal wat technischer en duurt gewoon langer voordat je er vertrouwt mee bent. De console is best complex en GCP hanteert een "project" benadering. Dat laatste is overigens ook een zege om zeer gemakkelijk een sandbox op te zetten en te experimenteren. GCP is (veel) minder compleet dan AWS, maar sommige dingen zijn zeer verleidelijk. Een nadeel is overigens het imago. Als mensen het woord Google lezen denken ze direct dat je data gedeeld wordt met Google.
Wat ik mee wil geven is dit. Leer als organisatie wat cloud providers zijn en hoe ze opereren. Het is een visie. Iedere kleine organisatie heeft de kracht van een enterprise als het op infrastructuur aan komt. En cloud provider is totaal iets anders dan hosting. Cloud providers zijn aanbieders van frameworks. Ze bieden functies om je IT te kunnen doen.
Wat ik verschrikkelijk vind is dat al die kracht uit de VS komt. Noem het een VS lock-in.
Ik sta volledig open om te switchen naar Europees, maar dat is voor nu een veel te grote beperking.
Multi-cloud is een blabla woord, niettemin raad ik ieder organisatie in de basis onder de knie te krijgen....
Mijn ervaring is dat het nog wel eens mistig kan worden tussen de verschillende clouds en daarbij horende consoles en SLA’s. Daar ligt in mijn ogen optiek juist de grootste uitdaging van multicloud. Hoe hou je het in- en overzicht? Hoe hou je het beheer- en beheersbaar? Hoe zorg je dat de verschillende clouds workload van elkaar overnemen en dus continuïteit bieden tussen de logische applicatie ketens? En wanneer is het pas echt een multicloud? Nu zie ik vaak multi silo’s. Meerdere consoles, weinig flexibiliteit,weinig inzicht waardoor de kosten nog wel eens kunnen oplopen (verkeer tussen de clouds) en weinig teaming (ketenproblematiek) en vaak ieder voor zich. En dat brengt allemaal meer nieuwe uitdagingen met zich mee.
Maar ja dat houdt ons weer bezig en van de straat ;-)
Mijn ervaring is dat het nog wel eens mistig kan worden tussen de verschillende clouds en daarbij horende consoles en SLA’s. Daar ligt in mijn ogen optiek juist de grootste uitdaging van multicloud. Hoe hou je het in- en overzicht? Hoe hou je het beheer- en beheersbaar? Hoe zorg je dat de verschillende clouds workload van elkaar overnemen en dus continuïteit bieden tussen de logische applicatie ketens? En wanneer is het pas echt een multicloud? Nu zie ik vaak multi silo’s. Meerdere consoles, weinig flexibiliteit,weinig inzicht waardoor de kosten nog wel eens kunnen oplopen (verkeer tussen de clouds) en weinig teaming (ketenproblematiek) en vaak ieder voor zich. En dat brengt allemaal meer nieuwe uitdagingen met zich mee.
Maar ja dat houdt ons weer bezig en van de straat ;-)
@Ruud, thanks voor de zinvolle toevoegingen.
Uiteraard hebben we te maken met mensen, processen en technologie. SLA's valt in mijn ogen onder processen. Meer externe producten en diensten leiden tot meer SLA's, afhankelijkheden en organisatie talent. Dan moet je natuurlijk de afweging maken.
Voorbeeld: Organisatie gebruikt Office 365 en Azure Active Directory, maar maakt ook diensten voor derden. Het (deels) nieuwe team heeft meer ervaring met AWS en leunt sterk op Linux. Gebruik je dan toch Azure omdat dit makkelijker voor is voor overzicht en het gemak van een one-stop shop, of kies je toch om deel Azure, deels AWS te gebruiken.
De situatie van workloads overnemen tussen verschillende cloud providers, daar ken ik weinig succesverhalen in. Dat lijkt me dan ook geen goede use case met alleen maar nadelen en zonder voordelen, hooguit om de vendor lock-in te vermijden.
Wanneer iets multi-cloud is vind ik zelf niet zo boeiend. Er is namelijk *altijd* wel iets on-premises qua clients en overige infrastructuur. Dus of er nu werkelijk een koppeling bestaat tussen de diverse cloud platforms of niet en of dat dan multi-cloud mag heten... Wat is er voor of tegen? Hoe uit zich dat? Data verplaatsen tussen cloud providers is inderdaad kostbaar en vaak ook niet wenselijk voor latency. Dus data opslag in bijvoorbeeld Azure en dataverwerking in AWS lijkt me een situatie die je probeert te vermijden of te beperken. Ook krijg je inderdaad eilanden omdat het ene team bezig is met één cloud-provider en een ander team zich richt op een andere cloud provider (met bijbehorende console, API's en eigenaardigheden).
Mijn ervaring is dat praktisch alle bedrijven kiezen voor Microsoft en dus logischerwijs al met Azure te maken hebben. In dat opzicht heeft Microsoft zeer sterke kaarten in handen. Als je kijkt naar de console, de volwassenheid van de services en de services zelf, dan vind ik Azure zeker niet de sterkste speler. Kijk je naar Amazon, dan zie je dat hun generieke kantoorapplicaties qua adoptie en functie zich niet kunnen meten aan Microsoft. Het lijkt me dus een lastige spagaat.
Ach en veel bedrijven zijn pas net begonnen met hun reis om cloud providers te omarmen. Brede en diepe kennis van cloud providers is vaak niet eens aanwezig. Daarbij wordt een cloud provider gezien als een soort verlengstuk van wat men altijd al gedaan heeft. Logisch omdat er ook vaak een legacy bestaat. Het maakt de hele digitale transformatie echter wel moeizaam.
Ieder zal zijn eigen verhaal in dit opzicht hebben, mijn perspectief zal weer anders zijn dan die van een collega. Dat houdt het interessant..
"Uiteraard hebben we te maken met mensen, processen en technologie. SLA's valt in mijn ogen onder processen. Meer externe producten en diensten leiden tot meer SLA's, afhankelijkheden en organisatie talent. Dan moet je natuurlijk de afweging maken"
Ja en nee. Je kan hele mooie processen hebben maar als de technologie dit niet borgt dan heb je er vrij weinig aan. Dus in mijn optiek is SLA een afspraak welke enerzijds door een proces maar ook zeker door de techniek geborgd moet worden.
Je krijgt met multicloud te maken met een vrij nieuw begrip "Deel(tjes) SLA/SLO's". Die zoals de naam het al zegt allesbehalve de gehele keten dekken. Het wijzen naar wie is de schuldige levert wel eens leuke discussie en uiteindelijk teleurstelling op.
"Wanneer iets multi-cloud is vind ik zelf niet zo boeiend. Er is namelijk *altijd* wel iets on-premises qua clients en overige infrastructuur. Dus of er nu werkelijk een koppeling bestaat tussen de diverse cloud platforms of niet en of dat dan multi-cloud mag heten... Wat is er voor of tegen?"
Tja meningen verschillen en dat is prima. Ik vind het pas echt multi-cloud als ik het over en weer kan verplaatsen zonder dat je te maken krijgt met beperkingen of vendor lock-ins. Want als het allemaal langs elkaar heen en dus lastig samen werkt en ook nog eens met verschillende consoles beheerd moet worden, dan krijg je last van "multi silo's" in plaats van "multi-cloud".
"Hoe uit zich dat? Data verplaatsen tussen cloud providers is inderdaad kostbaar en vaak ook niet wenselijk voor latency"
Ja dat klopt, afhankelijk van de technologie waar voor je kiest. Er zijn al genoeg DC partijen welke direct connectiviteit met de cloud bieden. Dus latency is zeker wel te voorkomen. Ook zie je al dat er al partijen zijn welke de "egress" aantrekkelijker en transparanter maken qua kosten. Maar daar is nog wel een lange weg te gaan. Want pas als dat ingeregeld is, dan kan het pas echt de flexibiliteit leveren welke je verwacht van een echte multicloud.
"Dus data opslag in bijvoorbeeld Azure en dataverwerking in AWS lijkt me een situatie die je probeert te vermijden of te beperken.
Ook krijg je inderdaad eilanden omdat het ene team bezig is met één cloud-provider en een ander team zich richt op een andere cloud provider (met bijbehorende console, API's en eigenaardigheden)"
Waarom zou je dit willen voorkomen? In IT land geldt er al jaren iets zoals "One size doesn't fit all". Je zal zien dat medium tot grote organisaties graag aan risicospreiding doen, en niet graag al hun geld op rood of op zwart zetten.
"Ach en veel bedrijven zijn pas net begonnen met hun reis om cloud providers te omarmen. Brede en diepe kennis van cloud providers is vaak niet eens aanwezig. Daarbij wordt een cloud provider gezien als een soort verlengstuk van wat men altijd al gedaan heeft. Logisch omdat er ook vaak een legacy bestaat. Het maakt de hele digitale transformatie echter wel moeizaam"
Daar verkijk je jezelf ietwat op. Ruim 93% van alle wereldwijde organisaties is volgens Forrester al bezig met 2 of meer cloud proposities in welke vorm dan ook. Dus cloud is meer aanwezig dan menigeen al denkt. En juist dit zorgt er al voor dat we al last beginnen te krijgen van een nieuw fenomeen namelijk de zogenaamde "overbewolking" . Het lijkt allemaal zo makkelijk, goedkoop en flexibel die clouds. Daarom schieten de wolken als paddestoelen uit te grond. Maar hoe kan je het beheer- en beheersbaar houden? Daar ligt vaak de volgende uitdaging in de transitie naar cloud.
Ik deel wel je mening dat er nog niet altijd even genoeg kennis aanwezig is om de juiste keuzes te maken. Maar ook hier geldt dat een goede voorbereiding het halve werk is.
Voor zover een multi-cloud die end-user facing is (onder het motto doe meer met je netwerk packets):
https://www.linkedin.com/pulse/why-end-to-end-slos-important-will-moonen/
Een manier om de SLA's rondom prestaties en beschikbaarheid van de verschillende cloud-diensten snel in kaart te brengen. Afhankelijk van de invulling kan meteen gestart worden met probleemanalyses.
Multi-cloud of niet – het blijft iemand anders zijn server/software die staat te snorren in iemand anders zijn DC; niet noodzakelijkerwijs allemaal van dezelfde partij.
De bijbehorende contracten en SLA’s komen terecht bij contract managers die op hun beurt weer ondersteund worden door juristen. Uiteindelijk hebben die juristen (en de CFO) het laatste woord.
Tot zover is er door de jaren heen niet zoveel veranderd; het is en blijft een vorm van (out-)sourcing.
Wat veranderd is is de verrekening. In het verleden betaalde je een bedrag per maand gedurende een bepaalde contractperiode. Tegenwoordig betaal je een bedrag per maand wat afhankelijk is van het verbruik. Daarbovenop is er wat korting mogelijk als je per jaar in een keer betaald.
De olifantenorganisaties hebben doorgaans wat meer onderhandelingsruimte als het gaat om maandbedrag en contractermijn. Met als eindresultaat een maatwerk contract en dito maandbedrag.
@Ruud en @Henri - even met de genoemde Azure-, AWS- en Google-diensten als referentiekader:
Voor zover ik op dit moment kan overzien kijkt elke cloud provider niet verder dan zijn eigen domein en onderliggende deelgebieden.
Voor elk deelgebied is een SLA vastgesteld wat is uitgedrukt in een beschikbaarheid- en een malus-spercentage; alles op basis van een “commercially reasonable effort”.
Wordt die SLA niet gehaald, dan kun je achteraf een “credit request” indienen op basis van de malus percentages die genoemd zijn bij elke van de deelgebieden:
- 99.9% met een malus van 25%
- 99% met een malus van 50%
- 95% met een malus van 100%
Alle genoemde leveranciers hanteren dezelfde SLA's en malus percentages.
Als je een service credit request wil indienen dan moet dat onderbouwd worden met error logs waaruit blijkt dat die SLA’s inderdaad niet gehaald zijn.
Bij een eventuele creditering lijkt Amazon nog het meest klantvriendelijk: heb je aangetoond dat de afgenomen diensten niet beschikbaar zijn kan je tot 100% creditering verwachten. Bij Google is dat maximaal 50% van het totaalbedrag per maand.
Bij Microsoft is het afhankelijk van de oorzaak van de onbeschikbaarheid. Zijn er meerdere diensten niet beschikbaar en hebben ze allemaal dezelfde oorzaak (te bepalen door Microsoft), dan kan je op één dienst een creditering aanvragen (die dan tot 100% kan oplopen).
In alle gevallen dien je ervoor te zorgen dat je de aanvraag tot creditering plus bewijslast binnen 30 dagen hebt aangevraagd.
Voor de volledigheid: performance problemen zijn altijd uitgesloten.
En ook: mocht het “Internet” te kampen hebben met een serieuze onbeschikbaarheid, dan is de malus ook niet van toepassing.
Als afnemer hou je 3 opties over:
- Niets doen en eventuele problemen voor lief nemen (inspanning voor creditering plus bewijslast kost meer dan de creditering opbrengt; als die al gehonoreerd wordt)
- Zorgen dat je alles in stelling hebt staan om binnen 30 dagen de aanvraag tot creditering plus bewijslast kunt indienen (wat ook weer zo zijn kosten met zich meebrengt)
- Zorgen dat je zo snel als mogelijk wordt geïnformeerd bij eventuele uitval zodat je kunt overschakelen op alternatieven; bijvoorbeeld een manueel uitgevoerde procedure of de workload van dat moment ergens anders opstarten.
Blijft over de data… waar is die opgeslagen en hoe krijg je die snel mogelijk ingelezen?
Oftewel, hoe staat het met de RTO en RPO? En wat is er nodig om dat voor elkaar te krijgen?
Goede toevoeging Will!
Vandaar ook mijn opmerking over deeltjes SLA/SLO. Ketenproblematiek maar dan op het gebied van beschikbaarheid en verantwoordelijkheid.
Dus verspreiden levert uitdagingen op maar op 1 cloud leverancier al je geld inzetten is ook risicovol als het gaat om mission critical data en apps.
Wat is wijsheid dan? Classificatie? Spreiding? Of juist niet?
En ja data is zeer cruciaal en wil je op de juiste plek met de juiste beschikbaarheid/snelheid en tegen de juiste kosten beschikbaar hebben.
We zijn nog wel even van de straat denk ik maar zo.
Bedankt Ruud.
Mijn 5-centen: daar waar in het verleden sprake was van IT-silo's gaan we nu cloud-silo's krijgen; of zo je wil hybride silo's omdat er ook nog wat on-prem draait.
Ik heb zo mijn twijfel of er voor de rest veel gaat veranderen.
Contract managers, juristen en financiële mensen zijn nog steeds leidend in de manier waarop IT-middelen gefinancierd en ingezet worden. Die mensen denken doorgaans in processen, procedures en contracten; de wetmatigheden van technologie en de wisselwerking met die processen, procedures en contracten is zelden een onderdeel van de vergelijking.
Zowel de organisatorische als strategische driver voor de cloud houdt nog altijd geen rekening met juridische beperkingen van mijn data op jouw systemen. En een master information system architect moet dat weten of zoals Will Moonen het zegt, het zijn de processen die de exodus UIT de cloud naar de on-premises oplossingen bepalen omdat 'cloud born' procedures een korte lifecycle kennen terwijl de data een (fiscaal) wettelijke bewaartermijn van 7 jaar of meer kent.
Eén van de veel gehoorde klachten over de cloud is dat het allemaal duurder is dan beloofd en veel organisaties komen er achter dat verspreidde data via een multi-cloud strategie niet alleen de kans op datalekken vergroot maar vooral tot administratieve tekortkomingen leidt. Ik zeur graag over het (BTW) bonnetje omdat de omgekeerde bewijslast nogal vervelend is als je geen back-up van de cloud hebt en organisaties moeten de kleine lettertjes van een cloud provider nog maar eens lezen als het om een herstel in tijd van 'gebruikersfouten' gaat.
Ik loop nu vooruit op een reactie over disaster recovery in de multi-cloud van een andere opinie waar Nasreen stelt dat de focus moet liggen op een datastrategie met vragen zoals waar moet deze worden opgeslagen en wie er toegang toe moeten hebben. Interessante vragen als ik uitga van de viewpoints van een master information system architect, een cursus die ik ook gedaan heb. Het probleem van integratie versus integriteit gaat namelijk om de focus op information governance en daarin blijkt de cloud als de belofte van een VVD politicus.
Prijzen in de cloud staan contractueel namelijk net zo vast als belofte dat er geen geld meer naar Griekenland gaat want zodra de inkt van het contract droog is beginnen de onderhandelingen, hoe groter je portabiliteit hoe beter je onderhandelingspositie.
"Eén van de veel gehoorde klachten over de cloud is dat het allemaal duurder is dan beloofd en veel organisaties komen er achter dat verspreidde data via een multi-cloud strategie niet alleen de kans op datalekken vergroot maar vooral tot administratieve tekortkomingen leidt. Ik zeur graag over het (BTW) bonnetje omdat de omgekeerde bewijslast nogal vervelend is als je geen back-up van de cloud hebt en organisaties moeten de kleine lettertjes van een cloud provider nog maar eens lezen als het om een herstel in tijd van 'gebruikersfouten' gaat"
Bezin eer ge begint geldt ook hier weer. Zorg dat je het overzicht en de controle tussen al die wolken blijft behouden. Niet alleen technisch maar ook financieel. Per use case zal het verschillen. Het is daarom van groot belang je applicaties en de daar bijhorende data op de juiste manier te classificeren/kwalificeren. En dat doe je in mijn optiek op basis van technische criteria ( performance, schaalbaarheid, redundantie, security ) maar ook op basis van business criteria ( regelgeving, compliancy, kosten, flexibiliteit ) . Ook hier is een goede voorbereiding weer het halve werk wat veel teleurstelling kan voorkomen. En dit is iets wat je niet alleen tijdens de voorbereiding alleen maar in kaart moet brengen. Dit is iets wat "ongoing" is.
Hallo Ruud M.
Bezint eer ge begint gaat wel om je startpunt. Vaak is er geen bewustzijn aangaande data terwijl de controle op je data geen vrijblijvendheid kent. Zo is het inderdaad handig als je bij het aanmaken van data er direct een bewaartermijn op plakt. Het digitale residu van veel business processen moet 7 jaar of meer bewaard worden terwijl de meeste services niet langer dan een paar jaar mee gaan. De cloud speelt dan ook steeds vaker een facilitaire rol in fraudes, bewust of onbewust.