Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Zin en onzin over latency in de cloud

 

Computable Expert

Michael van den Assem
Algemeen Directeur Interxion, Interxion. Expert van Computable voor de topics Cloud Computing, Infrastructuur en Datacenters.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5144110). © Jaarbeurs IT Media.

6,1


Lees meer over


 

Reacties

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? ;-)

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.

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 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.

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?

@ 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!

@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!

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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×