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.
Stabiele en snelle verbindingen, snelle schijven en dan ook nog maar hopen dat er niet teveel virtuele servers op een machine zijn gepropt.
@ Louis,
Je haalt een zeer valide punt aan. Performance garanties in de cloud van de gehele IT keten zijn vaak lastig inzichtelijk te krijgen en te garanderen.
Een keiharde IO garantie op bijvoorbeeld je opslaglaag wordt niet door iedereen gegeven. En ik praat hier niet over de lokale disken van een webserver. Maar over de storagelaag waar je DB of CRM pakket voor een Enterprise omgeving in de Cloud opdraait.
Dit gebeurt vaak op multi-tenant omgevingen. Bandbreedte wordt vaak gedeelt , net als de serverlaag, back-up faciliteiten en de storagelaag. En op al die lagen kan latency/vertraging plaats vinden.
@Ruud Heb dit zelf al een keer ervaren waarbij van een hard op het ijzer oplossing naar een gevirtualiseerde oplossing overgegaan werd dat je een wiebelende performance kado kreeg. En heb het ook van anderen gehoord dat het nog lastig kan zijn om na te gaan waar de performance bottlenecks zitten als van alles (netwerk, opslag, geheugen, rekenkracht) gevirtualiseerd is en met elkaar gedeeld wordt. Een extra complicerende factor en vond het toen niet prettig, dat gewiebel.
@Louis: herkenbaar scenario wat je schetst.
Maar … betekent dit ook dat virtualisatie wel eens een bottleneck zou kunnen gaan vormen indien men performancegaranties uit de cloud wil?
En … als virtualisatie de performance in de weg staat, en we terug moeten naar dedicated hardware, cloudoplossingen ineens niet meer zo voordelig worden?
Pa Va Ke,
Nee dat is absoluut niet het geval. Met virtualisatie is ook QoS mogelijk en kan een keiharde onder- en bovengrens op het gebied van resources (CPU, Memory ) ingeregeld worden.
@PaVaKe Dat is een vraag die ik mezelf ook al stelde, zijn er performancegaranties mogelijk? @Ruud Als het mogelijk is die garanties te geven dan zal dat vast ook gevolgen hebben in welke mate je die resources kan uitdelen. Kan me voorstellen dat je daar ook beperkt in bent en zou ik verwachten dat er van uitbundig overcommitten geen sprake kan zijn.
Een aantal aardige reacties die richting mijn eerste vraag komen wat je nu precies op wilt lossen. Want een lage latency op het netwerk door gebruik te maken van dedicated lijnen heeft volgens mij weinig nut als je uiteindelijk weer gedeelde computing resources hebt. En heb je beide dedicated dan komt dus de vraag naar voren waarom je eigenlijk voor cloud computing kiest.
Natuurlijk draait alles om de workload, hiermee bedoel ik niet de belasting van resources maar het (bedrijfs)proces als geheel. Binnen de wachtrijtheorie heeft het namelijk weinig nut om een backlog te hebben aan voorhanden werk. Latency hoeft niet een probleem te zijn als de achterliggende stap langzamer is. De uitdaging van parallellisatie ligt dan ook in de afstemming van het geheel en dus niet zo zeer in het netwerk zelf.
Ik lees in reacties en opinie over QoS maar vraag is waarop wordt die nu precies ingericht wordt?
We weten vaak niet meer welke resources belast worden en in welke mate met een fijnmazig granulariteit van bijvoorbeeld één transactie. Ik kan vaak wel de response hiervan meten maar meestal ontbreekt de impact analyse op de techniek doordat ik te maken heb met vele ‘eilanden’ in de stack die ieder hun eigen waarheden hanteren. Latency van het netwerk is tenslotte even nietszeggend als die van de disks als ik niet weet wat ik nu precies wil bereiken.
Ik noemde in eerste reactie ook al de protocollen welke even goed hun impact kunnen hebben want kijkend naar wat netwerk analyses zie ik nog weleens dat elke transactie opnieuw een connectie opzet wat ook voor de nodige vertragingen kan zorgen, met name bij webservices om nog even een koninkrijk aan te vallen.
De duivel zit altijd in de details en dit dus geldt met name als je pas achteraf nadenkt over je keuzen.
Ewout,
Je ligt de vinger precies op de zere plek. QoS is leuk maar je moet wel heel goed weten waar je het toe gaat passen. QoS op maar 1 laag van de gehele keten lost in mijn optiek weinig tot niets op.
En ja, nog te weinig organisaties weten wat hun infrastructuur ( cloud/ non-cloud ) doet qua resources. En hier moet verder dan alleen het “ijzer” gekeken worden. Ook de programmatuur kan onnodige vertraging veroorzaken.
@ Louis,
Ja in zekere maten zijn er op bepaalde lagen van de keten wel garanties af te spreken. Meestal vinden de cloud-leveranciers dat een stuk minder leuk omdat hun terugverdienmodel juist vaak gebasseerd is op overcommitten en thin provisioning.
Al is QoS voor een Cloudleverancier ook niet altijd even aantrekkelijk. Om de afgesproken resources te kunnen bieden moeten die of keihard gealloceerd worden of op afroep beschikbaar zijn. Dit zorgt voor een hoger kostenplaatje voor de leverancier die dit natuurlijk naar de eindklant zal door berekenen. Want als de leverancier dit soort afspraken met een enterprise organisatie maakt, dan moet hier ook echt aan voldaan worden. Meestal worden er prestatieverplichtingen met de daar bijhorende boetes afgesproken. Dit zijn vaak de verborgen kosten van de cloud die men initieel niet izichtelijk heeft.
@Ruud De programmatuur telt zeker mee, waar zet je welke onderdelen neer, bv staat je DB om de hoek of in een uithoek met heel veel DB’s bij elkaar, dat ook tegengekomen. @Ewout De devil is in de details en ook als je vooraf goed nadenkt moet je misschien achteraf ook nog wel vaststellen dat het net even anders moet. Dat heet nou geloof ik agile. Op de fiets, die werkt.