Cloud computing biedt in theorie onbegrensde groeimogelijkheden maar wordt tot op heden vooral beperkt door bandbreedte. De kosten en beperkingen van het netwerk worden vaak onderschat of simpelweg vergeten. En dit geldt niet alleen voor de bovenkant, de toegang van cliënt naar de cloud applicaties, maar ook naar de achterliggende opslag.
Iets om bijvoorbeeld rekening mee te houden is dat veel aanbieders van cloud computing wel aantallen gigabytes bieden maar geen garanties in IOPS, het aantal lees- en schrijfacties naar de opslag. En dat kan, zeker als opslag gedeeld wordt uiteindelijk voor vervelende verrassingen in de prestatie van applicaties zorgen. En de schaalbaarheid proberen te vergroten door de werklast te verdelen over verschillende computers verschuift probleem alleen maar naar de onderkant, vaak de database die de bron van informatie is voor vele processen en services.
Data(base) bottleneck
Schaalbaarheid van onderliggende database bepaalt dus ook in grote mate de elasticiteit van een oplossing, zelfs in de theoretisch oneindig schaalbare cloud. Nu zijn er verschillende oplossingen om de schaalbaarheid van databases te vergroten zoals clustering (Azure), caching (Google) en de op file gebaseerde oplossingen zoals noSQL (Amazon). Het gebruik van deze technieken vraagt echter aanpassing van de onderliggende datalaag. En hoewel inspanning en kosten hiervan grotendeels bepaald worden door beoogd doelplatform van cloudleverancier zal het duidelijk zijn dat een dergelijke migratie geen sinecure is. Het zijn dus vooral de applicaties die niet alleen de mogelijkheden van cloud computing bepalen maar vooral ook de migratie kosten. En zeker voor bestaande applicaties kunnen de investeringen voor een transitie naar de cloud weleens de uiteindelijke besparingen overstijgen.
Hardware gebonden
Probleem met de toegang tot de opslag komt echter ook voor bij het virtualiseren van de infrastructuur. In plaats van dit op te lossen door aanpassingen te maken aan applicaties wordt dit vaak opgelost met I/O cachekaarten of flashdisks. Er wordt dus vaak voor een hardware oplossingen gekozen waardoor er uiteindelijk een afhankelijkheid met het platform is. Ook eisen als schaalbaarheid en herstelbaarheid worden nog teveel vanuit de 'box' ingevuld waarbij beperkingen van de techniek bepalend zijn voor de mogelijkheden. Zo klonen we bijvoorbeeld servers meermaals en voegen een vorm van load balancing toe om de werklast te verdelen. En op dezelfde manier proberen we ook de betrouwbaarheid van applicaties te vergroten waardoor dus het aantal servers blijft groeien. Uiteindelijk dus allemaal niet zo heel erg efficiënt en het is dan ook niet zo vreemd dat it nog steeds als een kostenpost gezien blijft worden.
Paradox
Om echt te kunnen profiteren van het nieuwe computerparadigma van cloud computing zijn dus aanpassingen aan applicaties onvermijdbaar. Want het blijven invullen van behoeften zoals bijvoorbeeld mobiliteit met deeloplossingen als terminal services en vdi maakt de architectuur niet overzichtelijker. Dat bemoeilijkt niet alleen de holistische visie erop maar ook aansluiting op infrastructuren van derden voor een hybride locudoplossing. Want uiteindelijk kan natuurlijk niet alles naar de cloud gebracht worden maar veel van de dertien-in-een-dozijn services wel. Maar om te bepalen wat je kunt besparen met cloud computing is inzicht in de kosten van de service nodig en juist dit ontbreekt vaak bij organisaties. Want veel infrastructurele zaken zoals stroom, koeling, netwerk, beveiliging maar ook beheer worden namelijk nog niet in rekening gebracht van de gebruiker waardoor cloud computing goedkoper lijkt maar niet hoeft te zijn.
Architectuur verschillen
Natuurlijk behoeft niet iedere applicatie een schaalbare infrastructuur en is dit alleen interessant voor de Enterprise applicaties die door duizenden tegelijk gebruikt worden of enorme aantallen transacties moeten verwerken. Veel bestaande applicaties zijn ook nimmer ontwikkeld met schaalbaarheid als uitgangspunt. Probleem is echter dat de meeste wel ontwikkeld zijn vanuit een andere architectuur, namelijk die van netwerk computing. Terwijl cloud computing juist een grote gelijkenis heeft met grid computing. Hierbij zorgt virtualisatie voor de dynamisch schaalbare resources en het grid voor federatie van middelen, uniforme api's maar ook generieke toegangsmechanismen. Het 'cloud enablen' van applicaties gaat dus niet alleen om aanpassingen in de datalaag maar ook van de middleware, zeg maar de service bus die voor het grid van cloud computing zorgt.
Platformdefinities
En het zijn deze bouwstenen die de afhankelijkheid weg nemen met onderliggend platform en de grenzen van het datacenter laat vervagen. Natuurlijk kunnen we de infrastructuur virtualiseren maar dat is nog geen cloud computing, tenminste niet platform as a service. Misschien dat daarom bij uitbesteding ook zo vaak verwarring is over de definitie platform. Zo wordt de ene keer de middleware en database als onderdeel van het platform gezien en de andere keer juist weer als applicaties. Hierdoor wordt de belofte van cloud computing – een schaalbare en flexibele oplossing waarbij grenzen niet door techniek maar de economische aspecten bepaald worden – dus niet altijd waar gemaakt. Want pas als applicaties aangepast worden aan de nieuwe architectuur van cloud computing kunnen eisen als schaalbaarheid en betrouwbaarheid hoger in de stack, binnen de software zelf ingevuld worden.
Servicegericht
Dan is er niet alleen meer dynamiek in de infrastructuur maar gaan de kosten pas werkelijk omlaag. Bijvoorbeeld door alleen het herstelpunt en hersteltijd van de kritische services te verbeteren via database synchronisatie in plaats van alles via gebruikelijke 'one-size-fits-all' oplossing met replicatie van gecentraliseerde opslag. Of door het elimineren van ruim aanwezige overlap in functionaliteiten binnen de bestaande infrastructuur door te rationaliseren. Maar omdat kosten voor de baten uit gaan wordt meestal gekozen voor het vrijwel ongewijzigd laten van applicatielandschap. En dus zijn steeds meer toevoegingen aan de architectuur nodig om de wensen van de organisatie zoals mobiliteit en flexibiliteit te kunnen blijven ondersteunen waardoor kosten van ict blijven stijgen. Dit mede omdat omslag van kosten teveel gebaseerd zijn op servers in plaats van service en er dus nog veel verborgen kosten zijn.
Dit artikel is voor mijn *onweerstaandbaar* om niet op te reageren. Goed geschreven, goed leesbaar en ik kan niet zeggen dat er fouten of onwaarheden in staan. Tot zover het goede nieuws.
Dit soort stukken lees ik heel veel. Ze worden gebruikt om aan te geven dat cloud computing eigenlijk helemaal zo goed niet is, ofwel er lijkt geen winst te zitten in cloud computing. Ik zal een analogie geven. Laatst sprak ik met een kalkoen over kerst. Die zei dat het maar een ordinaire vreetpartij geworden was en verzuchtte zich dat mensen niet meer gaven om de oude tradities en de geest achter de kerst-mis. Hij pleitte ervoor dat er meer taart gebakken moest worden en dat veel vlees slecht was voor je cholesterol.
Voel je een beetje waar ik naar toe ga? Het klinkt als een it-bedrijf die de bedreiging voelt van verandering (maar er is een oplossing, hier later meer over).
Het klopt inderdaad dat cloud computing niet de technologie is om je legacy software en architectuur naar te verplaatsen, ondanks dat het kan en dat er bedrijven zijn die dat graag voor je doen. Je krijgt dan in principe de problemen die je beschrijft en als bonus krijg je er nog wat nieuwe problemen bij.
Dat zegt niets over of cloud computing zinvol is en winst oplevert, het gaat meer om dat je de cloud computing dan niet op juiste wijze gebruikt. Dit is ook de reden waarom infrastructure as a service (iaas) de minst aantrekkelijke levering is van cloud computing. Hoewel het wel goed aansluit bij wat (traditionele) IT-ers kennen en begrijpen.
Voor enterprises heb je meer strategie nodig om te profiteren van cloud computing, niettemin geloof ik dat te lang wachten met adapteren nog wel eens desastreus zou kunnen zijn. Een reactie is niet de plaats om dit uit de doeken te doen, maar kort door de bocht komt het hier op neer (als 1 van meerdere manieren); je besteed langzaam wat generieke zaken uit zoals e-mail, tools om samen te werken, engagement met klanten en misschien wel documenten en backup. Voor de wat grotere applicaties kijk je bijvoorbeeld maar de mogelijkheid te migreren naar hun online oplossing.
Cloud computing is sterk en groot door te denken in standaardisatie en commodity. Software en data opslag vereisen inderdaad een andere benadering, maar naast dat dit niet heel complex meer is (de cloud computing provider neemt wat complexe zaken geautomatiseerd over) ben je wel degelijk schaalbaar en IOPS die lust ik voor ontbijt. Dat databases en performance prima samengaan met cloud computing lijkt mij wel bewezen door Google; die heeft veruit de grootste database ter wereld en ik kan me niet herinneren dat iemand tegen me geklaagd heeft dat Google search traag is.
Maar cloud comuting is meer. Juist door de aard van cloud computing hoeven mensen niet op kantoor te zitten en de huishoudens samen hebben voldoende bandbreedte. Je moet ook niet willen om alles door de cloud heen naar je toe te trekken. Als je met software in een browser werkt is de bandbreedte consumptie laag.
Een andere grote winst is dat je door adoptie van cloud computing veel minder beheerders en dergelijke nodig hebt. Als je het goed opzet is er gewoon veel minder werk nodig omdat veel taken geautomatiseerd zijn. Het bijbestellen van opslag capaciteit of een server hoeft niet via lange dure procedures waarbij de it-afdeling ‘moeilijk, moeilijk’ roept.
En vergis je niet in de price-drop die je nu ziet. Ik moest even wat op Windows Server 2012 testen. Weet je wat het virtualiseren van een Windows 2012 Server kost per maand bij Windows Azure? 8 Euro! Oh, en ik had hem ook binnen vijf minuten tot mijn beschikking.
Dus ja, cloud computing kan duurder uitpakken als je het verkeerd (traditioneel) aanvliegt. Cloud computing is nu eenmaal anders dan on-premise met software die in een ander tijdperk is geschreven.
Maar cloud computing is the way to go. Er is niet één molecule in mijn lichaam die daar aan twijfelt. En ik sta daar niet alleen in. Als je kijkt naar alle grote IT (software) bedrijven in de wereld zie je dat ieder vol inzet op cloud computing. Met de toespraak van Neelie Kroes vorige week wordt ook wel duidelijk dat de EU in cloud computing gelooft en dat het er gewoon aankomt.
Dus zoek naar de juiste mensen die snappen wat het is en hoe je het toepast en zorg dat je niet die kalkoen voor kerst bent.
Het is een aardig artikel maar zoals Henri ook aangeeft, verteld door een leverancier die is gevraagd een cloudoplossing te bouwen en deze offerte niet heeft gewonnen.
In de wereld van de cloud moet je geen afspiegeling verwachten de traditionele wereld, in de cloud worden infrastructuren anders ingericht. Bandbreedte om aan te sluiten op de cloud zal je altijd nodig hebben, daar verandert niet zoveel aan, daarna gaat het allemaal anders. Ik baseer mijn kennis op Openstack dat sterk in opkomst is in de cloudwereld.
In Openstack wordt storage ingericht met objectbased storage op basis van lage snelheid disken. Deze storage is goedkoop, relatief snel en kan redundantie bieden, dus back-up is niet meer nodig. Voor servers wordt meer gewerkt met JBOS (Just a Bunch Of Servers) of specifieke virtualisatie. Het bouwen van een oplossing begint met een voorafgedefineerde architectuur waar je niet van kan afwijken, aangestuurd door specifieke pooling, bijvoorbeeld crowbar van Dell. Dell heeft ook een openstack referentie architectuur.
Vergeet wat je nu weet en stap in de cloud oplossingen en vind uit dat de cloud architecturen goed kunnen werken met een generieke architectuur.
Zoals al vaker aangegeven je moet om te beginnen geen transactie gerichte database met 10.000 transacties per seconde in de cloud gaan zetten, maar heel veel applicaties werken goed en “performant”. Het gaat natuurlijk voornamelijk om applicaties waarbij de data in de Cloud mag staan, dus niet bedrijfskritieke systemen met kritische data.
De high end zal vanzelf ontstaan als de generieke applicaties in de cloud staan.
@Henri
Ik ben blij dat ik in jouw ogen geen onzin schrijf en geef toe dat ik, om stuk leesbaar te houden en volgende keer wat te kunnen publiceren, niet volledig ben. Dank dus voor de aanvulling waar ik graag wat verder op in ga.
Het klopt dat Google de grootste databases heeft en dat deze niet traag zijn. Tenslotte geef ik in mijn stuk al aan dat je de datalaag ook kunt schalen. Maar dat vraagt wel enige en soms zelfs radicale aanpassingen van bestaande applicaties. Wegnemen van de legacy bijvoorbeeld die in veel RDBM’s oplossingen zit en ze afhankelijk maakt van de opslag. Google lost trouwens met F1 een aantal tekortkomingen van noSQL op. Maar zolang je nog te maken blijft hebben met legacy ontkom je echter niet aan migratie.
Verder geef je al aan dat er een strategie nodig is om te kunnen profiteren van Cloud Computing. Bijvoorbeeld de rationalisatie en standaardistatie van applicaties. Dit zijn echter toevallig net de 2 dingen die vergeten zijn bij server virtualisatie. Want de aanvliegroute naar de Cloud wordt inderdaad te traditioneel gedaan, voornamelijk vanuit een kostenoverweging. Ik schreef geloof tenslotte al iets over kostenomslag voor servers in plaats van services. En een lokkertje van €8 voor een server zegt ook nog niets over wat er uiteindelijk werkelijk onderaan de rekening komt te staan.
Betreffende beheer van applicaties in de Cloud had ik in augustus al eens iets geschreven waarover we van mening verschilden en ik wil je ook hier niet teleurstellen. De automatisering waar je het over hebt kan namelijk ook alleen maar als daar met de ontwikkeling van applicaties rekening meegehouden is. Wederom is dat in veel bestaande applicaties niet het geval en zullen ook hier aanpassingen nodig zijn. Bijvoorbeeld dat meldingen niet in de systeemlog geschreven worden, waar je afhankelijk van verantwoordelijkheden soms geen toegang toe hebt.
Oja, en dat alle moleculen in je lichaam Cloud gericht zijn is niet te zien aan je foto. Je lijkt tenminste niet op personage ‘Seven of Nine’ uit Star Trek.
@Willem
Je verwijt kan ik niet plaatsen ten opzichte van mijn artikel want hoewel ik niet ontken dat we net als andere bedrijven aanbestedingen verliezen en winnen staat deze opinie hier los van. Ook je argumenten vind ik weinig inhoudelijk en op bepaalde punten zelfs naief, bijvoorbeeld het idee dat er geen back-up meer nodig is als je redundantie in je schijven hebt.
Verder vind ik het prima als je Openstack wil promoten en ben benieuwd naar je artikel hierover waar verschillende oplossingen met elkaar vergeleken worden. Hoop dat je hierin dan ook uiteen wilt zetten hoe je tot een hybride oplossing komt.
Alhoewel ik wat allergisch begin te worden voor alle artikelen over de cloud vind ik dat dit artikel een goed punt aansnijdt. Als het om cloud gaat dan dan denk ik maar, resources on demand. Maar inderdaad het is leuk om te praten over de cloud maar dan moeten applicaties ook zo ontworpen zijn dat die schaalbaar zijn, kan de load ook inderdaad uitgesplitst worden op een of andere manier?
@ Ewout,
Duidelijk artikel de aandachtspunten op het gebied van bandbreedte/netwerk en opslag zijn zeer herkenbaar.
Voor de meeste punten zijn zoals je zelf al aangaf oplossing. Zoals IO-kaarten en wan-optimalisatie. Op software gebied valt in mijn ogen nog een grote slag te maken. Niet iedere applicatie kan al optimaal met de dynamiek van de cloud om gaan.
@ Willem,
Jboss is zeker een interessant concept. Ondanks de redundantie door middel van RAID ( op cluster / serverniveau ) is af te vangen, is het erg naief om te denken dat je helemaal geen back-up nodig meer hebt. Ik kan mij niet voorstellen dat je al je data (jaren,maanden,weken etc )online laat staan op je Jboss-omgeving. Een seperate back-up omgeving op basis van disk, tape of misschien wel cloud is onoverkomelijk.