Cloud-beheerde locaties: wanneer wel, en wanneer niet

Welk probleem het oplost

Een organisatie met twintig vestigingen en één netwerkbeheerder heeft geen technisch probleem maar een reisprobleem. Elke wijziging die op locatie moet gebeuren kost een dag: heen, doen, terug. Elke storing waarvoor iemand ter plaatse moet zijn, duurt zo lang als de rit erheen.

Cloud-beheerd netwerk haalt die rit eruit. Het apparaat haalt zijn configuratie uit een beheeromgeving die je vanaf elke plek opent, en die beheeromgeving is dezelfde voor alle vestigingen. Een nieuwe vestiging aansluiten is dan: apparaat opsturen, iemand ter plaatse steekt de stroom en de internetverbinding erin, en de rest gebeurt vanaf afstand.

Dat is geen kleine winst. Het verschil tussen "we sturen morgen iemand" en "ik doe het nu" is voor een filiaalorganisatie het verschil tussen een dag omzet en een half uur ongemak.

Wanneer het past

Cloud-beheerd netwerk komt het best tot zijn recht als aan drie dingen tegelijk is voldaan.

• Veel vestigingen die op elkaar lijken. Twintig winkels met dezelfde indeling zijn twintig keer dezelfde configuratie. Eén sjabloon, twintig apparaten. Bij drie vestigingen die alle drie anders zijn, is die winst er niet.
• Geen technische mensen op locatie. Als er in elke vestiging iemand zit die een switch kan configureren, betaal je voor gemak dat je al had.
• Het beheer moet overdraagbaar zijn. Eén console waarin alles zichtbaar is, is makkelijker over te dragen dan twintig apparaten met elk hun eigen wachtwoord.

De sector waar dit het vaakst klopt is retail, gevolgd door horeca met meerdere zaken en zorgorganisaties met kleine locaties verspreid over een regio.

Wanneer het niet past

Er zijn drie situaties waarin we het afraden, en dat doen we ook als het ons werk zou schelen.

• Eén groot pand met eigen eisen. Een hoofdkantoor of een productielocatie heeft vaak configuraties die niet in een sjabloon passen. Dan werk je tegen het product in.
• De omgeving mag niet naar buiten praten. Bij cloud-beheer staat de beheerlaag buiten je pand. In een omgeving waar dat niet mag — sommige industriële netwerken, sommige gereguleerde omgevingen — valt het af, punt.
• De licentiestructuur past niet. Bij Meraki is de licentie geen serviceabonnement maar een voorwaarde: verloopt hij, dan stopt het apparaat. Dat is een bewuste keuze van de fabrikant en het is te overzien, maar je moet het weten voordat je koopt en niet erna.

In die gevallen kijken we naar apparatuur die je zelf beheert. Fortinet als de firewall het zwaartepunt is, Juniper bij grotere campus- en datacenterswitching, Ubiquiti waar een eigen controller en voorspelbare licenties zwaarder wegen dan beheer op afstand.

Waar de kosten zitten

Bedragen staan niet op deze site, maar de opbouw wel, want daar zitten de verrassingen.

Bij cloud-beheerde apparatuur betaal je twee dingen: het apparaat en de licentie die eraan vastzit. Die tweede loopt door zolang het apparaat in gebruik is. Vergelijk je dat met apparatuur die je één keer koopt, dan lijkt de eerste optie duurder. Vergelijk je het met apparatuur die je één keer koopt plus de reistijd van iemand die eens per kwartaal langs twintig vestigingen gaat, dan kantelt het.

Die rekensom hangt af van het aantal locaties, de afstand ertussen en hoe vaak er iets moet gebeuren. Wij maken hem met je, met jouw aantallen, en we laten hem zien in plaats van er een conclusie uit voor te lezen.

De afhankelijkheid die je aangaat

Cloud-beheer betekent dat je beheerlaag bij een fabrikant staat. Dat heeft twee gevolgen die je vooraf moet wegen.

Het eerste is dat je die fabrikant niet zomaar verlaat. De apparaten werken niet met de console van een ander merk. Overstappen betekent hardware vervangen, en dat is een investering die je niet elke drie jaar wilt doen.

Het tweede is dat je verkeer blijft lopen als de beheeromgeving onbereikbaar is. Dat is bij dit type apparatuur zo ontworpen: de configuratie staat lokaal, de cloud is voor beheer en niet voor doorvoer. Dat is een belangrijk verschil, en het is de reden dat we dit type netwerk wel op locaties inzetten die niet stil mogen vallen.

Wij noemen die afhankelijkheid altijd voordat er iets besteld wordt. Een keuze die je over vijf jaar niet meer kunt uitleggen, is geen goede keuze, ook niet als hij vandaag werkt.

Hoe wij het inrichten

Als we dit inzetten, doen we het in deze volgorde.

• Eerst één vestiging, dan de rest. Een sjabloon dat op één locatie bewezen werkt, is een sjabloon. Een sjabloon dat op papier klopt, is een aanname.
• Verkeer gescheiden vanaf het begin. Gasten, personeel en betaalverkeer horen niet op hetzelfde netwerk. Achteraf scheiden is werk; vooraf is het een vinkje.
• Bewaking die zelf meldt. Een uitgevallen vestiging hoor je van het systeem, niet van de bedrijfsleider.
• Documentatie die van jou is. Wachtwoorden, licenties en de inrichting staan op jouw naam. Gaat het beheer ooit naar een ander, dan gaat het mee.

Hoe we een netwerk over meerdere locaties ontwerpen en beheren staat onder managed netwerk.