Bij applicaties die in een private of publieke cloud-omgeving draaien, zijn er allerlei factoren die van invloed zijn op de latency en dus op de prestaties van een applicatie. Naast trace routes en het het aantal routerhops zijn er meer complicerende factoren.
Met veel van deze factoren wordt nog dikwijls onvoldoende rekening gehouden. In de cloud is een lage latency echter belangrijker dan ooit tevoren voor de ervaring van eindgebruikers. Zeker als tijd een kritische factor is zoals dat bij het digitale handelsverkeer, 3D-modelleringstechnieken en digitale media-diensten het geval is.
Bij applicaties die in de cloud draaien, is het berekenen van de latency om meerdere redenen niet eenvoudig. Zo liggen allereerst de eindpunten niet vast. De gebruikers van applicaties in de cloud kunnen zich overal ter wereld bevinden. Daar komt bij dat sommige gebruikers op een glasvezelnetwerk zitten, terwijl anderen een mobiele 3G-verbinding gebruiken. Ook de manier waarop de infrastructuur van de cloud is ingericht, de locatie van specifieke onderdelen van netwerken, applicaties, servers en opslag en de wijze waarop de verschillende delen met elkaar zijn verbonden, spelen een rol.
IT-dienstverleners en system Integrators die een dienstverlening met een hoge kwaliteit willen bieden aan hun klanten, zullen een vaste lage latency moeten kunnen garanderen. Dit impliceert dat zij de latency moeten kunnen meten en beheren.
Consistente netwerkverbindingen
Behalve een beperkte latency zorgt het onvoorspelbare karakter van de netwerkverbinding tussen it-infrastructuur die lokaal staat en de cloud-aanbieder voor problemen; netwerkverbindingen die via het openbare internet lopen, kunnen tot latency-schommelingen leiden. Het tot stand brengen van een private, dedicated verbinding tussen it-infrastructuur op locatie en it-infrastructuur in de cloud biedt uitkomst. Zo bieden onder andere Amazon Web Services en Microsoft Azure klanten de mogelijkheid om dit soort private verbindingen te realiseren via respectievelijk Amazon Web Services Direct Connect en Expressroute.
Omdat dit soort verbindingen niet via het openbare internet lopen, zorgen ze naast een lagere latency ook voor een grotere betrouwbaarheid, hogere snelheden en een betere beveiliging. Het stelt klanten in staat hoogwaardige hybride it-oplossingen te realiseren, waarbij zowel gebruik wordt gemaakt van systeembronnen op locatie als van capaciteit in de cloud. De applicatiecode en -data kunnen bijvoorbeeld worden opgeslagen op locatie, terwijl de systeemcomponenten die een beroep doen op de functies en betaalmodellen van cloud-computing worden overgeheveld naar de cloud.
Onvoorspelbaarheid
Wie vertrouwt op het internet voor de verbinding met een applicatie in de cloud krijgt te maken met veranderlijkheid en onzekerheid op het gebied van bandbreedte, snelheid en latency. Logischerwijs vinden steeds meer bedrijven dit soort onzekerheden onacceptabel, temeer omdat het eenvoudig kan worden voorkomen. It-dienstverleners, aanbieders van clouddiensten en connectivity providers zullen daarom steeds meer een complete, geïntegreerde service moeten aanbieden, waarbij ze mede door het realiseren van particuliere verbindingen vaste niveaus van bandbreedte, snelheid en latency kunnen garanderen. Want eerder dan het niveau van latency, zorgt het veranderlijke en onvoorspelbare karakter van latency voor problemen.
Ruud, et al,
Natuurlijk is cloud computing meer dan webservices en mijn reactie was niet per se gericht op enterprise. Juist door een *goede* architectuur op te zetten gericht op scale-out kun je in mijn ogen performance problemen of latency problemen op lossen.
Als ik over cloud diensten praat bedoel ik met name Amazon Webservices en Microsoft Azure. En niet de hosting partijen of partijen die VPS aan kunnen bieden, maar beperkt zijn in repertoire.
Als ik tegen peformance of latency problemen aanloop is dat veel vaker slechte architectuur of slechte code, dan dat ik tegen beperkende bandbreedte aanloop of netwerk congestion. Disclaimer : Als ik deze problemen tegenkom heb ik externe kennis nodig om het op te lossen.
Mijn punt is dat ik weinig problemen ervaar van of door de cloud computing providers en dat was twee jaar geleden wel anders. En zeer veel van de gevallen ligt de schuld aan mijn kant. Ik laat zoveel mogelijk “controls” inbouwen om performance te meten en laat op veel kenmerken alerts zetten. Natuurlijk zijn er wel eens bad neighbors (VM’s met tegenvallende performance omdat iemand anders op het ijzer loopt te hameren), maar de meeste problemen met latency en performance veroorzaken we toch vaak zelf. En lossen we op.
Henri,
Ik had het al door dat je niet op enterprise doelde toen je over caching en inbound memory begon. Dat is zeer leuke technologie maar meestal wordt dat ingezet om andere bottlenecks in je infrastructuur te ontlasten/verbloemen. En in mijn optiek is veel van die technologie nog niet enterprise waardig en vaak alleen maar toepasbaar in de webservices hoek.
Storage caching kan er juist er voor zorgen dat bij het vol lopen er van , er nog grotere uitdagingen ontstaan omdat er dan meestal terug wordt gevallen op 15k,10k of zelfs nog erger SATA disken. Met alle latency gevolgen vandien. Caching is een leuke tijdelijke opvangbak.
We hebben het in het verleden al eens vaker over IO garanties en latency gehad. Maar hoe is dit nu bijvoorbeeld bij een Azure of AWS in te regelen?
Inmiddels weet ik van je dat ze meerdere raid-sets onderwater aan elkaar vast knopen om slim en flexibel met IO belasting om te gaan. Maar kan je een keiharde onder- of bovengrens afspreken? En is dit extern goed te monitoren?
@Henri Dat laatste, dat lossen we op, dat hoop je natuurlijk en je doet je best. Maar ik ben het wel met je eens, als er problemen zijn met een toepassing (dat zal dan vast geen SaaS zijn….) dat kun er eigenlijk donder op zeggen dat het aan jouw kant ligt. Virtualisatie is weer een extra factor, even een goede architectuur, even je applicaties ontwerpen op scale out, triviaal zal het vast niet zijn. Virtualisatie/cloud brengt weer zijn eigen categorie van mogelijk problemen mee. Bad neighbours dat lijkt een horrorverhaal maar lijkt me ook een reeel probleem, ik neem aan dat er vast tools en technieken bestaan om dat te herkennen. Maar dat weet ik niet.
@ Louis,
Bad neighbours blijven altijd lastig. Wil je hier geen last van hebben dat plaats je schuttingen, creeer je je eigen tuinpad/steeg, en laat je isolering plaatsen. Dit alles kost natuurlijk allemaal extra. En dit zijn vaak de verborgen kosten die men niet altijd vooraf inzichtelijk heeft.
Vaak wordt er op AWS een servertje in elkaar geklikt door iemand in de organisatie. Die gaat dan met deze initieel lage prijs naar IT toe en roept waarom kunnen wij het niet zo goedkoop? IT gaat dan in discussie en legt het dan vaak af en laat die gebruiker zijn servertje maar bestellen. Uiteindelijk krijgt de gebruiker een soort van Ryan Air / Easy jet ervaring. Hij heeft bijna geen beenruimte ( lees performance ), zijn buurman/vrouw zit erg breed en daar door zit hij erg belabberd, en hij moet voor alle zaken eten/drinken betalen en de service is vaak belabberd en neemt veel tijd in beslag. Uiteindelijk is zijn vlucht naar de Cloud toe dus alles behalve comfortabel en leuk geweest.
De 2e keer brengt hij samen met IT al zijn behoeftes vooraf in kaart kiest voor Signapore Airlines en heeft een top ervaring en geen verborgen kosten. Moraal van dit verhaal is bepaal eerst wat je nodig hebt. Zet deze behoeftes in een consumentenbond overzichtje en kies dan de juiste smaak/aanbieder er bij. De ene keer ga je voor prijs en de andere keer voor kwaliteit.
Ik ga hier niet te diep op in – het is weekend – maar ik wil wat nuance aanbrengen voordat je het later weer tegen me gebruikt: Cloud computing is prima geschikt voor de enterprise. Er is *niet één* uitdaging waarvan ik zeg; “Dit kan niet zonder cloud computing”.
Latency problemen met AWS zijn zeer zelden de fout of het gebrek van Amazon. Als je kijkt naar gegarandeerde IOPS, dan zeg ik Google is your friend. Als je kijkt hoe Amazon als een malle iteratief zijn dienst verbetert dan zie je een patroon. Er wordt geklaagd over een gebrek -bijvoorbeeld te weinig invloed op IOPS- er komt een oplossing. Een heerlijk stuk om te lezen is deze link : http://steverant.pen.io/, in November geef ik nog een seminar over webservices en zodoende heb ik deze post weer doorgelezen.
Azure is overigens een stuk abstracter dan AWS, de middelen om IOPS te lijf te gaan zijn verborgen achter lagen. Maar uiteindelijk geeft niemand een steek om IOPS als je performance en responsiveness gewoon goed is. Overigens werkt het gehele filesysteem heel anders bij cloud computing aangezien je data zich nooit op één raidset bevindt.
Ook is je vergelijking met Ryan Air een verkooptruuc die je vast wel eens toepast. Ja, in de basis is AWS ook een prijsvechter, maar het is ook nog eens de meest geavanceerde (enterprise) cloud computing provider op deze planeet die de vergelijking met Singapore Airlines
ver overstijgt.
Ook je moraal vind ik niet zo sterk. Zoals jij ook weet, weet een klant niet altijd vooraf zijn behoefte en even een server bij elkaar klikken is dan een mooie eerste stap, als het dan in productie moet kan dit geregeld worden, is het niets, dan sleep je hem naar de prullenbak. Performance behoefte bij nieuwe dingen zijn sowieso vaak onbekend, je kunt niet altijd inschatten wat een klant nodig heeft, en om daarvoor hele dure trajecten te starten vind ik in veel gevallen de ongewenste (traditionele) route.
Spijtig genoeg blinkt de auteur weer door afwezigheid. Wederom een gemiste kans, zeker gezien de zeer vruchtbare en zinvolle discussie, waar zelfs Ewout en Henri het bijna met elkaar eens lijken te zijn 🙂
interessant leesvoer heren.
@Ruud je schrijft iets over niet geschikt voor de enterprise in relatie tot o.a. caching. Hoe zie jij dan initiatieven van bv SAP voor in memory databases? In memory databases zie ik dan voor het gemak maar even als een hele grote cache.
SAP is volgens mij toch wel gericht op de enterprise.
Verder lees ik op de diverse techblogs van grote cloud apps (sommigen zijn best open over hun techniek) hele mooie verhalen waarbij ze bv met sharding zorgen dat de performance gewoon goed blijft en ze toch voordelen houden van schaalbaarheid in de cloud. De aantallen gebruikers die ze daarbij servicen zijn zonder meer te vergelijken met enterprise omgevingen volgens mij, latency is belangrijk omdat anders hun gebruikers gillend weglopen.
Hoe zie jij dat soort technieken?
Hebben jullie nog tips over leesvoer of cursussen over dit soort architecturen? Hoe meer ik er over lees hoe interessanter ik het ga vinden.
@PaVaKe:
Het oordeel over de auteur vindt ik (voor nu) wat kort door de bocht.
Het artikel is op vrijdagmiddag rond half 3 geplaatst.
Op het moment van schrijven is het zaterdagmiddag rond enen en dus weekend => niet iedereen is een “workaholic”… 😉
Laat staan zin en tijd hebben om in het weekend inhoudelijk te reageren als het buiten +25 graden is.
Henri,
Ik ben het best wel met je eens dat er veel in de cloud kan. Alleen vergen bepaalde zaken wel meer aandacht maar dat is bij een non-cloud infrastructuur natuurlijk ook het geval.
Als je om performance en responsiveness geeft, dan geef je misschien zonder dat je het door hebt ook om IOPS en latency. Dat kan natuurlijk niet los van elkaar gezien worden. Dank trouwens voor je link ik zal dit zeker eens doornemen. En dat er een oplossing komt is mooi en ook zeer nuttig. Het bevestigt wel mijn opmerking dat het er nu in veel gevallen nog niet is. En aan roadmap selling doe ik persoonlijk gezien niet. Eerst zien dan pas geloven is mijn motto.
Af en toe krijg ik wel het idee dat je continu AWS blijft verdedigen. Het lijkt soms net of je er werkt. Bijvoorbeeld over de propositie van VMWare hoor ik je nooit. En ook zij doen zeer leuke dingen. Ik roep ook niets wat niet waar is. AWS is nu eenmaal een prijsvechter net zoals velen andere cloudproviders in de markt. En ja ze houden hun instap laag om mensen over de streep te trekken. Om nu direct te roepen dat dit een verkooptruc van mij is, vind ik iets te kort door de bocht van je. Ik vind dit behoorlijk gekleurd en dit bevestigt wel heel erg je voorkeur. Ik roep nergens dat ze niet goed zijn. De cloud en ook AWS heeft nu eenmaal wel wat verborgen kosten die niet voor iedereen even inzichtelijk te maken zijn.
En ja een server in elkaar klikken voor test doeleinden is zeker geen verkeerde stap. Het is zeker een goede 1e kennismaking en leuke test. Maar daar stopt het ook wel bij. Maar voor een productie omgeving gaat dit natuurlijk totaal niet op. Als daar vooraf je performance behoeftes onbekend zijn, is het even in elkaar klikken van een server niet the way to go.Tenminste niet in mijn optiek.
In mijn ogen is dit in enterprise omgevingen juist dodelijk. Probeer dan op zijn minst tijdens een POC of in de testfase de requirements duidelijk te krijgen. En gebruik waarbij nodig best practices en ervaringen uit het verleden. Een beetje intergrator/dienstverlener heeft het trucje namelijk al vaker gedaan. Zo niet dan moet je jezelf even goed afvragen of je met hem of haar wel in zee wilt gaan.
En ja kennis en ondersteuning kost nu eenmaal geld. Om dit gelijk duur te noemen is natuurlijk weer iets te kort door te bocht van je. Dit is net zo zeer een verkooptruc om te roepen als mijn opmerking over Ryan Air. En ik neem aan dat jou advies en ondersteuning ook niet gratis is.
Maar je hebt natuurlijk met je 1e regel helemaal gelijk. Het is weekend en mooi weer. Dan moeten we op het terras zitten ipv over wolken en performance te spreken 😉
Prachtig deze discussie.
Een dag of wat geleden hab ik de gehele ICT weer uitgeschakeld, zwaar onweer. Dus een uur of wat ook weer eens wat anders doen.
Een van de klanten was niet thuis, dat betekende exit voor zijn server en 2 dagen geen produktief werk.
Dan is een latency in de cloud ineens niet zo belangrijk, maar de geruststelling dat jouw boeltje veilig in een datacenter staat.
Ja Henri, waarvoor de klimaatverandering al niet goed is!