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.
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.
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 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.
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.
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.
Bart,
Leuk artikel waar voor dank. Bovenstaand is vooral gedoeld op de technische kant van Cloud bursting. Wat ik merk is dat de politieke kant van het verhaal vaak spelbreker is. Hoe mooi de TCO of businesscase ook is, heeft men toch vaak Cloud Water.
Security,verantwoordelijkheid en beschikbaarheid zijn daar vaak de bottleneck.
Hoe ga jij daar mee om? Misschien kan je wat voorbeelden schetsen.
Bart,
Leuk artikel waar voor dank. Bovenstaand is vooral gedoeld op de technische kant van Cloud bursting. Wat ik merk is dat de politieke kant van het verhaal vaak spelbreker is. Hoe mooi de TCO of businesscase ook is, heeft men toch vaak Cloud Water vrees. Security,verantwoordelijkheid en beschikbaarheid zijn daar vaak de bottleneck.
Hoe ga jij daar mee om? Misschien kan je wat voorbeelden schetsen.
Bart,
Mooi artikel!
A)Je gaf aan dat cloud bursting interessant is voor organisaties waarbij het gebruik van applicaties fluctueert. Ik ben het met je eens maar als je kijkt naar de lijst van "wat er voor nodig is" dan denk ik dat aan de realisatie van de randvoorwaarden een prijskaartje hangt dat niet voordelig is voor het aanbieden van een applicatie waarvan het gebruik fluctueert! Ik ben benieuwd op welk getal je uitkomt als je de kosten van Architectuurvoorwaarden bij elkaar optelt.
B)Een van onderwerpen op je lijst van Architectuurvoorwaarden is "Stateless applicatie"
Veel applicaties (of bijna alle applicaties)in de huidige vorm kunnen we niet als "Stateless applicatie" beschouwen. Dit betekent dat de realisatie van Cloud Bursting zoals je dat beschrijft, bevat ook het herschrijven van applicaties die voor dit concept gebruik kunnen worden.
C)Cloud Bursting is (naar mijn mening) gebaseerd op Software Defined Infrastructure. Twee DC`s die Software Defined zijn kunnen de flexibiliteit zoals je het hierboven beschreven hebt aanbieden. Bursting tussen twee verschillende DC`s die niet software defined zijn is ook mogelijk maar niet zo fraai en flexibel zoals je dat hierboven aangeeft (dit kan ik persoonlijk niet echt een bursting noemen)
Nogmaals, ik ben het met je eens dat deze oplossing interessant is als je "tijdelijk" extra capaciteit nodig hebt. Als je DC geen software defined is dan zou dit concept rendabel zijn als je voor je tijdelijke dienst weinig interactie nodig hebt met je huidige back-end omgeving. Denk aan een extra webserver en database server voor een verkiezingscampagne, marketingcampagne (voor zorgverzekeraars, reisbureaus, energieleveranciers etc)die bij een hoster geplaatst zijn.
tl;dr
Als je wilt bursten naar de cloud, waarom niet het geheel in de cloud zetten? Veel eenvoudiger te realiseren. Nu creeer je een hele niet intuïtieve manier van het gebruiken van cloud computing en creer je allemaal risico's. Elke keer als de basis veranderd moet je het bursten weer gaan testen.
Henri,
Als je DC gebaseerd is op SDI dan heb je het niet over "veranderen van de basis".
Ik vind je opmerking enigszins terecht, dat probeerde ik ook in Punt C duidelijk te maken.
Bart,
Ik geloof dat ik me wel aan kan sluiten bij de eerste reactie van Reza, van cloud naar cloud is naar mijn mening meer balanceren dan bursten.
En inderdaad zijn er weinig stateless applicaties waardoor data(opslag) veelal het probleem is. Regels hieromtrent kunnen trouwens plaatsing van een workload in een public cloud verbieden, naast de technische aspecten zijn er dus ook nog wat organisatorische waar rekening mee gehouden moet worden.
Een private cloud binnen eigen datacenter heeft niet deze problemen en de kosten van netwerk liggen lager maar er zitten ook nadelen aan SDN architectuur. Beheersbaarheid is er één van wat vaak tot uiting komt in capaciteitsmanagement want inderdaad dimensioneer je een omgeving niet voor de pieken maar is gedeeld resource gebruik ook weer niet optimaal voor stabiele scheduling.
@Henri
Uiteraard kun je alles in de cloud zetten maar reversed cloud bursting komt ook nog weleens voor om bijvoorbeeld PCI of HIPAA compliant te blijven. En hoewel je het niet met me eens bent, cloud computing is uiteindelijk niet meer dan een delivery model. Een punt dat namelijk ook niet echt goed onder de aandacht gebracht wordt in artikel is de plaats van gebruikers. Een periodieke piek zoals bijvoorbeeld een jaarafsluiting kun je namelijk vaak beter toch intern opvangen dan in de cloud.
Ach er zijn veel scenario's mogelijk en ook vele redenen om het niet te doen. Public cloud computing is niet de enige manier om dingen te bereiken en het hangt ook sterk af van wat je hebt staan.
Maar als je dingen gaat ontwerpen dan is het in ieder geval een goed idee om te kijken wat het kan betekenen om met commodity diensten aan de gang te gaan.
Uiteraard preek ik voor eigen parochie aangezien ik me nagenoeg alleen maar richt op de grote publieke dienstverleners. Ik geloof dat het gros hier namelijk de komende jaren voor zal kiezen.
Overigens is cloud bursten of uberhaupt de architectuur achter schaalbaarheid pittig. Relationele data schaalt vrij lastig en niet relationele data vergt weer heel veel coderen en is nog volop in ontwikkeling zodat de juiste keuzes van vandaag de legacy van morgen is.
Schaalbaarheid schurkt heel dicht tegen standaardisatie aan en standaardisatie is op zijn beurt vaak weer weinig flexibel. Het lijkt dus een geval van winnen en verliezen.
Skills voor SDI zijn in ieder geval belangrijk.
PS: SDI is geen garantie voor toegankelijk maken van cloud bursting. Eigenlijk werkt het verlengen van je reken en verwerkingscapaciteit volledig af van de architectuur van de oplossing.
Het minen van bitcoins leent zich heel goed. Veel websites ook nog wel, maar zelfs bij webapplicaties begint het al snel te wringen.
Heren,
Ik ben echt heel erg positief verrast over het aantal zeer goede inhoudelijke reacties. Ik ben blij dat jullie inhoudelijk reageren op dit nog erg onontgonnen onderwerp.
Jullie leggen haarscherp bloot waar de onduidelijkheden in dit architectuur (want zo duid ik het aan) zitten. Er zijn nog jammerlijk weinig praktijkcases te vinden waarbij dit mechanisme efficiënt wordt ingezet. Ik ben er echter van overtuigd dat op termijn applicaties volledig ‘cloud aware’ zullen worden. Dus dat de applicaties besef hebben van:
1. De fysieke infrastructuur waar ze op draaien en de capaciteit daarvan
2. Het aantal actieve gebruikers van de componenten en de schaalbaarheid restricties ervan
3. De geo-positie van de applicatie ten opzichte van de gebruiker
4. De performance van de applicatie op dat moment
Een dergelijke intelligentie in de applicatie voorkomt dat de applicatie stukdraait onder hoge belasting. Belangrijker nog: dergelijke intelligentie en flexibiliteit zorgt er ook voor dat dit soort mechanismes makkelijker ingezet kunnen worden.
Dat klanten Cloud watervrees hebben (mooi woord, die leen ik van je!) is zeker waar, maar dat is zo-een generiek probleem dat ik er een separaat artikel aan zal wijden.
De suggestie dat Software Defined Infrastructure dit mogelijk maakt… tja.. het gaat zeker helpen, maar strikt noodzakelijk is het natuurlijk niet.. afijn, dat ook al is voer voor een volgend artikel.
Bart
Bart,
Er is geen twijfel dat de architectuur van applicaties in de toekomst heel anders gaat worden. De huidige architectuur, gebaseerd op x86 platform, is flink verouderd en een showstopper voor innovatie binnen ict. Apple heeft met introductie van App hier een begin van gemaakt. De trage adoptie van Windows 8, problemen op het gebied van BYOD, ellende binnen VDI trajecten en nog meer hebben allemaal te maken met de huidige architectuur van applicaties.
Ik heb tijd geleden een rapport gelezen over een experiment waarin applicaties zoals tekstverwerkers flink anders geschreven waren:
1- de interface was heel anders (een uitgebreid chat-programma ipv Word),
2- data werd in een database opgeslagen dan als platte bestanden (dus geen .doc, .pdf, .xle etc),
3- Interactie met de onderliggende hardware en andere applicaties was zeer anders,
En nog meer.
Dit zegt genoeg over het feit dat we in de toekomst totaal andere OS en applicatiearchitectuur hebben dan nu. In dat geval zullen deze ontwikkelingen gericht zijn op de realisatie van het nieuwe delivery model: Cloud (Computing)
@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: http://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;-)
Ruud Mulder | 9 december 2013 13:20 
Reza Sarshar | 9 december 2013 16:04 
Henri Koppen | 9 december 2013 17:02 
Bart Veldhuis | 10 december 2013 21:48 
Lees meer over