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.
@Wil … als je kijkt naar het profiel van de auteur kun je zien dat hij alleen artikelen post, maar nooit reageert. Vandaar ook mijn opmerking, anders had ik me zeker kunnen vinden in je reactie hoor 🙂
Ruud,
Ik zal proberen bondig te zijn.
VMWare richt zich voornamelijk op server virtualisatie. De kern van cloud computing is niet IAAS en (virtuele) servers inzetten. Daarmee mis je de essentie van cloud computing. VMWare is in mijn ogen helemaal niet gericht op start-ups en zelf bediening. Ze willen gewoon de grote klanten en zaken doen zoals ze dat altijd gedaan hebben. Een model waar ik me tegen afzet en waarin in *niet* geloof. Ik kan ook geen account aanmaken bij VMWare en dan mijn cloud gaan opzetten. Nee, er komt eerst menselijk handelen aan te pas en daarmee mist het de leverage van AWS.
Ja ik praat vooral AWS en krijg daar niets voor. Dat komt omdat zij in mijn ogen de definitie zijn van cloud computing. Puurder dan dat is het niet te krijgen. Dus dan is het logisch dat ik als gelover in cloud computing vooral teruggrijp naar tastbare mogelijkheden.
Wat goede implementatie technieken zijn voor de enterprise, dat is heel verschillend per geval. Bedrijfskritische systemen vergen wellicht een andere aanpak dan het inzetten voor wat software voor HRM of CRM.
Hier zijn de laatste woorden natuurlijk niet over gezegd en neem ook echt wel jouw punten in overweging. Zo houden we elkaar scherp 🙂
Dank voor je reactie.
Je hebt gelijk over VMware. Maar let maar op mijn woorden dat daar wel wat verandering in gaat komen.
Ik ben ook totaal niet anti AWS. Alleen ik zie het geregeld gebeuren dat het niet altijd goedkoper en beter is dan de old fashioned way. Zeker als je het een beetje enterprise waardig wil maken gaat de teller aardig lopen.
Zoals ik al vaker hier heb geroepen kan het opstellen van een consumentenbond overzicht een hoop onduidelijkheid duidelijk maken.
Ondanks ik mij in deze reactie al wat beter kan vinden, ben ik het niet eens met je opmerking over HRM en CRM software. Juist dat laatste is vaak bedrijfskritischer dan je denkt.
En ja we zullen hier nog wel vaker over in discussie gaan. Maar dat is ook helemaal niet erg. Hier leer ik zelf ook altijd erg veel van.
@Henri
Wel of niet cloud is een vraag die je pas kunt stellen als je weet wat je wilt bereiken, je gaat voorbij aan het feit dat dedicated verbindingen en dedicated resources nog maar weinig verschillen met on-premises oplossingen.
Stellen dat je allerlei ‘zekerheden’ in moet bouwen in de code om enige garantie omtrent de prestatie te kunnen hebben lijkt me ook een omgekeerde argumentatie. Want zoals al vaker naar voren is gekomen zal inderdaad je code niet alleen bij het platform moeten passen maar het geheel ook passend moeten zijn bij wat je nu precies wilt bereiken.
Je disclaimer zegt dat je hier pas aan gaat denken als het incidenten regent en reactief beheer is vaak de weg naar maatwerk en hogere kosten zoals jij ook weet. In de race naar abstractie worden IOPS, latency en alle andere technische dingen vergeten die rechtstreeks verbonden zijn aan het ijzer. Je zegt zelf dat je externe kennis nodig hebt om dat op te lossen waarbij ik me afvraag hoe onafhankelijk deze is als het geleverd wordt door de leverancier van het ijzer.
Ach de snelheid van PC naar server is zo snel als de traagste schakel toe staat en laten veel van die schakels nu vaak buiten het bereik van de cloudleveranciers liggen. Maar daar hebben we in het verleden al lang iets op bedacht.
Pilot
Scheelt een hele hoop gezeur moet je maar denken.
Mischien dat ik er naast zit,
Maar ik heb de indruk dat wat Michel bedoeld, weinig te maken heeft met latency, maar met gebruikers ervaring.
@ Benno,
Met betrekking tot SAP (HANA )heb je helemaal gelijk. Als er gebruik van dat soort technologie gebruikt wordt gemaakt moet het redundant zijn.
Ik doelde meer op caching op de storagelaag. Daar is de technologie vaak nog niet even enterprise-waardig.
En ja er zijn absoluut cloud-leveranciers die het technisch gezien goed afvangen. Maar het wordt nog te vaak vergeten om mee te nemen in een prijsvergelijk. Het hebben van dedicated performance en bandbreedte haalt wel een beetje de kracht van de cloud weg ophet gebied van kosten en flexibiliteit
Het issue beschreven door Michael komt neer op het gebrek aan controle op de geboden kwaliteit van de zogenaamde “middle mile” i.e. het world wide web tussen de cloud infrastructuur en de eindgebruikers. Deze middle mile bestaat uit meer dan 22.000 verschillende ISP netwerken dus controle hierop krijgen is geen eenvoudige zaak.
Het inzetten van vaste lijnen tussen de cloud aanbieder en de eigen IT infrastructuur is een oplossing die beperkingen heeft vwb met name schaalbaarheid. Het zal ook niet de afhankelijkheid van het internet wegnemen. Eindgebruikers zullen immers nog steeds de applicaties benaderen via het internet.
Een oplossing voor controle binnen het internet zelf is het inzetten van een platform dat zorgt voor QoS in het internet zelf. Je hebt de garantie nodig dat je content 100% van de tijd de eindgebruikers zal bereiken en je moet de zekerheid hebben dat je eindgebruikers te allen tijde de optimale route over het internet van en naar je applicaties gebruiken.
Daarnaast is het belangrijk dat de content zich buiten de eigen infrastructuur aanpast aan de groeiende diversiteit aan devices en de type verbindingen van eindgebruikers. Beschikbaarheid is een belangrijke factor voor het bereiken van een optimale gebruikerservaring. Daarom dien je ook maatregelen te nemen om je applicaties vanuit het internet zelf te beschermen tegen het groeiende aantal cyberaanvallen.
De juiste CDN technologie kan het bovenstaande realiseren.
De ervaring van je eindgebruikers kun je redelijk eenvoudig meten door het inzetten van agents (zoals Gomez en Keynote) en Real User Monitoring (RUM).
@ Pascal,
Correct. Alleen heeft latency een grote invloed op de gebruikerservaring.
Vaak is dit af te vangen door dedicated resources zoals bandbreedte te gebruiken.
Alleen haalt dit natuurlijk wel een beetje de kracht en flexibiliteit van de Cloud weg.
Cloud-architectuur kent verschillende lagen en componenten. We hebben niet alleen bij elke component en laag maar ook tussen elke schakel genoeg legacy punten. Dit artikel bespreekt misschien een aantal zaken maar zeker niet alles.
Het probleem (o.a. rondom verbinding en legacy) dat in dit artikel besproken is heeft eerder aandacht gekregen binnen Fog Computing concept. Of dit concept de oplossing is, nee dat denk ik niet. Dat komt doordat cloud nog in de ontwikkelingsfase is. Bijvoorbeeld we zien dat een aantal bedrijven van start zijn gegaan met het schrijven en herschrijven van applicaties die geschikt zijn voor cloud-concept. Deze ontwikkeling zien we ook bij een aantal (nieuwe)leveranciers die hun product cloud ready maken.
In de komende jaren zullen deze ontwikkelingen bijeenkomen waardoor cloudleveranciers kunnen waarmaken wat ze nu al beweren!