Applicaties die zijn geschreven voor lokale netwerken, worden door bijkantoren vaak gebruikt over relatief trage huurlijnen, VPN-verbindingen, of via het internet. Een structurele oplossing lijkt nog niet in zicht. Bedrijven hikken aan tegen de investeringen voor het verhogen van hun bandbreedte. En applicatiebouwers vertrouwen liever op de voordelen van WAN-optimalisatie, dan dat ze applicaties schrijven die wél geschikt zijn voor Wide Area Netwerken (WAN). Dat zeggen de netwerkexperts van Computable.
Ze reageren daarmee op onderzoek van Riverbed. Daaruit bleek dat ontoereikende bandbreedte, gebruik van inefficiënte netwerkprotocollen en inefficiëntie ‘communicatie' van applicaties over het WAN ervoor zorgen dat dertig procent van de gebruikers buiten het hoofdkantoor zo'n twee tot drie uur per week bezig is met toegang krijgen tot documenten en applicaties op het bedrijfsnetwerk.
'Een belangrijke oorzaak van trage netwerkresponse zijn de complexe processen die de servers uitvoeren. Bij service oriented architecturen (soa) zijn ze vaak afhankelijk van andere servers voor deel-responses, en dus van WAN-lijnen. En qua communicatie zijn de applicaties meestal geschreven voor LAN-snelheden, terwijl slechts de lagere WAN-snelheden beschikbaar zijn. De vraag naar bandbreedte zal dus voorlopig blijven bestaan.' Dat zegt Computable-expert Joost Tholhuijsen van Tholhuijsen Consultancy.
Tholhuijsen: 'Applicaties zijn niet eenvoudig naar WAN-performance te herschrijven, dus lossen in de tussentijd WAN-accelerators of bijvoorbeeld Citrix-architecturen een deel van de problemen op. Dit maakt weer dat applicatie-bouwers op deze lapmiddelen blijven vertrouwen. Echte oplossing blijft echter een applicatie en bijbehorend protocol dat (ook) is geschreven voor WAN-snelheden. Zo kan het vereenvoudigen van de transportweg met IPv6 een deel van de WAN-vertraging verminderen.'
Stenen tijdperk
Voorlopig gaan veel organisaties gebukt onder capaciteitsproblemen. Arjan Anthonisse, projectleider bij IeTee Solutions: 'Een 2Mbit-verbinding wordt al gezien als een ruime verbinding. Wanneer zo'n verbinding met beperkte bandbreedte gebruikt wordt als een standaard LAN-verbinding, ga je terug naar het stenen tijdperk voor wat betreft de datadoorvoersnelheid. Het ophalen van een Word-documentje van 100Kb gaat dan nog wel als je alle bandbreedte voor jezelf hebt, maar als die lijn gebruikt wordt voor data, internet en applicatiedistributie is werken geen pretje meer.'
WAN-optimalisatie
In de tussentijd grijpen organisaties naar oplossingen zoals WAN-optimalisatie en datacompressie. Marcel van Wort, consultant bij Orange Business Services: 'Vooral wanneer een applicatie in een datacenter aan de andere kant van de wereld wordt geraadpleegd,kan het voorkomen dat een slechte gebruikerservaring ontstaat. Een goed ingeregelde WAN-optimalisatiedienst kan in deze gevallen wonderen verrichten.' Technisch ingenieur Enriko Groen van Atos Origin: 'Daarnaast valt er winst te halen door gebruik van voor WAN-geschikte protocollen en priorisering op de verbinding door Quality of Service (QoS).'
‘Paar duizend euro’
Organisaties besluiten niet snel tot het verhogen van de bandbreedte. Groen: 'Bandbreedtebeheer wordt vaak over het hoofd gezien. De verbinding was er toch al en dit kan er nog wel bij.' Anthonisse: 'Een verbinding met een hoge uploadsnelheid en hoge beschikbaarheid is duur. Bedrijven zien op tegen de benodigde investeringen voor uitbreiding van de bandbreedte.'
Volgens Richard Jonker van Netgear vallen die investeringen echter wel mee: 'Voor kleinere vestigingen tot twintig werknemers zou je kunnen kijken naar een stevige internetverbinding in combinatie met een alles-in-1 UTM en een stack smart switches. Alles bij elkaar ben je dan voor een paar duizend euro klaar voor cloudcomputing anno 2010.'
Hoezo specialistische eigen parochie prekers ? Welk probleem wordt hier vastgesteld? Iets dat al 20 jaar of zo speelt, anders was Citrix niet een Fortune 500 club geworden.
In de Cloud draaien feitelijk alleen low bandwidth apps; web geoptimaliseerd. Anders werkt de Cloud niet. daar heb je dus geen speciale apparatuur voor nodig.
De Cloud kan ook trage apps bieden, via een Citrix interface. Maar dat is afhankelijk van de vraag naar die applikatie.
Hebben ze nog nooit van Terminal Server/Citrix gehoord?
Je gaat toch ook niet traditioneel client/server over zo’n VPN verbinding draaien. Als je applicaties naar de buitenwereld wilt ontsluiten, doe dat dan via TS/Citrix: Je weet dat je ongeveer maar zo’n 10KB/s per client nodig hebt om GOED te kunnen werken.
WAN-optimalisatie kan maar een deeltje van het probleem oplossen, maar dan zal je toch eerst beter inzage moeten gaan krijgen in de applicaties die over het netwerk gaan, voordat men kan optimaliseren. Dit is volgens mij het eerste probleem dat aangapakt moet gaan worden. Uit een onderzoek bleek dat Enterprise bedrijven totaal niet weten hoeveel en welke applicaties ze hebben draaien en dat dit meestal vele malen hoger is dan men denkt.
Terminal Server/Citrix is een goede oplossing om te gebruiken bij beperkte bandbreedte, maar waar men vaak tegen aanhikt zijn de benodigde investeringen. Hetzelfde probleem dus als met het ophogen van de bandbreedte of het investeren in WAN optimalisatie. Overigens ben ik zelf van mening dat je het probleem op alle fronten moet aanpakken. Dus zeker inventariseren wat je allemaal aanbiedt, vervolgens kijken of een andere manier van werken (lees: ts) toepasbaar is en vervolgens de optimale bandbreedte bij de nieuwe manier van werken bepalen.
Applicaties zijn in het algemeen te zwaar, kijk nou naar al die mooie bouwblokken die je aangedragen krijgt via bijvoorbeeld .NET, hiermee word het je heel gemakkelijk gemaakt om als programmeur al je feeling met benodigde resources en dan met name bandbreedte te verliezen.
Ik zou hier een boek over kunnen schrijven, mijn eerste reactie was:
No sh*t sherlock
Goed artikel. De korte termijnoplossingen zoals WAN-accelerators, priorisering en Server Based Computing worden nog steeds te vaak onvoldoende benut.
Door deze tijdelijke oplossingen vergeten veel CIO’s en hoofden automatisering dat multi-locatie applicaties toch echt anders geschreven moeten worden. En dat soms al 15-20 jaar lang.
Ik zie velen praten over apps aanbieden middels Xenap of TS, omdat deze weinig bandbreedt zouden gebruiken (10K).
Zelfs ICA sessies van meerdere mb’s (print binnen ICA) zijn geen uitzondering dus dat gaat al niet op.
Het zet je aan het denken waarom de BranchRepeater van Citrix als unique sellingpoint “het optmaliseren van ICA” heeft.
Hoe de apps geschreven worden is de eerste horde die je moet nemen, en er voor te zorgen dat dit goed gebeurd.
En wat te denken van de latency op de link, zelfs Citrix heeft daar last ook al heb je de leuke features van Citrix aanstaan die dit zouden moeten “oplossen”
Upgraden van bandbreedt is zeker een mogelijkheid maar is van tijdelijke aard, en bandbreedte verhogen op internationale links doe je niet even voor een paar euro.
Ongeacht de gekozen oplossing: als bedrijf moet je wel willen investeren in je verbindingen wil je de satteliet-vestigingen naar behoren kunnen laten werken.
En zoals Frank al aangeeft, het verhogen van de bandbreedte over internationale links is niet goedkoop.
Dat is de keerzijde van internationaal willen werken.
Veel van de reacties wijzen op TS/Citrix e.d. als de “oplossing” terwijl dit nou precies is wat het artikel probeert duidelijk te maken: door het gebruik van dit soort lapmiddelen komen applicatie-ontwikkelaars er mee weg om applicaties te bouwen die alleen op een LAN (en dan bij voorkeur nog eens minimaal 100Mb/s) goed functioneren. Bij WAN verbindingen is het vaak niet zozeer de bandbreedte die performance de nek om draait, maar vaak nog veel meer de toegenomen latency.
Wanneer voor een simpel inlog-scherm 30 of meer ‘request-response’ paren tussen client en server verzonden worden duurt dit bij een latency van 100ms dus al minimaal 3 seconden! 100ms is typisch voor een verbinding tussen Europa en de oostkust van de VS.
En waar een hogere bandbreedte (tegen meer geld) nog wel te realiseren is, is een lagere latency fysiek onmogelijk.