Datum: 25-08-2015
Auteur: Jeroen Gijze, Manager Consulting

Blog_JeroenGijze_20150825Al vele jaren is er in de basis eigenlijk niet zo heel veel veranderd in de wereld van networking. In de grotere netwerken gebruiken we al sinds jaar en dag een drielaags model: de core switches, de distributielaag richting de access switches en de access switches zelf voor de werkplekken, printers en dergelijke. Een overzichtelijk, begrijpelijk model waar we de afgelopen vijfentwintig jaar mee zijn opgegroeid. Met duidelijke verkeersstromen, namelijk tussen werkplek en servers. Uiteraard met de nodige uitdagingen. Denk bijvoorbeeld aan de complexiteit die komt kijken bij het bieden van een hoge beschikbaarheid door kritische componenten dubbel uit te
voeren.

Traditionele netwerken zijn complex

Laten we eerlijk zijn. Soms was een netwerk volledig redundant opgezet, maar wisten we toch niet altijd te voorkomen dat het volledig onderuit ging als gevolg van configuratiefoutjes, juist door die complexiteit. Gelukkig hadden we houvast als het gaat om inzicht in datastromen. Op een werkplek draait een applicatie, de datafiles staan centraal op servers of in de storagesystemen en anders halen we wat van het internet. Alles volgens een strak pad: de Noord-Zuidlijn. En doordat het zulke duidelijke paden betreft, zijn we makkelijk in staat om met wat eenvoudige statefull firewalls en IPS-systemen het dataverkeer ook nog netjes door de wasstraat heen te trekken teneinde alle ellende die we kunnen verzinnen te voorkomen.

De echte wereld: verkeer is niet voorspelbaar

Maar in de echte wereld, en dus ook de echte wereld van networking, laten mooie theoretische modellen zich in praktijk toch van een meer weerbarstige kant zien. De modellen kloppen niet altijd, of werken juist contraproductief. Toch houden we angstvallig vast aan het model, omdat we het altijd al zo gedaan hebben en… snappen wat er gebeurt. Maar de wereld om ons heen verandert. Applicaties veranderen, het gebruik verandert. In plaats van eigen opslag maken we steeds meer gebruik van cloud-oplossingen. Ook rechtstreekse communicatie tussen werkplekken komt meer en meer voor. Heeft u daadwerkelijk zicht op hoe alle verkeersstromen in uw netwerk zijn? De kans dat u die vraag met ‘ja’ kunt beantwoorden acht ik niet zo heel groot. We weten het vaak ‘globaal’.

Applicaties en netwerken zijn twee werelden

Het is best lastig om applicaties met elkaar te laten communiceren over een netwerk. Het zijn twee totaal verschillende werelden en er zijn maar weinig mensen die beide werelden volledig begrijpen. Daar waren we al heel snel achter. Daarvoor is het alom bekende OSI-laag model ontwikkeld, waar we weer wat houvast aan hadden zodat we taken en verantwoordelijkheden bij de verschillende
specialisten konden beleggen. We hoefden ons niet om alles zorgen te maken, als we de afspraken over ‘hoe we met elkaar omgaan’ maar helder hadden. De complexiteit gaat er niet geheel door weg. We hebben slechts wat structuur aangebracht. Maar eigenlijk snappen we dus helemaal niet zo goed wat er gebeurt.
Er is veel onbegrip over en weer. Waarom snappen applicatiebouwers niet dat het handig is dat alle datastromen volgens een vast pad lopen? Waarom snappen ze niet dat wij wellicht onderscheid willen maken tussen SQL-databases die productie draaien en SQL-databases die in ontwikkel- en testomgevingen worden gebruikt? Of dat wij sturing willen kunnen geven om tijdkritische applicaties met voorrang over het netwerk te leiden.

Applicaties centraal stellen

Zelfs ‘wij van networking’ moeten toch één ding toegeven. De applicatie is van het allergrootste belang. Zonder applicaties hebben we geen informatie en hoeven we ook geen communicatienetwerk te bouwen. En eigenlijk snappen we ook wel dat we dus de applicatie centraal zouden moeten stellen. Wij draaien om de zon heen, de zon draait niet om ons. Als applicatiebouwers vinden dat er niet alleen Noord-Zuidverkeer zou moeten zijn maar ook Oost-westverkeer, dan zullen wij ons daarop moeten aanpassen. Zo… dat is dan maar gezegd. En ja, het doet pijn. Nog wel, want hier is de nieuwe belofte: Software Defined Networking (SDN) gaat u helpen.

Software Defined Networking met Cisco of VMware?

Nu lijken er twee stromingen te ontstaan. We gebruiken het SDN van VMware, of we vertrouwen op de 30 jaar kennis en kunde van dé netwerkbouwer Cisco door ACI te gebruiken. Twee grote bedrijven, de één helemaal thuis in de applicatiewereld, de ander in de netwerkwereld. Wie van de twee heeft het beste DNA? Of kan het gewoon beiden prima naast elkaar bestaan? Hierover wil ik in een latere blog graag een keer uitweiden.

Netwerk moet zich aanpassen aan applicaties

Webinar_SDNOver één ding wil ik graag heel duidelijk zijn. Het netwerk blijft altijd belangrijk. Wat er echter verandert is dat het netwerk zich beter moet aanpassen aan de applicaties. En we spreken af dat we het voor de gemiddelde netwerkbeheerder eenvoudiger willen maken. Mike Dvorkin zou gezegd hebben: “Networks are very, very simple: groups of things connect to other groups of things. We apply policies. Don’t overcomplicate!”
En eigenlijk is dat het hele spel. Wij willen beleid over wat wel of niet mag kunnen afdwingen. Dát is waar wij ons namelijk zorgen over maken. Er zorg voor dragen dat wat ‘de baas wil’ aantoonbaar wordt uitgevoerd.

Transitie naar applicatiecentrisch netwerk: hoe bereid je je voor?

Als eenvoud nu de belofte is, hoe moet ik dan starten? Hoe ziet zo’n applicatiecentrisch netwerk er in de praktijk uit? De eerste voor de hand liggende stap is een korte inventarisatie of de bestaande hardware geschikt is voor een applicatiecentrisch SDN of dat er nieuwe hardware benodigd is. Dit is de gemakkelijke stap. Een wat lastigere vraag is in praktijk vaak: Hoe ziet het applicatielandschap eruit? En welke applicaties hebben wat met elkaar van doen? In welke securityzone bevinden deze zich? En hoe gaan we om met de uitzonderingen die niet in een SDN te vangen zijn? Eén ding is duidelijk: in de praktijk hebben we niet uitsluitend te maken met virtuele systemen en VMware, maar ook met hardware devices zoals fysieke servers, IP-telefooncentrales, modems of een andere hypervisor zoals Microsoft Hyper-V. Wellicht wat ‘old school’ maar ze blijken er in praktijk toch bijna altijd nog echt te zijn.

Beloofde eenvoud komt pas na realisatie

Eén en ander vergt dus best wat uitzoekwerk. Met andere woorden: het is wellicht toch niet zo heel eenvoudig. De eenvoud komt pas nadat de inrichting is afgerond en dan met name op beheer of instandhouding van een omgeving. Dát is naar mijn mening dan ook vooral het doel. Het oudhollands gezegde ‘De kost gaat voor de baat uit’ gaat ook hier natuurlijk op. Investeren in tijd en middelen om later tijd en kosten te kunnen besparen. Of die investering de moeite waard is kan globaal worden ingeschat. Omvang van een omgeving en hoeveelheid changes zijn daarbij belangrijke parameters. Maar ook een verkorting van de ‘time to market’ van nieuwe ideeën in uw organisatie kan een voordeel zijn dat wellicht de doorslaggevende factor gaat zijn.

Meer weten over de meerwaarde van ACI?

Binnenkort volgt een meer technische verdieping vanuit mijn collega Michel van Kessel. Als u niet wilt wachten, dan kunt u natuurlijk altijd even contact met mij (jeroen.gijze@axians.com) opnemen.

Een interessante vergelijking tussen de positie van Cisco naast VMware en OpenStack komt uitgebreid aan bod in ons webinar van 2 juni jongstleden.

Webinar_terugkijken