całkiem niedawno Piotr Jabłoński, jeden z najlepszych architektów i konsultantów w Cisco Systems poprowadził sesje na podobny temat w trakcie naszego polskiego klubu CCIE. zupełnie niezależnie, na Forum CCIE.pl temat wraca regularnie, a Mirek Burnejko poprosił o parę słów w kontekście whitebox networkingu.

czy SDN oznacza konieć świata dla CCIE?

i tak i nie.

zdefiniujmy na poczet tej dyskusji co to w ogóle jest SDN, bo jak wiadomo, definicji jest dosyć dużo - nie jest to technicznie precyzyjny termin. na poczet tej dyskusji założę, że SDN to:

Software Defined Network - architektura zapewniająca fizyczne oddzielenie warstwy kontrolnej (ang. control plane) od warstwy przekazującej dane (ang. forwarding plane), w której warstwa kontrolna steruje wieloma urządzeniami

oczywiście ta definicja jest daleko niedoskonała, ale rysuje pewien trend - mówiąc o SDN mamy na myśli rozwiązanie lub architekturę, w ramach której programowalność (i automatyzacja) wynikła z bliskiej współpracy między aplikacjami (oprogramowaniem) a siecią (w ogólności - sprzętem, oprogramowaniem) pozwala efektywnie wpływać na to, jak sieć działa (jakie usługi świadczy, zgodnie z jakimi politykami, etc).

popatrzmy zatem bliżej na mój punkt widzenia w temacie.

po pierwsze SDN nie jest niczym nowym - jest ewolucją w stronę zbliżenia świata programistów (odpowiedzialnych za aplikacje i ich interakcję ze światem zewnętrznym) i inżynierów sieciowych (odpowiedzialnych za działanie infrastruktury sieciowej i utrzymanie polityk nią rządzących). o ile często powtarza się, że SDN nie jest niczym nowym bo ’takie rozwiązania już istniały’ nie jest to do końca prawda - o ile koncepcja oddzielenia warstwy kontroli od warstwy przekazywania danych dla systemów rozproszonych faktycznie była tworzona i odkrywana już wielokrotnie (choćby switching IP ponad ATMem pokazany światu przez firmę Ipsilon przed tag switchingiem czyli poprzednikiem MPLSu, ATM z koncepcją zestawianych kanałów przez - potencjalnie - centralny punkt w sieci, czy w końcu architektura urządzeń modularnych, w których karta sterująca nadzoruje i programuje pracę wielu kart liniowych przekazujących ruch), o tyle do tej pory brakowało cały czas łatwego mechanizmu do oprogramowania tych interakcji. rozwiązania były firmowe, zamknięte a już w szczególności praktycznie niezrozumiałe nawet dla wysokiej klasy specjalistów.

powstała w 1996 roku i stworzona - jak zwykle w przypadku takich ‘ciekawych’ nazw - przez Gartnera koncepcja Service Oriented Architecture mówiła o współdzieleniu mechanizmów i aplikacji pomiędzy silosami - składającymi się tradycyjnie ze sprzętu sieciowego, komputerów/serwerów (zasobów obliczeniowych) i zasobów do przechowywania danych (ang. storage). echa tej architektury odnaleźć można potem w działaniach usług profesjonalnych IBMa, czy architekturze Application Oriented Networking Cisco - zbliżały one świat aplikacji i sieci, ale nadal posługiwały się natywnymi dla danego języka/aplikacji interfejsami. SDN wprowadza wspólny mianownik - separację interfejsów (API) pomiędzy węzłami sieciowymi a aplikacjami (kontrolerem, agentem - czymkolwiek w świecie ‘programowym’).

zatem nowość, oprócz otworzenia interfejsu dla programistów w dużo bardziej strawnej formie, stanowi skala na jaką wiele podmiotów zaangażowanych w budowanie środowisk - zarówno aplikacyjnych jak i sieciowych - postanowiło do koncepcji dołączyć. w tym sensie, jako certyfikowani inżynierowie i specjaliści od architektur sieciowych - wnosimy konkretną wartość ze swoją wiedzą i doświadczeniem ponieważ interfejs to jedno, a logika tego co interfejs robi - to już zupełnie inne zagadnienie.

z tej perspektywy można powiedzieć, że model SDN ma trzy warstwy:

  • należąca do producentów fizycznego sprzętu, z interfejsami północnymi (ang. northbound) w stronę warstwy abstrakcji; od starego dobrego SNMP przez protokoły takie jak NetConf (z uwielbianym dzisiaj przez wszystkich modelem Yang), BGP LS, PCEP i paroma innymi
  • warstwy abstrakcji dostarczanej dzisiaj po prostu jako zbiory API - OnePK z Cisco to jeden z przykładów, ale znajdziecie ich więcej
  • trzecia warstwa to ulubione przez wszystkich ‘kontrolery’ SDN, czyli twory takie jak Ciscowy APIC, Juniperowy Contrail czy otwarty i wygląda na to, że dzisiaj najszerzej adoptowany w rozwiązaniach SDNowych OpenDaylight (wymodelowany zresztą na bazie Cisco OnePK).

parafrazując znane powiedzenie - czy trzeba być CCIE żeby to zrozumieć? nie, ale to bardzo pomaga. czy to oznacza, że zapotrzebowanie na wiedzę CCIE będzie nadal tak duże jak do tej pory? zaryzykowałbym nawet stwierdzenie, że będzie rosło - ilość rozwiązań budowanych dzisiaj jest ogromna, choć oczywiście nie wszystkie kończą się komercyjnym sukcesem. trzeba jednak pamiętać, że otworzenie interfejsów znakomicie ‘spłaszczyło’ świat sieciowy - nie musisz już być bardzo bogatym przedsiębiorcą, żeby móc pobawić się dużym środowiskiem sieciowym - możesz uruchomić je na własnym laptopie. zdobycie wiedzy jest zatem prostsze, a oprogramowanie interakcji między aplikacjami a siecią - przestało być zarezerwowane dla firm z dużym kapitałem.

po drugie, ewolucja jest naturalna. mam dzisiaj dwa CCIE i CCDE, ale nie wyobrażam sobie zatrzymania się z tą wiedzą w miejscu. widzę wokół masę kolegów (i dużo mniej koleżanek!), którzy uznali że po zdaniu CCIE należy im się duża pensja i to wszystko co będą robić w życiu. tacy ludzie po 2-3 latach tracą wiedzę praktyczną, a po 5-6 przestają mieć wartość dla rynku w tej specjalizacji. często wybierają rolę managerów (sam nim jestem!) ponieważ technicznie posiadają już tylko ogólną, szczątkową wiedzę. nie znam dzisiaj biegle Pythona (ale uczę się!), ale znam Perl, C++, potrafię pisać skrypty w powłoce i doskonale zdaje sobie sprawę, że żeby rozmawiać z ludźmi odpowiedzialnymi za utrzymanie infrastruktury (tzw. DevOpsi, czyli ludzie łączący odpowiedzialność za sieć i aplikacje), muszę poruszać się dobrze po kwestiach aplikacyjnych. tak jak rozumiem, że stos TCP/IP działa tak czy inaczej i wiem co to jest PMTUD, tak muszę wiedzieć, że aplikacja pracuje transakcyjnie (MySQL), ma konkretne wymagania co do opóźnień i jitteru (głos), albo jest po prostu fatalnie napisana. muszę wiedzieć, jak pracują aplikacje na smartfone’ach, a jak aplikacje używane przez użytkowników laptopów z ciężkim interfejsem po stronie stacji roboczej - wszystko w kontekście tego, jak sieć musi się z ich ruchem obejść i jakie problemy mogą się pojawić.

innymi słowy, tzw. DevOpsi, którzy łączą w sobie umiejętności sieciowe i programistyczne zabiorą zarówno sieciowcom jak i programistom dużo, ale nie wszystko. CCIE pracujący w roli DevOpsa będzie miał naturalną przewagę nad swoim kolegą, który jest ‘po prostu CCIE’ ponieważ ma szerszą wiedzę i zdobywa doświadczenie na wielu frontach. z drugiej strony CCIE nadal może pogłębiać swoją wiedzę i będą firmy i sytuacje, w których ta wiedza będzie po prostu bezcenna. czy oznacza to mariaż CCIE z programowaniem? nie sztywny, ale zaryzykowałbym stwierdzenie, że konieczny. wiedząc jak działa LDP oraz BFD wiedza jak dokompilować kolejną bibliotekę dla aplikacji żeby sieć mogła wykorzystać ścisłą integrację z aplikacją nie jest konieczna, ale operacyjnie będzie bardzo przydatna. i coraz częściej pracodawcy po prostu będą o to pytać.

po trzecie, SDN przyniósł nam ogromne odświeżenie spojrzenia na to, co robimy i jak robimy w sieciach. przyniósł nam whitebox networking, który odciął część profitów tradycyjnych dostawców sieci, przyniósł nam otwarte platformy do prawdziwej integracji między siecią a aplikacjami. czy wywrócił wszystko do góry nogami? nie, ale przesunął nas o dwa kroki do przodu i jeden do tyłu. część ludzi spędzi parę kolejnych lat wynajdując od nowa sieci nakładkowe (ang. overlay networks, w tym VLANy, MPLS, TRILL/FabricPath i tak dalej), część dorobi się pieniędzy konsultując co i jak przenosić “do chmury” a czego nie, już pojawiła się rola ‘architekta SDN’ - można spędzić kolejne 10 lat doskonale żyjąc na fali tego wspaniałego zjawiska. ale czy można pójść pod prąd i całkowicie je zignorować? nie, ponieważ jak pisałem w punkcie drugim - wiedza, którą dzisiaj można zdobyć rozwijając się, za 3-4 lata będzie po prostu progiem wejścia do szerszego świata sieciowego. z drugiej strony, zrobiliśmy krok do przodu, wypłaszczając pole gry - na swoim laptopie możecie dzisiaj zasymulować bardzo dużą sieć, a potem sprawdzić, jak przy różnych ustawieniach zachowywać się będą aplikację. zagadnienia zarezerwowane do tej pory dla bardzo drogich zestawów aplikacji i symulacje zabierające tygodnie można dzisiaj zrealizować w zaciszu swojego pokoju, korzystając z dobroci jaką daje moc obliczeniowa nowych procesorów oraz rozwój integracji między wirtualizowaną siecią a aplikacjami. już dzisiaj część z Was zdobyła certyfikat CCIE korzystając tylko ze środowisk wirtualnych - legendarnego dynamipsa, czy też innych platform wirtualizacyjnych.

jestem pełen optymizmu. SDN to krok w stronę skrócenia pętli między programistami i ich aplikacjami, a inżynierami sieciowymi i ich urządzeniami. zrobimy po drodze dużo błędów (część już zrobiliśmy, wystarczy popatrzeć gdzie jest dzisiaj OpenFlow), ale z drugiej strony - już dzisiaj widać, że było warto. ja zabieram się zatem za recertyfikację :)