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.
Latency is een container begrip met vele gezichten en daarmee ook minstens zovele oorzaken en oplossingen.
Een paar voorbeelden.
Een voorbeeld van latency is netwerk latency. Op korte(re) afstanden is dat op te lossen met hogere transmissiesnelheden. Maar op langere afstanden zal je gebruik moeten maken van ander middelen zoals bijvoorbeeld WAN optimizers.
De latency van “het internet” is weer een heel ander vraagstuk met heel andere oplossingen. Een CDN kan hier in specifieke gevallen goede diensten bewijzen. In veel gevallen zit er niet veel anders op dan gebruik te maken van bijvoorbeeld een MPLS netwerk.
Latency van disken is weer een heel ander vraagstuk. En zelfs al heb je de grootste en snelste SSD met de allersnelste CPU en hele sloten flitsend RAM-geheugen, dan is daar nog altijd de software. Een bekende uitspraak in deze context: al is een kompjoeter nog zo snel, Microsoft achterhaalt hem wel…
🙂
@Will
Latency is geen container begrip maar gewoon een keihard gegeven, hoe langer je verbinding hoe hoger je latency. Vergelijk het met licht welke wel snel reist maar uiteindelijk toch de afstand moet overbruggen. Toevoeging van CDN lost volgens mij niet het latency probleem op hoewel je hiermee de content dus wel dichterbij de gebruiker kunt brengen en daarmee de ‘reisafstand’ verkleind. QoS op Internet lijkt me echter onmogelijk door netneutraliteit, het baas boven baas principe gaat echter wel meer een rol spelen op de Internet backbones.
Vrij vertaald betekent latency gewoon wachttijd en deze zit inderdaad niet alleen in het netwerk. Response is dan ook de optelsom van alle wacht- en verwerkingstijd waarbij niet alleen besturingssysteem (en applicatie) een rol spelen maar ook alle overhead die er is toegevoegd. Het gaat namelijk niet zo zeer om de software, het netwerk of schijven maar de gebruiker die steeds meer snelheid verwacht maar zelf niet mee groeit. En die gebruiker wil ook nog weleens een systeem gebruiken waarvoor deze niet bedoeld is.
Kan me case herinneren waar online systeem volgens alle berekeningen meer dan toereikend moest zijn maar het plots niet was. Bleek na onderzoek dat slimmeriken de batch online verwerkten omdat dit goedkoper was, vanuit hun perspectief dan want het leidde dus tot vertragingen en uitbreidingen. Als ik me niet vergis gebruiken de providers om deze reden technieken als DPI, optimalisatie kun je ook alleen maar doen als je weet wat er over het netwerk gaat.
@Ewout
Als iets een container begrip is wil niet zeggen dat het *geen* keihard gegeven is (en v.v.) – in mijn optiek zijn die twee niet “mutual exclusive”. Maar inderdaad – de term latency wordt het meest gebruikt bij netwerk verbindingen.
Misschien een wat (te?) academisch betoog – maar toch:
Heel strikt genomen zijn latency problemen *niet* op te lossen – anders dan door het verhogen van de transmissiesnelheid. Wat vandaag de dag (in de praktijk) alleen maar kan op korte afstanden tot enkele kilometers. Alle andere “oplossingen” zijn feitelijk workarounds.
De huidige wetten van de fysica staan het nu eenmaal niet toe dat er nog meer elektronen in beweging worden gebracht tijdens een datatransport. Wat maakt dat zelfs lichtsnelheid vandaag de dag zijn beperkingen kent door de compromissen die gesloten moeten worden bij de ontwikkeling en bouw van actieve componenten zoals bijvoorbeeld de chipsets van servers, van disken, van netwerk apparatuur, etc…
Weinig toe te voegen aan het degelijke artikel en de vele goede aanvullingen behalve de constatering dat ik bij ‘de hele groten’ (in mijn geval met name Google en Microsoft) eigenlijk vrijwel nooit latencyproblemen ondervind. Ook gratis producten als gmail dat ik al een jaar of 10 pruttelt eigenlijk altijd voldoende snel door.
Voor alle duidelijkheid: hiermee wil ik de uitdaging niet bagatelliseren maar constateer ik dat een goede service (terecht punt van Henry) blijkbaar voldoende uit de voeten kan met doorsnee voorzieningen aan de gebruikerkant om latency geen probleem te laten vormen.
Als ik het artikel lees en de reacties dan wilde ik eigenlijk niet reageren, maar alsnog.
De schrijver van het artikel heeft het over de latency als de cloud-omgeving wordt benaderd via internetverbindingen. Hij suggereert dat het beter is om daar dedicated verbindingen van te maken, zodat de weg tussen de devices en de systemen in de cloud geen of weinig hinder ondervinden van de zogenaamde golfslag op Internet. Wederzijdse beïnvloeding van devices die dezelfde verbinding gebruiken blijft van toepassing.
Latency is er in vele verschijningsvormen, die hierboven allemaal zijn besproken. In de cloud modellen kan je latency projecteren en maatregelen treffen om de latency zo weinig mogelijk de gebruikersbeleving te beïnvloeden. De schrijver van het artikel legt de vinger wat dat betreft op de juiste plaats, de verbinding tussen de devices en de cloud omgeving heeft in de meeste gevallen de grootste invloed op de beleving van de gebruiker. Als de gebruiker gebruik maakt van webbased service, zoals Google en Office 365 of Salesforce zal de hinder van internet latency niet of nauwelijks een rol spelen, dan spelen de verbindingen tussen de componenten in de cloud een grotere rol.
@henri: Ik zou toch nog eens naar de VMware Vloud oplossing kijken die VMare nu ook zelf in de markt zet: http://blogs.vmware.com/vcloud/2014/08/vcloud-hybrid-service-35-cheaper-azure-83-cheaper-aws.html?utm_source=rss&utm_medium=rss&utm_campaign=vcloud-hybrid-service-35-cheaper-azure-83-cheaper-aws Volgens mij een eyeopener.
Willem, vCloud is een ander product dan AWS en heel anders dan Microsoft Azure. Dit artikel is enorm biased (logisch, het staat bij VMWare op de site) en daarnaast haalt dingen uit de vergelijking, bijvoorbeeld dat je 40% korting krijgt als je instances “inkoopt”.
Nu zeg ik niet dat vCloud niet goed is, maar als ik vandaag met vCloud aan de slag wil, dan kan dat niet en moet ik eerst een procedure volgen en contactopnemen met een sales persoon. Het proces is me dan ook niet duidelijk wat de extra kosten zijn of er een minimale afname verplichting is, et cetera.
Henri,
Op zich heb je ( nu nog ) valide punten.
Vergeet alleen niet dat een mogelijke migratie naar VCloud voor velen erg makkelijk is. Technologie zoals VMotion/HA etc. etc. worden allemaal gesupporteerd wat een hoop migratie en implementatie ellende scheelt.
En ja, het is nog niet zo on-demand beschikbaar als AWS. Maar ook daar wordt aan gewerkt. En een paar jaar achterstand haal je niet in een paar maanden in.
Maar al met al is het in mijn ogen een zeer veelbelovend iniatief. Een beetje concurrentie kan geen kwaad.
Ik heb op youtube het product bekeken en ziet er inderdaad bruikbaar uit als je als bedrijf op een traditionele manier met servers om gaat. Het is daarmee ook een niet zo grote overstap om vanuit een huidige situatie naar de vCloud te gaan.
Maar als we het hebben over profiteren van cloud computing is dit niet het product waarmee je het verschil maakt. Het zijn juist de PaaS achtige aanvullingen van bijvoorbeeld AWS die de dienst zo waardevol maken. Hiermee doel ik op bijvoorbeeld : SES, SQS, SNS, Route 53, OpsWorks, Elastic Beanstalk, et cetera.
Servers virtualiseren en basic IaaS kun je bij elke hosting partij.
Henri,
Ik heb wat meer dan een alleen een youtube filmpje gezien,gelezen en gehoord. En neem maar van mij aan dat ze leuk bezig zijn.
In mijn optiek verkleinen ze juist het gat wat er nu ligt. Een migratie van traditioneel naar een 1e vorm van cloud is zeer gemakkelijk bij deze propositie te noemen. En het PAAS aanbod van VMware is nog druk in ontwikkeling. Ze kunnen natuurlijk niet in een paar maanden de opgelopen achterstand direct inhalen.