De impact van de cloudstrategie op het bedrijfsnetwerk (Dutch only)

Hoe zorg je ervoor dat het bedrijfsnetwerk de cloudstrategie ondersteunt en geen knelpunt wordt? Verkeersstromen draaien, knelpunten verplaatsen: sommige applicaties worden sneller, andere onwerkbaar traag. Het bedrijfsnetwerk en internetaansluiting worden na afloop van een cloudmigratie anders belast dan daarvoor. De impact van deze veranderingen goed inschatten blijkt lastig, maar het belang is groot: immers zonder een goed functionerend netwerk presteren de (SaaS)cloudapplicaties niet. In dit artikel leggen we uit waar op te letten bij het geschikt maken van het netwerk voor de cloudmigratie.

Netwerkverkeervolgt applicatie
Het netwerkverkeer (tussen client en server) volgt de applicatie; wordt een applicatie vanuit het datacenter gemigreerd naar een cloudproviderdan verdwijnt er een verkeersstroom richting het datacenter en ontstaat er een verkeersstroom op de internetaansluiting. Waar eerder voldoende capaciteit aanwezig was ontstaat nu krapte en andersom. Het inschatten van de benodigde netwerkcapaciteit na eencloudmigratie blijkt bijzonder lastig. Er zijn berekeningen te maken om de toekomstige netwerkbehoefte in te schatten, maar die berekeningen staan zo bol van de aannames en verwachtingen dat ze in de praktijk niet uitkomen. Ook kan de netwerklatency (de vertraging door de toegenomen afstand en het aantal tussenstations) flink toenemen wat de prestaties van de applicaties in de weg zit. Dat beïnvloedt de gebruikerstevredenheid en kan uiteindelijk de sfeer rondom de cloudmigratie gaan beheersen.

Het netwerk als onderdeel van de cloudstrategie
De vraag die als onderdeel van de cloudstrategie moet worden beantwoord is:

Hoe zien de toekomstige verkeersstromen eruit en welke netwerktopologie past hierbij? Zijn de veranderingen zo groot dat het netwerk opnieuw ingericht/gecontracteerd moet worden?

Er zijn modellen en tools beschikbaar om deze veranderende behoefte vooraf in kaart te brengen. Het probleem van dit soort ‘calculators’ is echter dat ze gevoed moeten worden met gebruiksprofielen zoals: “hoe vaak opent een gebruiker een groot PowerPoint bestand van Sharepoint” en “hoeveel grote e-mails ontvangt en verstuurt een gebruiker”. Deze aannames blijken in de praktijk ver te staan van het werkelijke gebruik waardoor het inkopen van netwerkcapaciteit op basis van deze berekeningen een hachelijke onderneming is. Beter is om tijdens de migratie het netwerkverkeer nauwgezet te monitoren en dan, in overleg met de leverancier, de bottlenecks op te lossen door de capaciteit op-of af te schalen. Deze capaciteit en flexibiliteit moet het contract met de netwerkleverancier dan natuurlijk wel bieden; dat is een aandachtspunt bij de contractering.

Internetverkeer eerst centraliseren of kiezen voor het lokaal uitbreken vanaf de vestiging?
Een belangrijke beslissing die bij het opnieuw inrichten van het netwerk moet worden genomen is: kiezen we voor een lokale break-out van internetverkeer op de vestigingen of centraliseren we al het verkeer en gaat het daar via een hoogwaardige internetaansluiting het internet op? In het pre-cloud tijdperk was het gebruikelijk om vestigingen onderling te verbinden met een Wide-Area-Network (WAN). Dergelijke gesloten (MPLS) netwerken bieden veel voordelen als het gaat om beveiliging en beheersing van de netwerkstromen maar als gevolg van de cloudmigratie worden ze minder relevant. De behoefte aan verkeer naar het centrale datacenter neemt af en snelle internettoegang is noodzakelijk. Daarbij geldt dat hoogwaardige internettoegang (Business Internet) inmiddels op bijna iedere locatie in Nederland tegen acceptabele kosten is te krijgen en dat capaciteit op de WAN-verbinding in de regel duurder is. In het geval van SaaS applicaties zoals Office 365 is ons advies te kiezen voor het lokaal uitbreken van het internetverkeer, dit geeft de beste prestaties en is voordeliger in gebruik. Een belangrijk argument daarbij is het verlagen van de netwerklatency, een tussenstop maken op de hoofdvestiging of in het datacenter (van de netwerkleverancier) voegt onnodige extra stappen en netwerklatency toe. Dit geldt ook voor de verplichte VPN-verbindingen die gebruikt moeten worden bij het werken buiten kantoor. Dat kan met name bij het gebruik van applicaties zoal Skype, Teams, Outlook en SharePoint het verschil maken tussen zeer goede prestaties en onwerkbaar.

Een belangrijk argument om het kostbare WAN te ontdoen van ‘frivool’ internetverkeer zoals Youtube en Internetradio wordt minder relevant; uit recente ervaring met aanbestedingen blijkt namelijk dat de prijsverschillen tussen WAN en Business Internet langzamerhand kleiner worden. Dit maakt dat de businesscase voor de Internetaansluiting op de vestiging niet persé gerealiseerd kan worden door de besparing op de (voorheen flink duurdere) WAN capaciteit; er worden tenslotte extra verbindingen op de vestiging binnengebracht (met de bijbehorende kosten). Ook gaan er kosten gepaard met het organiseren van de beveiliging van die lokale breakout. De belangrijkste business driver voor het lokaal uitbreken van SaaS verkeer is de applicatiesnelheid en dus gebruikerstevredenheid.

Verkeer naar Office 365 niet filteren of proxy-en
Een andere belangrijke architectuurbeslissing moet genomen worden rondom het filteren en eventueel proxy-en van verkeer richting de Office 365 cloud en andere SaaS applicaties. Als organisaties gebruik maken van een webfilter en/of proxy dan wordt al het verkeer, zonder uitzondering, daar doorheen geloodst. Dat is in het geval van Microsoft Office 365 en de meeste SaaS applicaties onnodig, bij binnenkomst in de datacenters van Microsoft wordt het verkeer namelijk al uitgebreid gecontroleerd en gefilterd. De extra controle binnen de organisatie zelf voegt daar niets aan toe. Met name applicaties zoals Skype en Teams hebben baat bij zo direct mogelijke toegang. Microsoft publiceert een lijst met adressen die uitgesloten dienen te worden van filtering en proxy-en. Zie de toelichting onderaan dit artikel voor meer informatie.

Netwerk automatiseren met behulp van SD-WAN
Mogelijkheden tot automatisering geven gelijk weer nieuwe input voor de herinrichting van het netwerk. Door gebruik te maken van internetverbindingen in combinatie met slimme software op de netwerkapparatuur-laag(een Software-Defined Wide-Area-Netwerk of SD-WAN) ontstaan er mogelijkheden om hetzelfde niveau aan beveiliging en functionaliteit te bereiken als met een traditioneel (MPLS) WAN maar met meer flexibiliteit. Een volledig met software bestuurd netwerk geeft de mogelijkheid om verbindingen te optimaliseren waar de hoogste toegevoegde waarde wordt gerealiseerd, zoals bijvoorbeeld voor Skype en Teams verkeer. Een SD-WAN oplossing voorziet ook in de behoefte om eenvoudig de connectiviteit naar de verschillende cloudomgevingen te realiseren en blijvend te optimaliseren. Deze Software-Defined-WAN’s zijn bijzonder interessant voor organisaties waarbij er veel wijzigingen in de WAN architectuur optreden, bijvoorbeeld om toegang te regelen tot cloudapplicaties. De kosten zijn op dit moment nog wel vrij hoog (>50%+ ten opzichte van reguliere WAN), dus weeg dit af tegen de voordelen zoals vermindering van beheerlast.

Wel of geen Direct Connect / Express Route verbinding?
Als laatste punt voor dit artikel; het vraagstuk over de directe verbinding tussen het bedrijfsnetwerk en de cloud. Alle grote cloudproviders bieden de mogelijkheid om, al dan niet via een cloudexchange zoals Equinixof IX-Reach, rechtstreeks te connecteren met de netwerken van de provider. De voor-en nadelen van een dergelijke verbinding zullen we in een separaat artikel behandelen maar de keuze om rechtstreeks te verbinden moet weloverwogen worden genomen. Naast argumenten over beveiliging en controle moet ook hier de prestaties van de applicaties meegenomen worden in de overweging. Regelmatig hebben de applicatieprestaties er baat bij, maar dat is zeker niet altijd het geval. Ook hier geldt weer dat de extra stappen die genomen worden om vanuit de gebruiker bij de Direct Connect / Express Route te komen vertraging toevoegen in plaats van wegnemen. De kortste route is vaak via het publieke Internet, een netwerk dat is ontworpen op basis van het principe om de kortste route van gebruiker naar bestemming te kiezen. De cloudproviders kiezen hun Edge locaties (dit is waar het providernetwerk aansluit op het Internet, dat is niet persé hetzelfde als waar de datacenters staan) op zo’n manier dat ze korte toegang hebben naar de grootst mogelijke groepen gebruikers. Soms bereik je de beste prestaties via het Internet, daar kan dan geen eigen netwerk tegenop.

Generieke principes voor netwerkarchitectuur bij cloud:

De volgende principes kunnen toegepast worden bij het nemen van architectuurbeslissingen. Deze principes zijn gebaseerd op onze ervaring met het uitvoeren van cloudstrategie projecten en de diverse ontwerpen die we daarbij als architect gemaakt hebben.

  1. Voorkom onnodige vertraging door haarspeldbochten in het netwerk (lokale break-out vs. centraliseren van Internetverkeer)
  2. Voer geen dubbele inspectie van het netwerkverkeer uit (Office 365 niet filteren of proxy-en)
  3. Behandel verkeersstromen niet gelijk; optimaliseer daar waar mogelijk (real-time verkeer vs. regulier)
  4. Optimaliseer het netwerk voor de hoogste gebruikersprestaties; kies de oplossing met de laagste netwerklatency (RTT)

De netwerkarchitectuur tijdens de cloudmigratie
Het oplossen van deze puzzel vereist inzicht in een flink aantal van de schuivende panelen; welke applicaties gaan er naar de public cloud; welk deel daarvan wordt als SaaS afgenomen; welk deel blijft er dan nog in het datacenter staan en vanaf waar wordt dit alles benaderd. Bij het uitvoeren van een cloudstrategie brengen we al deze elementen bij elkaar en zijn we in staat om de contouren van het netwerk te schetsen. Hierbij zouden de prestaties van de (SaaS)applicaties voor de gebruiker centraal moeten staan. Wat ons betreft behoort het bedrijfsnetwerk een onderdeel te zijn van de cloudstrategie en moet hier in elk geval goed over nagedacht worden.

Voor dit artikel heb ik input gebruikt van-,en gesproken met:

Verdiepende informatie over filtering enproxy-en
Microsoft stelt een lijst beschikbaar van die URL’s en IP-ranges die het beste uitgesloten kunnen worden van de filters en proxy’s. Deze lijst is opgedeeld in: beslist niet filteren | beter van niet | maakt weinig verschil; de adressen in de eerste categorie betreffen met name real-time diensten zoals bellen via Skype en conference calls via Teams hebben veel belang bij ongehinderde toegang
naar het Internet. Hiervoor geldt dus: niet proxy-en, niet decrypten maar zonder onderbrekingen naar het Internet.Waar het voorheen ging om duizenden adressen en honderden URL’s die handmatig ingevoerd moesten worden stelt Microsoft veel in het werk om het aantal gebruikte IP-ranges en URL’s voor Office 365 en Azure te beperken. Dat aantal is inmiddels aanzienlijk teruggebracht en Microsoft heeft een API beschikbaar waarmee de URL’s automatisch opgehaald kunnen worden. Moderne webfilters kunnen al overweg met deze API’s en kunnen het verkeer richting Office 365 ‘met de klik van een button’ uitzonderen van filtering zonder bewerkelijke handmatige administratie.

Additionele verdiepende informatie vind je hier.

Het inschatten van de benodigde netwerkcapaciteit blijkt bijzonder lastig. Er zijn berekeningen te maken om de toekomstige netwerkbehoefte in te schatten, maar die berekeningen staan zo bol van de aannames en verwachtingen dat ze in de praktijk niet uitkomen. 

Meer weten over hoe je het netwerk onderdeel kan maken van je cloudstrategie? Tijdens de meet-up op 28 mei introduceren we een stappenplan om deze ‘eenvoud’ te bereiken en behandelen we nog veel meer onderwerpen. Meld je gratis aan.

Door: Bart M. Veldhuis