Home Cloud Cloudketens: je krijgt wat je vraagt, dus weet wat te vragen

Cloudketens: je krijgt wat je vraagt, dus weet wat te vragen

87

Public clouds zijn de échte innovatie van de laatste jaren, want ‘private cloud’ is veelal gewoon een nieuwe naam voor een schaalbaar en gevirtualiseerd datacentrum. IaaS oftewel Infrastructure as a Service lijkt mooi, maar kent sterke boemerangeffecten als je niet uitkijkt.

De crux van IaaS is namelijk dat je redelijk fijnmazig bouwstenen kunt huren, en die als IT-afdeling zelf samensmeedt tot bijvoorbeeld overloopcapaciteit van de eigen website. Elk van die bouwstenen kent zijn eigen SLA, en bij ongeplande downtime biedt de vendor door de aard van het beestje vrijwel nooit volautomatische failover. We moeten altijd aan onze kant ook ‘meegaan’ in die uitwijkactie, al is het maar door DNS namen of loadbalancing aan te passen. En ook duidelijk specificeren, met accepteren van bijbehorend kostenplaatje, tegen welk soort rampen we allemaal beveiligd wensen te zijn.

Amazon Web Services, pionier op IaaS-vlak, is hier in zijn manuals heel duidelijk over en werkt met ‘zones’ voor redundantie. In één zone zitten beschermt tegen hardware-uitval en beperkte site-uitval, over meer zones spreiden is duurder maar beschermt ook tegen meer.

In 2011 had Amazon een forse dagenlange storing in één der US datacentra, en wat bleek: zeker de helft van de klanten, tot aan grote websites toe, had alle eieren in één zone-mand gestopt en had soms miljoenen euro’s aan direct meetbare schade. Bij de andere helft hadden IT en business wél de manuals gelezen en dat beetje extra geïnvesteerd in multi-zone scripting en replicatie, en dat verdiende zich nu dubbel en dwars terug.

Voor opkomende concurrenten zoals RackSpace en Microsoft Azure ‘VM role’ gelden soortgelijke caveats, maar de problematiek bij IaaS-clouds ligt zeker niet alleen bij ons als interne IT-staf. Ook in wat we met de provider afspreken zitten de nodige variabelen, en zeker kleinere en/of op deelterreinen gespecialiseerde IaaS-spelers eisen soms dubbelchecken op alle onderdelen.

Wat is bijvoorbeeld de exacte RTO (Recovery Time Objective) bij storingen, en het RPO (Recovery Point Objective) qua hoeveelheid data die verdwenen mogen zijn? En zijn er verschillen tussen sitestoringen en serverstoringen, oftewel heeft men eigenlijk wel een volledig redundante datacentrum-infrastructuur staan voor als de primaire site uitvalt? En kunnen we mogelijk ook een gespiegelde test-IaaS setup tijdelijk huren, waar we alle scenario’s inclusief langdurige piekbelasting en systeemuitval kunnen uitproberen zonder de normale productie te verstoren?

Het moge duidelijk zijn: clouds zijn geen panacee maar gewoon een volgende evolutiestap, en wij als IT-diersoort, maar ook onze vendoren zullen nieuw gedrag moeten aanleren als we in dat nieuwe tijdperk willen overleven en groeien. Waarin we dezelfde functionaliteit als van interne servers behouden mét cloud-extra’s zoals variabele kosten en capaciteit.

Voor andere modellen zoals PaaS (Platform as a Service) en SaaS (Software as a Service, het vroegere Application Service Provider-gebeuren) gelden deels analoge adviezen maar daarover bloggen we mogelijk een volgende keer meer…

Erik de Ruijter

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in