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.
Een andere oplossing voor lagere vertraging is om je ijzer dichter bij je gebruikers te zetten.
Dat kan nog steeds door een cloudprovider beheerd worden als het nodig is.
New,new,new : QoS as a Service, wel cloud, geen internet.
Elk netwerk kent latency, een vertraging in de dataoverdracht die niet alleen door het netwerk zelf veroorzaakt wordt maar ook inherent is aan het gebruikte protocol. En laten we de eventueel achterliggende componenten ook niet vergeten. Een lage latency op het netwerk maar langzame response van de disks zal bijvoorbeeld tot dezelfde trage response leiden, het gaat dus meestal om de som der delen en dus niet één factor.
Idee van data en gebruiker uit elkaar trekken middels een hyride cloud oplossing is dan ook niet nieuw als ik kijk naar de argumentaties van SAN/NAS oplossingen. De vraag hier is wat het meest efficiënt is, goedkope (en generieke resources in de cloud met als gevolg daarvan hogere latency of duurdere resources on-premises met daardoor een betere response.
Parallellisatie is leuk maar als je uiteindelijk een trechter hebt waar nog alle data door heen moet dan kan het weleens moeilijk worden om alles consistent te houden. Niks nieuws onder de zon eigenlijk als ik kijk naar de wachtrijtheorie, ook wel de wiskunde van de ergernis genoemd omdat je altijd weer een nieuwe bottleneck krijgt als je er één opgelost hebt.
Oja, je kunt de latency meten maar het beheren is nog weleens lastig als je ketens langer worden en je afhankelijkheden hierin groter, het nadeel van Internet.
eeuh … ” Naast trace routes en het het aantal routerhops zijn er meer complicerende factoren”
Nooit geweten dat een traceroute een complicerende factor was.
(ps: om te voorkomen dat mensen traceroute uit gaan leggen: bovenstaande is cynisch bedoeld 🙂 )
@Ewout,
Cloud connectie over private dedicated line tbv betrouwbaarheid, prestatie en beveiliging is volgens mij wel degelijk nieuw. Dit aanbieden als service ook. Nou ja, retro misschien, als je kijkt naar Leased lines of X25/PVC in de begin jaren 90.
Ewout,
Ik sluit mij volledig bij je aan. Iedere verbinding hoe langzaam of snel dan ook, heeft te maken met latency.
In dit stuk wordt gesproken over de latency van netwerkverbindingen naar de Cloud. Echter heb je in de cloud op meerdere lagen van de Cloud infrastructuur te maken met latency.
Bij Cloud oplossingen zie ik het buiten de latency en een tekort aan bandbreedte het ook steeds vaker mis gaan op de latency naar de disken.
Om je onderstaand even een rekenvoorbeeld te geven:
Gemiddelde latency op disken:
SATA 15 MS
SAS 10k 7.2 MS
SAS 15k 3.5 MS
SSD < 0.1 MS Niet iedere cloud leverancier kan door middel van QoS de juiste performance en minimale latency bieden. En hoe kom je er achter op wat voor disktechnologie het draait? En wat de latency is? Dit ondervind je pas op het moment dat je er daadwerkelijk draait. En dan is het vaak al te laat. Dus wat slimme vragen aan je cloudleverancier stellen en garanties omtrent performance afspreken is ook hier geen overbodige luxe. Een infrastructuur cloud of non-cloud is een keten van logische lagen ( compute/network/storage ). Iedere laag dient zo optimaal mogelijk op elkaar afgestemd te worden. Het verbreden van " de pijp" of " resources" op maar 1 van de lagen lost op de langere termijn niet altijd iets op. Ik ben benieuwd wat Henri hier over gaat roepen.
Eén van de voordelen van cloud based oplossingen is dat je anyplace, anywhere kunt werken.
Op het moment dat je met private, dedicated verbindingen gaat werken naar je locatie toe om latency schommelingen de kop in te drukken vervalt dit hele voordeel toch?
(ik ga er nochtans van uit dat een bedrijf geen dedicated verbindingen naar alle thuiswerkplekken en veel voorkomende internetcafés gaat aanleggen )
Overigens ga ik geheel in de 2e reactie van Felix the cat mee dat dit wel heel erg retro is. In de jaren 90 gebruikten we inderdaad al dedicated verbindingen om responsetijden/performance te kunnen borgen op o.a. het “good old mainframe”
Ik vind Ewout zijn reactie wel erg sterk.
Latency kent vele gezichten. Als je een applicatie op een client hebt draaien en een database in een datacenter / cloud, dan zal Latency altijd een rol spelen.
Zelf ben ik de koning van de webservices. Webservices hebben een aantal zaken tegen als het aankomt op latency. Het is een extra verwerkingslaag en omdat ze ook nog eens in een onhandig taaltje praten JSON of SOAP/XML en dit ook weer op de client verwerkt moet worden is een hoge latency vaak iets wat vroeg of laat de kop op komst steken.
Gelukkig hebben we cache en in-memory en heb je niet heel veel met de latency van discs te maken, en daarnaast kun je steeds gemakkelijker meerder verwerkingen parallel laten lopen.
Ook heb je vaak een scheiding tussen de webserver en code van de webservice en dat deze niet op de server draait waarop de data staat. Veel hiervan kun je echter wel weer compenseren met scale-out.
Mijn 0,02 euro.
King Henri,
Is dat wel zo wat je stelt? Cache en in memory is altijd beperkt qua omvang. Niet altijd redundant en vaak ook beperkt schaalbaar. En bij de echte enterprise omgevingen dus vaak niet toereikend.
Dus ik ben erg benieuwd wat je precies bedoelt. Misschien begrijp ik je wel niet goed.
King Henri Mc Cloud,
Is dat wel zo wat je stelt? Cache en in memory is altijd beperkt qua omvang. Niet altijd redundant en vaak ook beperkt schaalbaar. En bij de echte enterprise omgevingen dus vaak niet toereikend.
Dus ik ben erg benieuwd wat je precies bedoelt. Misschien begrijp ik je wel niet goed. Een vergelijk op alleen webservices is in mijn optiek iets te kort door de bocht. Of bedoel je hier mee dat de cloud alleen maar geschikt is voor webservices? 😉