Op het moment van schrijven gaf een zoekopdracht op een populaire vacaturesite naar de term 'Netwerkingenieur' ongeveer driehonderd vacatures in heel Nederland. Ter vergelijking: een zoektocht naar 'systeembeheerder' levert bijna 2,5 duizend vacatures op, en 'DevOps engineer' bijna 800.
Betekent dit dat netwerkspecialisten niet meer nodig zijn in het tijdperk van cloud computing, Docker, Kubernetes en alomtegenwoordig publiek wifi?
Laten we het uitzoeken (c)
Laat me me voorstellen. Mijn naam is Alexey, en ik ben netwerkspecialist.
Ik werk al meer dan 10 jaar met netwerken en meer dan 15 jaar met verschillende *nix-systemen (ik heb zowel met Linux als FreeBSD gewerkt). Ik heb gewerkt bij telecomoperators, grote bedrijven die als 'enterprise' worden beschouwd, en de laatste tijd werk ik in een 'jong en gedurfde' fintech, waar cloud computing, DevOps, Kubernetes en andere uitdagende termen de norm zijn, die mij en mijn collega's ooit overbodig zullen maken. Misschien.
disclaimer: 'In ons leven is niet alles, altijd en overal, en sommige dingen, soms en op bepaalde plaatsen' (c) Maxim Dorofejev.
Alles wat hieronder staat, kan en moet worden beschouwd als de persoonlijke mening van de auteur, die niet pretendeert de ultieme waarheid te zijn, en zelfs niet als een volledig onderzoek. Alle personages zijn fictief, alle overeenkomsten zijn toevallig.
Welkom in mijn wereld.
Waar kom je netwerkspecialisten Ć¼berhaupt tegen?
1. Telecomoperators, servicebedrijven en andere integratoren. Hier is het eenvoudig: netwerken zijn voor hen business. Ze verkopen direct connectiviteit (operators) of bieden diensten aan voor het opzetten/onderhouden van netwerken voor hun klanten.
Er is hier veel ervaring, maar niet veel geld (tenzij je directeur of een succesvolle salesmanager bent). Toch, als je van netwerken houdt en net begint, is een carriĆØre in de support van een niet al te grote operator, zelfs nu, een ideale startpunt. Bij de grote spelers is alles zeer gescript en is er weinig ruimte voor creativiteit. En de verhalen dat je van een dienstdoende ingenieur in enkele jaren kunt doorgroeien naar een C-level manager zijn ook heel realistisch, hoewel ze om begrijpelijke redenen zeldzaam zijn. De vraag naar personeel is er altijd, omdat er een behoorlijke verloop is. Dat is zowel goed als slecht ā er zijn altijd vacatures, maar aan de andere kant vertrekken de meest actieve/slimme mensen vaak vrij snel naar hogere posities of naar andere, aangenamere plekken.
2. Voorwaardelijke "enterprise"Het maakt niet uit of de belangrijkste activiteit verband houdt met IT of niet. Het belangrijkste is dat er een IT-afdeling is die zich bezighoudt met de werking van de interne systemen van het bedrijf, zoals netwerken in de kantoren, communicatielijnen naar de filialen, enz. De rol van een netwerkengineer in dergelijke bedrijven kan soms worden vervuld door een systeembeheerder (als de netwerkinfrastructuur klein is, of als een externe aannemer deze beheert), terwijl de netwerkbeheerder, als die er is, ook toezicht kan houden op telefonie en SAN (geen probleem). De salarissen verschillen sterk - dit hangt veel af van de winstmarges van het bedrijf, de grootte van het bedrijf en de structuur. Ik heb gewerkt met bedrijven waar Cisco-apparatuur regelmatig werd overbelast, en met bedrijven waar netwerken uit vuil, takken en blauwe tape werden opgebouwd, en waar servers nooit werden geĆ¼pdatet (moet ik zeggen dat er ook geen reserves waren). Er is hier veel minder ervaring, en het zal vrijwel zeker in de richting van strikte vendor-lock of "hoe iets uit niets te maken" zijn. Persoonlijk vond ik het daar extreem saai, hoewel veel mensen het leuk vinden - alles verloopt vrij rustig en voorspelbaar (als we het hebben over grote bedrijven), "doerakha-bakhato" enzovoort. Ten minste Ć©Ć©n keer per jaar beweert een grote leverancier dat hij weer een mega-super-duper-systeem heeft bedacht, dat volledig automatiseert en dat alle systeembeheerders en netwerkbeheerders kunnen worden ontslagen, met alleen een paar over om op knoppen in een mooi interface te drukken. De realiteit is echter zo dat, zelfs als we de kosten van de oplossing negeren, netwerkbeheerders daar niet weg zullen gaan. Ja, mogelijk zal er weer een webinterface zijn in plaats van een console (maar nu niet voor een specifiek apparaat, maar voor een groot systeem dat tientallen en honderden van zulke apparaten beheert), maar de kennis van "hoe alles van binnen werkt" zal nog steeds nodig zijn.
3. Productbedrijven, die winst genereert uit de ontwikkeling (en vaak de exploitatie) van bepaalde software of platforms - dat is het product. Ze zijn meestal klein en snel, en zijn nog ver verwijderd van de schaal van ondernemingen en hun bureaucratie. Hier zijn het precies deze devops, kubernetes, dockers en andere angstaanjagende woorden die massaal aanwezig zijn en die zeker het netwerk en netwerkingenieurs tot een overbodig relicter maken.
Wat is het verschil tussen een netwerkbeheerder en een systeembeheerder?
Voor mensen buiten de IT betekent het niets. Beide kijken naar een zwart scherm en typen allerlei spreuken, soms zachtjes vloekend.
Voor programmeurs is het eerder een vakgebied. Systeembeheerders beheren servers, netwerkbeheerders beheren switches en routers. Soms doen ze dat slecht, en dan vallen er dingen uit. In geval van vreemde problemen zijn de netwerkbeheerders ook vaak de schuldigen. Gewoon omdat het zo is.
De belangrijkste betekenis ligt in de aanpak van het werk. Misschien is het onder netwerkbeheerders het meest voorkomend dat ze de houding hebben: 'Als het werkt, laat het dan zo'. Het maken van iets (binnen Ć©Ć©n vendor) kan meestal maar op Ć©Ć©n manier, de hele configuratie ligt letterlijk voor je neus. De prijs van een fout is hoog, soms zelfs heel hoog (bijvoorbeeld, je moet honderden kilometers rijden om een router opnieuw op te starten, terwijl duizenden mensen zonder verbinding zitten ā een vrij gebruikelijke situatie voor een telecomoperator).
Naar mijn mening zijn netwerkingenieurs daarom aan de ene kant enorm gemotiveerd voor netwerkstabiliteit (en veranderingen zijn de voornaamste vijand van stabiliteit), en aan de andere kant zijn hun kennis en vaardigheden diepgaander dan breed. Je hoeft niet tientallen verschillende demonen te kunnen configureren, maar je moet de technologieƫn en hun implementatie bij specifieke fabrikanten begrijpen. Daarom is een systeembeheerder die heeft gegoogeld hoe je een VLAN op een Cisco instelt, nog geen netwerkbeheerder. En hij zal waarschijnlijk niet in staat zijn om een meer of minder complex netwerk effectief te onderhouden (en probleemoplossingen daarbij).
Maar waarom heb je een netwerkbeheerder nodig als je hebt hoster?
Voor een extra vergoeding (en als je een zeer grote en geliefde klant bent ā misschien zelfs gratis, 'om de vriendschap') zullen datacenteringenieurs je switches afstemmen op jouw behoeften, en misschien zelfs helpen om BGP-connecties met providers op te zetten (als je een eigen subnet hebt van IP-adressen voor aankondiging).
Het belangrijkste probleem is dat de datacenter geen IT-afdeling is, maar een apart bedrijf dat als doel heeft winst te maken. Dit gebeurt ook ten koste van jou als klant. Het datacenter biedt racks aan, voorziet ze van elektriciteit en koeling, en zorgt daarnaast voor enige 'standaard' connectiviteit met het internet. Op basis van deze infrastructuur kan het datacenter jouw apparatuur huisvesten (colocation), je een server verhuren (dedicated server) of managed services aanbieden (zoals OpenStack of K8s). Maar het beheer van de infrastructuur van klanten behoort (meestal) niet tot de kernactiviteiten van het datacenter, omdat dit een arbeidintensief proces is dat moeilijk te automatiseren is (en in een goed datacenter is alles wat mogelijk is geautomatiseerd), nog moeilijker te uniformeren (elke klant is uniek) en doorgaans leidt tot klachten (zoals: 'jullie hebben mijn server ingesteld, maar hij is nu gecrasht, jij bent schuldig!!!111'). Daarom, als de hoster je ergens mee helpt, zal hij proberen dit zo simpel en effectief mogelijk te doen. Moeilijk doen is niet winstgevend, vooral niet vanuit het perspectief van de arbeidsinspanningen van de ingenieurs van die hoster (maar situaties kunnen variƫren, zie de disclaimer). Dit betekent niet dat de hoster alles per definitie slecht zal doen. Maar het is helemaal niet zeker dat hij precies datgene zal doen wat je eigenlijk nodig had.
Het lijkt misschien voor de hand liggend, maar ik ben in mijn praktijk meerdere keren tegengekomen dat bedrijven iets te veel vertrouwden op hun hostingprovider, wat niet tot goede resultaten leidde. Ik moest vaak uitgebreid uitleggen dat geen enkele SLA de verliezen door downtime dekt (er zijn uitzonderingen, maar die zijn meestal erg, ERG duur voor de klant) en dat de hoster helemaal niet op de hoogte is van wat er in de infrastructuur van de klanten gebeurt (behalve heel algemene statistieken). En backups maakt de hoster ook niet voor jou. Het wordt nog erger als je meer dan Ć©Ć©n hoster hebt. In geval van problemen zullen ze zeker niet voor jou uitzoeken wat er precies mis is gegaan.
Eigenlijk zijn de motieven hier precies hetzelfde als bij de keuze tussen "eigen team van admins vs outsourcing". Als de risico's zijn ingeschat, de kwaliteit acceptabel is en het bedrijf staat achter deze keuze ā waarom niet proberen? Aan de andere kant is het netwerk een van de meest basale lagen van de infrastructuur, en het is twijfelachtig of je dat aan externe partijen moet overlaten als je alles ander zelf al ondersteunt.
In welke gevallen is een netwerkingenieur nodig?
Hierna gaat het specifiek over moderne productbedrijven. Bij operators en enterprise is het min of meer duidelijk ā daar is de situatie de afgelopen jaren nauwelijks veranderd, en netwerkingenieurs waren daar vroeger nodig, en zijn dat nu nog steeds. Maar met die "jonge en gedurfde" bedrijven is het niet zo eenduidig. Vaak plaatsen ze hun infrastructuur helemaal in de cloud, waardoor ze zelfs geen admins nodig hebben ā behalve die voor diezelfde cloud, uiteraard. De infrastructuur is enerzijds vrij eenvoudig van opzet, anderzijds goed geautomatiseerd (ansible/puppet, terraform, ci/cdā¦ nou ja, dat weet je wel). Maar zelfs hier zijn er situaties waarin je niet zonder een netwerkingenieur kunt.
Voorbeeld 1, klassiek
Stel dat een bedrijf begint met Ć©Ć©n server met een publiek ip-adres, die zich in een datacenter bevindt. Dan komen er twee servers. Dan meerā¦ vroeg of laat ontstaat de noodzaak voor een privaat netwerk tussen de servers. Omdat het "externe" verkeer beperkt is, zowel qua bandbreedte (bijvoorbeeld niet meer dan 100 Mbit/s), als qua hoeveelheid data die per maand wordt gedownload/geĆ¼pload (verschillende hostingproviders hebben verschillende tarieven, maar de bandbreedte naar de buitenwereld is meestal veel duurder dan die van een privaat netwerk).
De host voegt extra netwerkkaarten toe aan de servers en koppelt deze aan zijn switches in een aparte VLAN. Tussen de servers ontstaat er een "platte" lokale netwerkomgeving. Handig!
Het aantal servers neemt toe, net als het verkeer in het privĆ© netwerkāback-ups, replicaties, enzovoort. De hoster biedt aan om u naar afzonderlijke switches te verhuizen, zodat u de andere klanten niet stoort en zij u niet storen. De hoster plaatst een aantal switches en configureert ze op een manierāwaarschijnlijk door een vlak netwerk tussen al uw servers te laten. Het werkt goed, maar op een bepaald moment ontstaan er problemen: de latenties tussen de hosts nemen periodiek toe, er zijn fouten in de logs over te veel arp-pakketten per seconde, en de pentester heeft tijdens de audit uw hele lokale netwerk gekraakt door slechts Ć©Ć©n server te breken.
Wat moet er gebeuren?
De netwerk splitsen in segmentenāvlanās. In elke vlan zijn eigen adressering instellen, een gateway toewijzen die het verkeer tussen netwerken doorstuurt. Op de gateway acl instellen voor toegangslimieten tussen de segmenten, of zelfs een aparte firewall erbij plaatsen.
Voorbeeld 1, vervolg
Servers zijn met Ć©Ć©n kabel verbonden met het lokale netwerk. De switches in de racks zijn op een bepaalde manier met elkaar verbonden, maar als er een storing is in Ć©Ć©n rack, vallen ook nog drie aangrenzende racks uit. Schemaās bestaan, maar de actualiteit ervan is twijfelachtig. Elke server heeft zijn eigen publieke adres, dat door de hoster wordt verstrekt en aan het rack is gekoppeld. Dus als de server wordt verplaatst, moet het adres worden gewijzigd.
Wat moet er gebeuren?
Verbind de servers via LAG (Link Aggregation Group) met twee kabels naar de switches in het rack (die moeten ook redundant zijn). Verbindingen tussen racks moeten redundant zijn, herconfigureer ze naar een 'ster' (of de trendy CLOS), zodat het uitvallen van Ć©Ć©n rack de andere niet beĆÆnvloedt. Reserveer 'centrale' racks waar de netwerkcore zich bevindt, en waar andere racks op kunnen worden aangesloten. Ook de publieke adressering op orde brengen, neem een subnet bij de hoster (of bij RIR, als dat mogelijk is) dat zelfstandig (of via de hoster) in de wereld kan worden aangekondigd.
Kan een 'gewone' systeembeheerder, die niet diepgaande kennis van netwerken heeft, dit allemaal doen? Niet zeker. Zult u dit door de hoster laten doen? Misschien, maar dan is er een behoorlijk gedetailleerd technisch specificatie nodig, die ook door iemand moet worden opgesteld, en vervolgens moet gecontroleerd worden of alles correct is uitgevoerd.
Voorbeeld 2. Cloud
Stel dat je een VPC hebt in een publiek cloud. Om toegang te krijgen vanuit kantoor of on-premise infrastructuur tot het lokale netwerk binnen de VPC, moet je een verbinding via IPSec of een dedicated kanaal opzetten. Enerzijds is IPSec goedkoper, omdat je geen extra hardware hoeft aan te schaffen; je kunt een tunnel opzetten tussen je server met een publiek adres en de cloud. Maar daarentegen zijn er latenties, beperkte prestaties (omdat het kanaal versleuteld moet worden), plus niet-garantie op connectiviteit (omdat de toegang via het reguliere internet gaat).
Wat moet er gebeuren?
Een verbinding opzetten via een dedicated kanaal (bijvoorbeeld, bij AWS heet dit Direct Connect). Hiervoor moet je een partneroperator vinden die je kan aansluiten, bepalen bij welk aansluitpunt je het dichtstbij bent (zowel bij jou als bij de operator in de cloud) en tenslotte alles instellen. Is het mogelijk om dit zonder netwerkingenieur te doen? Vast en zeker. Maar hoe je zonder hem problemen moet oplossen als die zich voordoen, is al minder duidelijk.
Daarnaast kunnen er problemen optreden met de beschikbaarheid tussen clouds (als je multi-cloud hebt) of problemen met latenties tussen verschillende regio's, enzovoort. Natuurlijk zijn er tegenwoordig veel tools beschikbaar die de transparantie van wat er in de cloud gebeurt verhogen (zoals Thousand Eyes), maar dit zijn allemaal-tools voor netwerkingenieurs, en geen vervanging van hen.
Ik zou nog een tiental van zulke voorbeelden uit mijn praktijk kunnen geven, maar ik denk dat het duidelijk is dat, in een team, vanaf een bepaald niveau van infrastructuurontwikkeling, er iemand (of beter nog meerdere) moet zijn die weet hoe het netwerk werkt, in staat is om netwerkapparatuur in te stellen en problemen op te lossen als ze zich voordoen. Geloof me, hij zal druk genoeg zijn.
Wat moet een netwerkingenieur weten?
Het is helemaal niet noodzakelijk (en soms zelfs schadelijk) dat een netwerkingenieur zich alleen met netwerken bezig houdt en met niets anders. Zelfs als je de optie van infrastructuur die bijna volledig in de publieke cloud leeft niet meerekent (en die wordt, hoe dan ook, steeds populairder), en bijvoorbeeld on-premise of private clouds beschouwt, dan blijkt dat je met alleen 'kennis op CCNP-niveau' er niet komt.
Naast netwerken ā hoewel dit een eindeloos veld is om te bestuderen, zelfs als je je alleen op Ć©Ć©n richting concentreert (providernetwerken, enterprise, datacenters, wifi...)
Natuurlijk zullen velen van jullie nu aan Python en andere 'network automation' denken, maar dit is slechts een noodzakelijke, maar niet voldoende voorwaarde. Om als netwerktechnicus 'succesvol in het team te integreren', moet je in staat zijn om met zowel ontwikkelaars als collega-systeembeheerders/devops'ers dezelfde taal te spreken. Wat betekent dat?
- Niet alleen in staat zijn om als gebruiker in Linux te werken, maar het ook te beheren, al is het maar op het niveau van een junior systeembeheerder: de benodigde software installeren, een gecrashte service opnieuw opstarten, een eenvoudige systemd-unit schrijven.
- Begrijpen (althans in grote lijnen) hoe de netwerkstack in Linux werkt, hoe netwerken zijn opgebouwd in hypervisors en containers (lxc / docker / kubernetes).
- Natuurlijk moet je kunnen werken met ansible/chef/puppet of een ander SCM-systeem.
- Een apart punt is het vermelden van SDN en netwerken voor privƩclouds (bijvoorbeeld TungstenFabric of OpenvSwitch). Dit is nog een enorm gebied van kennis.
Kortom, ik heb de typische T-shape specialist beschreven (zoals het tegenwoordig gaat). Het lijkt misschien niets nieuws, maar uit ervaring tijdens sollicitatiegesprekken kunnen niet alle netwerktechnici met kennis van ten minste twee onderwerpen uit de bovenstaande lijst pronken. In de praktijk bemoeilijkt het gebrek aan kennis van 'verwante gebieden' niet alleen de communicatie met collega's, maar ook het begrip van de eisen die het bedrijf aan het netwerk stelt als de meest laagdrempelige infrastructuur van het project. Zonder dit begrip wordt het moeilijker om je standpunt onderbouwd te verdedigen en het aan het bedrijf 'verkopen'.
Aan de andere kant geeft de gewoonte om 'te begrijpen hoe het systeem werkt' netwerktechnici een groot voordeel ten opzichte van verschillende 'breed inzetbare specialisten' die alleen over technologieƫn weten uit artikelen op Habra/Hacker Medium en chatgroepen in Telegram, maar geen idee hebben op welke principes bepaalde software werkt. En zoals bekend, vervangt kennis van bepaalde patronen met succes een gehele hoop feiten.
Conclusies, of gewoon TL;DR
- Een netwerkspecialist (net zoals een DBA of VoIP-engineer) is een specialist met een vrij smal profiel (in tegenstelling tot systeembeheerders/devops/SRE), waarvan de noodzaak niet onmiddellijk ontstaat (en soms lang uitblijft). Maar als de behoefte er eenmaal is, kan het moeilijk zijn om deze te vervangen door externe expertise (outsourcing of gewone breed opgeleide beheerders die āook nog eens de netwerken in de gaten houdenā). Wat nog zorgwekkender is, is dat de vraag naar dergelijke specialisten laag is, en in een bedrijf met 800 programmeurs en 30 devops/beheerders kunnen er slechts twee netwerkspecialisten zijn die hun taken uitstekend uitvoeren. Dit betekent dat de markt vrij klein is geweest en nog steeds is, en dat voor een goed salarisānog kleiner.
- Aan de andere kant moet een goede netwerkspecialist in de moderne wereld niet alleen netwerken kennen (en weten hoe ze geconfigureerd kunnen worden geautomatiseerd), maar ook begrijpen hoe besturingssystemen en software die op deze netwerken draaien ermee samenwerken. Zonder deze kennis zal het uiterst moeilijk zijn om te begrijpen wat je collega's van je vragen en om (gegronde) wensen/vereisten aan hen over te brengen.
- Er is geen cloud, het is gewoon de computer van iemand anders. Je moet begrijpen dat het gebruik van openbare/private clouds of diensten van hostingproviders 'die alles voor jou regelen' niet wegneemt dat jouw applicatie nog steeds netwerken gebruikt, en problemen daarmee de werking van jouw applicatie zullen beĆÆnvloeden. Jouw keuze is waar het kenniscentrum zal zijn dat verantwoordelijk is voor het netwerk van jouw project.
Bron: habr.com
