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

Eis van je cloud-partner ‘zero-outage’-garantie

 

Computable Expert

Serge Vandenhoudt
VP Production, T-Systems. Expert van Computable voor de topics Outsourcing, Cloud Computing en Security.

Veel bedrijven nemen een groot risico door niet contractueel vast te leggen dat zij van hun cloud-partner ‘zero-outage’ eisen. Zeker als het om bedrijfskritische systemen gaat. Deze systemen moeten nu eenmaal een zeer hoge beschikbaarheid hebben. Bij voorkeur 99,999 procent, ofwel hooguit vijf minuten per jaar aan ongeplande onderbrekingen. Toch verzuimen bedrijven dit vaak op te nemen in contracten, met de nodige gevolgen van dien.

Nu organisaties meer en meer overstappen op een it-strategie die is gebaseerd op cloud-services, is ‘zero-outage computing’ - ofwel een hoge beschikbaarheid - essentieel. Toch lezen we bijna wekelijks berichten over cloud-aanbieders die met storingen te maken hebben. Horen bedrijfskritische applicaties dan niet in een cloud-omgeving thuis? Of kan cruciale enterprise-software wel degelijk met succes via een cloud-model worden aangeboden?

Waar veel mensen met twijfels over ‘de cloud’ de fout in gaan, is dat vrijwel alle storingen waar we over lezen plaatsvinden bij aanbieders van public cloud-oplossingen. Dit soort datacenters bedienen grote aantallen klanten met applicaties die vaak van sterk wisselende kwaliteit zijn. Ondanks de belofte van multitenancy zien we toch vaak dat technische problemen met een gehoste applicatie tot verstoringen in de beschikbaarheid van public cloud-diensten leiden. Public clouds hebben bovendien te maken met een forse druk op de prijzen. Er wordt dus per definitie beknibbeld op support.

Volledige controle

Bedrijfskritische applicaties hebben dan ook niets te zoeken in een public cloud. Zij vereisen een private cloud-omgeving. Alleen dan hebben we volledige controle over de gehele infrastructuur. Een aanbieder die zero-outage voor cloud-applicaties nastreeft, zal iedere fout die optreedt zorgvuldig willen analyseren. Alleen dan leren organisaties van de problemen die kunnen ontstaan en ontdekken zij hoe deze het beste kunnen worden opgelost. Of beter nog: worden voorkomen.

Belangrijk is ook dat het vaak storingen in applicaties zijn - en niet zozeer de cloud-infrastructuur zelf - die tot problemen in de beschikbaarheid van een cloud-omgeving leiden. Het is dus niet voldoende om simpelweg het hosten van een aantal applicaties uit te besteden. Kennis van de applicaties is hier minstens zo belangrijk als ervaring met het ‘runnen’ van een cloud-infrastructuur. Beide dienen immers een beschikbaarheid te hebben op het niveau van zero-outage.

Er is meer nodig

Juist op dit punt gaat het echter vaak mis. Zero-outage cloud computing vereist niet alleen een datacenter-infrastructuur op het niveau van vijf negens. De cloud-aanbieder moet ook een grondige kennis hebben van de bedrijfskritische applicaties die naar de cloud worden gebracht. Op het moment dat de cloud-partner op beide gebieden een beschikbaarheid van vijf negens kan garanderen, zijn zij ook bereid om ‘zero outage’ contractueel vast te leggen.

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

?


Lees meer over


 

Reacties

En welk datacenter in Nederland gaat dit garanderen? Volgens mij hebben we hier in Nederland (Belgie)een Tier III of Tier IV datacenter.......

Zelfs de grootste Cloud aanbieders (zoals bijv. Amazon, e.a) kunnen dit niet eens nakomen (99.999% zero-outage)

En voor zover ze dit wel aanbieden dan is er vaak de regel in de voorwaarden (SLA) die de volgende uitzonderingen zal bieden:

"Niet onder onze uptime garantie vallen netwerkonderbrekingen door onderhoud, DDoS of DoS attacks, storingen door kabelbreuken, storingen door aanslagen, storingen door water en/of brandschade, storingen door (natuur)rampen, storingen door ongelukken, storingen door stroomuitval en/of andere vormen van stroomstoringen, storingen in apparatuur zoals servers en/of de hardware, storingen door misbruik en/of gebruik te maken van netwerk en apparatuur, storingen omwille van fouten van onze medewerkers en/of leveranciers"

Leuke stelling, maar laat ik hier wat gedachten aan toevoegen:

Zero-outage is lekker kort door de bocht en kost sowieso zeer veel geld. Er komt ook wel wat meer bij kijken. Je kunt het wel eisen, maar als de penalty een bos bloemen is bij een outage kom je daar niet ver mee.

Daarnaast gaat het bij (public) cloud vaak om resilience. Bij uitval van Amazon datacenter zijn er inderdaad bepaalde diensten omgevallen. Een goed ontwerp (en Netflix had dit bijvoorbeeld goed voor elkaar) betekent niet dat het uitvallen van een datacenter leidt tot een outage. Een outage dient dus ook in kaders opgenomen te worden wat er precies bedoeld wordt.

Je moet software ook niet verwarren met een cloud dienst. Je software kan prima "plat" gaan terwijl de dienstverlener niets fout heeft gedaan.
Er zit dus wel meer in de keten dan de aanbieder van rekenkracht en data.

Ook kan je software zeer traag reageren, dat valt niet onder een outage maar heeft nagenoeg dezelfde gevolgen.

Tegenwoordig kun je ook gewoon SAP productie draaien op Amazon AWS. (http://goo.gl/O9W2u ). Een public cloud kan ook gemakkelijk meerdere datacenters beslaan. Je moet die zero-outage dan liever draaien op de dienst, niet op het datacenter.

Kortom, leuke stelling, maar tegen welke prijs? Ik ga voor de risico analyse en samenwerking en niet voor het "eisen" en de zinloze boete die daarbij komt kijken.

Daarnaast ben ik wel nieuwsgierig naar de voorbeelden die je aanhaalt in de inleiding en of die voorbeelden gerelateerd zijn aan de public cloud en of de schuld dan ook bij de cloud provider ligt.

Ik kan me niet voorstellen dat iemand ooit bedacht heeft om zijn bedrijfskritische applicatie(s) naar een public clouddienst te brengen. Dat komt o.a. door een aantal punten dat je benoemd hebt.

Maar als je het over de hoge beschikbaarheid van een applicatie/dienst hebt dan zou je de scope van je beschikbaarheid moeten uitbreiden met de schakels in "de hele keten" vanaf je bedrijf tot aan (en in) je cloudleverancier. Zoals ik dit artikel lees zie ik dat er aandacht besteedt wordt aan de zaken aan de kant van de cloudleverancier, dit is niet voldoende.
Ooit heb ik een analyse gelezen over de hoge beschikbaarheid van 99.9% met wiskundige onderbouwing in de hele keten. Het resultaat was dat je dit nooit kan behalen!

Pieter/Reza/Henri: Jullie missen volgens mij het punt van Serge een beetje. Hij zegt dat je helemaal niet naar de publieke cloud moet, maar naar een (eventueel uitbestede) private cloud. De vraag is dan natuurlijk: kan je met je eigen private cloud een hogere beschikbaarheid realiseren? Verder geldt trouwens voor een heleboel bedrijven natuurlijk dat zero-outage of near-zero-outage meer kost dan dat het oplevert.

Public cloud of private cloud - vanuit het perspectief zero outage garantie allemaal een pot nat! Er is maar een beroepsgroep die daar beter van wordt. En dat zijn de juristen. :-)

In essentie wordt gevraagd om betaalbare, betrouwbare en voorspelbare IT diensten. En om dat gerealiseerd te krijgen lijkt het me handiger om te kijken naar mogelijke alternatieven om de primaire processen toch door te kunnen laten gaan als een belangrijk IT onderdeel het eventjes niet doet.
Versus garanties eisen van leveranciers om vervolgens met juristen om tafel te moeten in hoeverre die garanties nageleefd (kunnen) worden.

Bij het lezen van dit artikel voel ik een hele grote déjà vu opkomen naar één van mijn vorige banen......

Als je een private cloud oplossing wil gaan gebruiken, met een 99.999% beschikbaarheid dan hangt daar waarschijnlijk een leuk prijskaartje aan.

Wat is dan nog het verschil met een traditionele IBM mainframe benadering, dedicated datalijnen, alles redundant en geografisch gescheiden uiteraard?



Ik begrijp de Katie tussen zero outage en de 5 negens niet. Als je zero outage wilt bereiken dan denk je in eerste instantie aan meerdere systemen geografische verspreid en dusdanig met elkaar geschakeld dat bij uitval van een of meerdere systemen er altijd een blijft functioneren. Het gezegde een is geen geeft aan dat je dus minimaal 2 systemen moet hebben, maar drie zou al veel beter zijn om echt onafhankelijk te kunnen handelen. Als deze systemen elk in een tier-3 datacenter staan, dat is volgens mij 4 negens, dan bereik je op systeem niveau een hogebeschikbaarheid.

Het verschil tussen 5 negens en 100%, oftewel zero outage kan in de praktijk wel een kostenverhoging betekenen van honderden procenten. Parallel schakelen van systemen is een oud principe dat ook in de cloud goed kan werken. De meeste cloud leveranciers bieden diensten in meerdere geografische datacenters aan, je ziet dat er downtime op systeemniveau onstaaat op het moment dat een belangrijke dienst alleen in 1 datacenter staat. Pas na deze downtime wordt de applicatie gedistribueerd.

Allen,

Leuk om te zien dat de zero-outage stelling toch wel enkele reacties en bedenkingen bij jullie teweeg brengt.


Tijdens de laatste seminaries en lezingen waar ik aan deelnam, bleek zero-outage en zero-touch (maw automatisering van IT processen) toch wel een trend te zijn waar de meeste (grote) providers hun investeringen aan toevertrouwen en streven naar six sigma guaranteed quality.

Wat me opvalt in bovenstaande reacties, is de afweging "kost" tov "opbrengst".

Ik ga hier mee met Henri's stelling - een goed partnership en een degelijke risico-analyse leiden meestal tot de gewenste ROI.

Ook Willem en PaVaKe zijn correct - door de clouddiensten in geografisch verspreide datacenters aan te bieden, zal de outage op applicatieniveau sterk gereduceerd worden, wat uiteindelijk het belangrijkste is voor onze business afdelingen, niet? Het secuur opvolgen en/of uitvoeren van fail-over tests is hier uitermate belangrijk.

Echter, zoals vaak wordt gezegd "stilstaan is achteruit gaan", worden er nog steeds tonnen geïnvesteerd in het verder optimalizeren van de diverse clouddiensten, dus...

Zero-outage... to be continued!?

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

×
×