Er wordt op dit moment nog veel te weinig gebruik gemaakt van cloud bursting. Komt dit doordat de techniek hierachter te gecompliceerd is, is de business case niet overtuigend, of is het simpelweg nog een gebrek aan kennis en ervaring?
Cloud bursting geeft de mogelijkheid om voor korte tijd workloads, zoals websites en applicaties, te laten uitschalen naar de cloud. De cloud wordt hiermee als een overdrukventiel gebruikt voor de bestaande infrastructuur. Het tijdelijk bij een cloud provider betrekken van capaciteit is vaak goedkoper en efficienter. Zeker als het niet rendabel is, of er simpelweg niet genoeg capaciteit aanwezig is, om de bestaande infrastructuur het hogere gebruik van de applicatie te laten opvangen.
Bij een cloud provider is deze capaciteit snel af te nemen zonder initiële investeringen en hoeft er uitsluitend afgerekend te worden over de periode dat de capaciteit verbruikt is. Dit is vaak vele malen voordeliger dan het op voorhand neerzetten van capaciteit in de eigen omgeving. Op deze manier wordt een hybride situatie gecreëerd tussen een private cloud en de public cloud van de provider.
Wat bereik je met cloud bursting?
Cloud bursting is interessant voor organisaties waarbij het gebruik van applicaties fluctueert. Meestal zijn dit web gebaseerde applicaties die publiekelijk toegankelijk zijn, maar soms ook intern georiënteerde applicaties die een tijdelijk karakter hebben. Denk hierbij bijvoorbeeld aan applicaties rond evenementen zoals verkiezingen of deadline gebonden zaken zoals vergunningaanvragen bij de overheid. Hoe onvoorspelbaarder het gebruik van de applicatie hoe groter het nut van cloud bursting.
Traditioneel gezien worden voor dit soort applicaties infrastructuren ontworpen en gebouwd die gedimensioneerd zijn de op de piekbelasting. Oftewel; welke infrastructuur is er noodzakelijk om de applicatie onder vollast te ondersteunen en welke systeemcapaciteit hoort daarbij? Dit betekent dat de applicatie gedurende de periodes van normaal gebruik overgedimensioneerd is. Heeft deze overdimensionering niet plaats gevonden dan is het uiteraard de vraag of de infrastructuur de piekbelasting van de applicatie wel aankan. Door het toepassen van cloud bursting blijft de applicatie beschikbaar, ook bij toenemende belasting.
Welke scenario’s zijn er?
Er zijn verschillende scenario’s denkbaar voor een cloud bursting architectuur. Het meest voordehand liggende scenario is van een private cloud naar een public cloud, maar andere scenario’s zijn denkbaar
|
Basis |
|
Burst locatie |
Scenario |
|
Private cloud |
-> |
Private cloud |
Burst out naar een private cloud |
|
Private cloud |
-> |
Public cloud |
Burst out naar een public cloud |
|
Public cloud |
-> |
Public cloud |
Burst out van een public cloud naar een andere public cloud (met meer, of andere, capaciteit) |
De voor- en nadelen van een cloud bursting architectuur
| Voordelen | Nadelen |
|
|
De business case
De cloud provider rekent af op basis van de werkelijk gebruikte capaciteit. Meestal wordt afgerekend voor de basis elementen zoals cpu, memory, storage en netwerkverkeer. Wordt er geen gebruik van gemaakt dan zijn er ook geen (of beperkt) kosten aan verbonden. In de eigen omgeving, zoals een private cloud, zijn er directe kosten verbonden aan het configureren en beschikbaar houden van de infrastructuur. Alle capaciteit die geconfigureerd wordt om de eventuele piekbelasting op te vangen is rechtstreeks terug te vinden als kostenpost op de p&l van de applicatie eigenaar. Door in de eigen omgeving (private cloud) te dimensioneren op de normale belasting en al het extra gebruik te laten afhandelen door de public cloud, kan er dus bespaard worden.
De business case is betrekkelijk eenvoudig. De kosten van de public cloud zijn niet noodzakelijkerwijs goedkoper dan de private cloud, maar omdat deze op basis van een pay-per-use-model worden afgenomen is dit voordeliger dan in de eigen infrastructuur servers laten draaien De vraag hoe snel dit terugverdient wordt kan beantwoord worden door uit te zoeken hoe hoog te kosten zijn om de infrastructuur geschikt te maken voor cloud bursting.
Hoe werkt cloud bursting precies?
Cloud bursting is een architectuurkeuze, waarbij er vooraf rekening gehouden wordt met de mogelijkheid om een applicatie (al-dan-niet geautomatiseerd) gebruik te laten maken van capaciteit van een cloud provider. Dit wordt doorgaans op applicatieniveau ingeregeld, maar het is ook mogelijk om dit op infrastructuurniveau te doen. Op het moment dat de belasting van een applicatie hoger wordt dan een vooraf gedefinieerd niveau wordt er een beslissing genomen om de capaciteit van de applicatie te vergroten door middel van het uitschalen van de systemen. Er wordt simpelweg meer capaciteit toegevoegd aan de applicatie.
Op het moment dat de bestaande infrastructuur deze extra capaciteit niet meer kan leveren wordt er aanspraak gemaakt op de capaciteit van de cloud provider. Bij de cloud provider staat capaciteit klaar waar de organisatie gebruik van kan gaan maken. Het kan zijn dat deze capaciteit door de cloud provider gereserveerd wordt, maar dit is niet noodzakelijk. De afspraken hieromtrent worden met de cloud provider vastgelegd. Het uitschalen van de infrastructuur gebeurt door vooraf gedefinieerde en geconfigureerde servers in de cloud op te starten, of door deze automatisch te laten configureren door een ‘rapid deployment engine’. Dat laatste heeft uiteraard de voorkeur, omdat hiermee het complete proces geautomatiseerd verloopt.
Wat is er voor nodig?
Om cloud bursting mogelijk te maken zijn er een aantal architectuur voorwaarden die ingevuld moeten worden.
|
Architectuurvoorwaarden: |
|
Cloud capaciteit (al dan niet gereserveerd) op basis van een pay-per-use model |
|
Self Service portal (inclusief API) bij de cloud provider |
|
Rapid Deployment Engine om servers in de cloud te kunnen configureren zonder handmatige interventie |
|
(Intelligente) load balancers |
|
Stateless applicatie |
|
Content- en/of database distributie technologie |
|
Netwerk connectiviteit tussen cloud A en cloud B |
Aan de hand van dit artikel geïnspireerd geraakt? Kijk eens naar het applicatie landschap van jouw organisatie en bekijk welke applicaties aan de hiervoor genoemde criteria voldoen. Een proof-of-concept is snel opgezet en kan inzichtelijk maken of de business case kloppend te maken is en op welk moment de investering in een cloud bursting architectuur wordt terugverdiend.
@Reza,
1- webinterface ipv Word
2- data werd in een database opgeslagen ipv platte bestanden
3- Interactie met de onderliggende hardware en andere applicaties was zeer anders, cloud oriented.
je beschrijft dit forum.
@Reza,
ook Apple gebruikt voor de imac etc de X86 architectuur, met de Ax architectuur is daar pas verandering in gekomen…., maar applicaties en X architectuur hebben niet zo veel met elkaar te maken….
Delivery model elke architectuur heeft ergens een delivery model als jet in de markt staat ….
De toekomst wordt niet gedreven door de techniek…..
Ik geloof er zelf niet in om cloud bursting op bestaande software toe te passen. Lijkt me zonde van de investering en fundamenteel blijven er tekortkomingen in zitten.
Beter begin je “Cloudborn”, als zijn er nu nog een hoop slechte keuzes die gemaakt kunnen worden.
Voer vcor meer.
Reza, ben gecharmeerd van je opsomming 🙂 En Mauwerd laten we dit forum alsjeblieft niet in één adem noemen met cloud. Dit is (internet) legacy in zijn puurste vorm.
Maarten, kleine cross-post, de toekomst wordt gedreven door adaptie van techniek 😉 Ik geloof overigens dat de toekomst juist wel gedreven wordt door techniek, maar dat is wellicht kip-ei verhaal.
@mauwerd,
Ja zoiets maar met volledige functionaliteiten en gebaseerd op een andere architectuur.
@Maarten
Meer dan 95% van applicaties die in de afgelopen jaren geschreven zijn, zijn gemaakt voor Windows OS en gebaseerd op x86 processorarchitectuur. Misschien moest ik in mijn reactie duidelijker zijn en verwijzen naar OS architectuur van Windows.
In ieder geval, ik probeer in mijn reactie aan te geven dat de inflexibiliteit van de huidige applicatie(architectuur) een van showstoppers is voor de belofds van Cloud. Om de zaken zoals wat Bart hierboven aangegeven heeft waar te maken moet je van een ander soort applicaties gebruik maken dat veel intelligentie in zich hebben.
@Bart
Ik weet niet of cloud bursting/balancing nog onontgonnen gebied is, verschillende providers bieden hiervoor al lange tijd opties en het is om deze redenen dat ik niet over SDI maar SDN spreek in voorgaande reactie. Want inderdaad zijn bestaande applicaties nog niet cloud agnostic – vaak niet eens platform onafhankelijk of horizontaal schaalbaar – maar zullen ze uiteindelijk altijd weer gebonden zijn aan een oplossing.
Al weer enige tijd geleden schreef ik hier al eens wat over: https://www.computable.nl/artikel/opinie/infrastructuur/4445784/2379248/de-valkuilen-in-cloud-computing.html
VM provisioning binnen één container kan dan misschien wel in minuten maar om dit ‘multi-tiered’ over verschillende architecturen te doen kost nog dagen. Tel daarbij op dat virtualisatie over meerdere lagen van de stack het zicht op resources alleen maar troebeler maakt en daardoor dus lastiger voorspelbaar waardoor de kosten lineair toenemen met de complexiteit. Achilleshiel blijft toch vaak configuratiemanagement dat nog altijd de basis vormt van het beheer, zelfs een Service Knowledge Management system kan niet zonder deze informatie.
In tegenstelling tot service support is delivery van Cloud bursting dan ook niet zo moeilijk: Pack, Stack and Rack!
Want cloud computing is eigenlijk gewoon een vervolg op het ‘web-enablen’ van systemen welke toch weer vaak aan platformen gebonden zijn. Net als de Enterprise Service Bus 2.0 omdat standaardisatie op alle lagen vaak een illusie is waardoor je vanuit de Microsoft oplossingen niet zo makkelijk naar Google burst of vice versa. En nee, ik geloof niet in cloud onafhankelijke applicaties die ‘seamless’ tussen aanbieders te migreren zijn omdat dit niet past bij de verdienmodellen van providers. En zoals Jeroen van Yperen in zijn opinie: ‘Een wolkje strooigoed’ al aangaf hebben deze leveranciers ook geen baat bij efficient resource gebruik waardoor er mogelijk een global server sprawl ontstaat.
Dus ja, het is een architectuurkeuze waar je dan vaak ook langer aan vastzit en welke dus niet vanuit de techniek genomen moet worden want het gaat uiteindelijk om de delivery van informatie. Tenslotte zijn op basis van business criteria al veel kritische workloads verdeeld over meerdere sites om zo te voldoen aan de eisen rond beschikbaarheid en response waarbij vaak een vorm van workload balancing gebruikt wordt aan de onderkant van de stack door (a)synchrone replicatie.
@Henri
Zoals al meermaals aangegeven is het handig als je eerst vanuit een architectuurvisie de behoeften bepaald in plaats van elke vraag direct met cloud te beantwoorden. Ik weet zeker dat jij op de operatietafel niet afhankelijk wilt zijn van een onbetrouwbaar netwerk, je creditkaart gegevens in een publieke wolk zet of andere diensten vertrouwd die met een kortzichtige blik in de cloud gezet zijn. Hoewel je natuurlijk achteraf ook nog je vrouw de schuld kan geven als blijkt dat het niet allemaal goud is dat er glimt;-)