POIT #059: Software-defined networking

Witam w pięćdziesiątym dziewiątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest Software-defined networking.

Dziś moim gościem jest Krzysztof Wróbel – lider projektów i zespołów w IT. Doświadczony programista z obszaru emedded i automatyzacji testów. Osoba pracująca z liderami technicznymi. Odpowiedzialny za całościowe dostarczanie projektów. Pracował m. in. w Samsungu. Od 1,5 roku dyrektor techniczny w CodiLime. W wolnym czasie uczy dzieci programowania.

W tym odcinku o sieciach SDN rozmawiamy w następujących kontekstach:

  • czym jest SDN i w jaki sposób łączy świat sieciowy z programowaniem?
  • czym Software-Defined Networking różni się od tradycyjnego podejścia?
  • czy SDN ma jakiś wpływ na bezpieczeństwo sieci?
  • czym jest NFV (Network Function Virtualization)?
  • czym jest edge computing?
  • jakie są wady i zalety sieci SDN?
  • kto i w jakich zastosowaniach korzysta z Software-Defined Netowrking?
  • jakich technologi, frameworków i języków programowania się używa?
  • jak wygląda codzienna praca programisty SDN?
  • w jaki sposób testuje się takie rozwiązania?
  • czy SDN funkcjonuje na polskim rynku?

Zniżka na kurs „Lider IT – Szkolenie Online”:

Adrian Sasin, gość 58. odcinka podcastu wystartował właśnie z kursem „Lider IT”. Jest to kurs dla osób, które niedawno zostały lub planują zostać managerami i liderami w IT. Adrian ma bardzo duże doświadczenie i wiedzę, którą dzieli się w tym kursie. Bardzo polecam!

Kurs można kupić na stronie https://szkolakierownikow.pl/kurs, a z kodem POIT10 otrzymasz 10% rabat!

Subskrypcja podcastu:

Linki:

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 59. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o Software-Defined Networking i alternatywnej ścieżce rozwoju dewelopera, związanej z sieciami SDN. 

Przypominam, że w poprzednim odcinku rozmawiałem o wyzwaniach w przejściu od roli specjalisty w IT do roli managera. 

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/59 

Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty będę to robił z sukcesem. 

Nazywam się Krzysztof Kempiński i życzę ci miłego słuchania. Odpalamy!

 

Cześć! Mój dzisiejszy gość to lider projektów i zespołów w IT. Doświadczony programista z obszaru embedded i automatyzacji testów, osoba pracująca z liderami technicznymi, odpowiedzialny za całościowe dostarczanie projektów. Pracował m.in. w Samsungu. Od 1,5 roku dyrektor techniczny w CodiLime. W wolnym czasie uczy dzieci programowania. Moim i Waszym gościem jest dzisiaj Krzysztof Wróbel. Cześć Krzysztofie, bardzo miło mi gościć cię w podcaście!

 

Cześć Krzysztofie, bardzo miło mi, że zostałem zaproszony. 

 

Dziś rozmowa dwóch Krzysztofów [śmiech]. Z Krzysztofem porozmawiamy dzisiaj tak naprawdę o dwóch tematach. Pierwszy to Software Defined Network, czym one są i drugi, alternatywna ścieżka rozwoju dewelopera, która właśnie z tego typu sieciami jest związana. 

Okej. Zacznę od tradycyjnego pytania, które zawsze u mnie się pojawia, czyli czy słuchasz podcastów? Jeśli tak, to jakich najczęściej? 

 

Tak, słucham podcastów. Na pewno słucham Porozmawiajmy o IT, z tego względu, też przygotowałem się do odpowiedzi, bo wiedziałem, że będziesz o to pytał. Zrobiłem sobie listę i na liście jest ich około 14, więc sporo, ale jeśli miałbym wymienić tak szybko, to Biznes w IT, Mała Wielka Firma, Manager Plus — chyba od tego podcastu w ogóle zaczynałem. Porządny Agile jest też bardzo fajnym podcastem, polecam. Greg Albrecht Podcast też bardzo ciekawy. To takie około biznesowe, około zarządzania, ale też bardziej techniczne, na przykład DevEnv czy też DevTalk Macieja Aniserowicza. Z zachodnich podcastów, obcojęzycznych The Python Podcast czy też Syntax na przykład, z web developmentu. Również zbliżone do naszej dziedziny, czyli Cloud Cast albo Packet Pushers też bardzo ciekawe, aczkolwiek odbiegające już od programowania. 

 

Bardzo fajna lista! Dobrze, to może spróbujemy przybliżyć tę dziedzinę, branżę, w której od pewnego czasu jesteś, w której się specjalizujesz. Powiedz proszę, czym jest Software Defined Network, czyli SDN. W jaki sposób łączy on programowanie ze światem sieciowym, kto zapoczątkował ten kierunek, jakie istnieją warianty sieci? Gdybyś mógł przybliżyć nam tę dziedzinę! 

 

Przede wszystkim należy zacząć od skrótu Software Defined Networking, czyli Sieć Definiowana poprzez Programowanie albo Programowalna. Tu jest właśnie duży problem — dzisiaj jako SDN-y rozumie się bardzo wiele rzeczy, ale to hasło pojawiło się po raz pierwszy chyba przy pracy doktorskiej Martina Casado, bardzo ciekawego człowieka właśnie, pracującego w tym obszarze, który napisał swoją pracę doktorską na Uniwersytecie w Stanford. I tak naprawdę chyba jego możemy uważać jako takiego twórcę tego terminu. 

 

Zgodnie z tym, jak on zdefiniował te SDN-y, to tak naprawdę jest rozdzielenie… Teraz będzie parę trudniejszych słów: rozdzielenie Control Plane’u od Forwarding Plane’u, takich dwóch płaszczyzn w urządzeniach sieciowych. 

 

Założenie jest jeszcze takie, że taki jeden Control Plane zarządza wieloma urządzeniami. Teraz właśnie może warto byłoby powiedzieć, czym jest ten Control Plane, czym jest Data Plane albo Forwarding Plane. Control Plane to jest tak jakby mielibyśmy posłużyć się jakąś metaforą, to jest mózg sieci. To jest ta część urządzenia sieciowego, która komunikuje się poprzez różne protokoły routingowe, poprzez narzucanie pewnych polityk i konfiguracji wrzucanych przez administratorów sieciowych do takich urządzeń i to ona decyduje tak naprawdę, co robi ta druga część. Czyli Data Plane, a Data Plane to jest nic innego jak tylko przesyłanie pakietów od urządzenia do urządzenia. Właśnie to, co SDN robi inaczej w stosunku do tego, co było kiedyś, to rozdziela te dwie rzeczy bardzo wyraźnie i jedną z tych części centralizuje. Umieszcza ten Control Plane w jednym miejscu, jako oprogramowanie działające na jakichś generycznych serwerach.

 

Natomiast Data Plane pozostaje po stronie urządzeń. Urządzeń rozsianych po całej sieci. To są routery, to są switche. Właśnie zadaniem tego Control Plane’u jest takie wysterowanie tymi urządzeniami, takie narzucenie polityk, którymi one się kierują, przy przesyłaniu pakietów, żeby one docierały do miejsca docelowego, urządzenia docelowego w jak najkrótszym czasie, zachowując pewne ograniczenia co do bezpieczeństwa i różnego tego typu polityk. 

Nie wiem, czy jakoś wyraźnie w miarę to pokazałem, bo pewnie łatwiej byłoby narysować. 

 

Jak najbardziej. Chciałbym cię jednak jeszcze dopytać w tym wątku. Powiedziałeś mniej więcej, jaka jest podstawowa różnica w stosunku do tradycyjnego podejścia do tradycyjnych architektur sieciowych. Chciałbym cię natomiast zapytać, jakie są jeszcze inne różnice, bo tez z tym wiąże się pytanie: po co sieci tego typu zostały wymyślone, jaka potrzeba, może jaki brak wpłynął na to, że sieci tego typu powstają? Dlaczego tradycyjne podejście jest, czy było, niewystarczające? 

 

Wydaje mi się, że ta oryginalna potrzeba wzięła się prawdopodobnie z dużych firm, które zarządzały dużymi jednostkami albo centrami danych. Czyli jakimś bardzo dużym zbiorem serwerów, które muszą się ze sobą komunikować, żeby tworzyć tę chmurę, która dla nas jest widoczna jako abstrakcja. 

 

Wydaje mi się, że były dwie takie potrzeby. Z jednej strony to technicznie bardzo trudno jest nadążać za administracją pojedynczych urządzeń, w związku z tym, mając jedno scentralizowane miejsce, gdzie definiujemy sobie pewne polityki, według jakich urządzenia te mają działać, mamy rozwiązany problem tego, że musimy się logować na każde z tych urządzeń z osobna, konfigurować, być może kiedyś za pomocą jakiegoś Command Line Interface, czyli logowania się po prostu poprzez terminal do konsoli każdego z urządzeń, to jest jedna rzecz. Czyli możemy to robić z jednego miejsca za pomocą scentralizowanych, że tak powiem, polityk zarządzanych centralnie. 

 

Z drugiej strony jednak dzisiaj jako SDNy rozumie się nie tylko według tej klasycznej definicji, jak mówiliśmy wcześniej, rozdzielenie tego Control Plane’u, ale chyba trochę hype spowodował, że zaczęliśmy podciągać pod to hasło tak naprawdę też inne rozwiązania, typu SD WAN czy NFV na przykład. Takie hasła też się pojawiają. Taki SD WAN z kolei to jest problem tego, że mamy wiele różnych sieci lokalnych, rozproszonych. po całym świecie, po całym kraju i problem też jest, czy w takim razie musimy zatrudniać administratora sieciowego do każdej z tych sieci lokalnych? To jest kolejny problem, który te rozwiązania rozwiązują. Możemy sobie zdalnie zarządzać sieciami lokalnymi, dbać o ich bezpieczeństwo, a z drugiej strony te rozwiązania typu SD WAN na przykład powodują, że z punktu widzenia urządzeń podłączonych do naszej jednej sieci lokalnej, wszystkie pozostałe urządzenia są widoczne tak jakby w tej sieci lokalnej były, nawet jeśli oddzielają nas od nich trzy kolejne sieci bądź też Internet. To są więc chyba główne problemy, które SDNy rozwiązują. 

 

Czyli mówisz, że takie typy sieci — znaczy, mówisz, że nie są to do końca typy SDN, tylko ogólnie rodzaje sieci typu SD WAN czy SD LAN dajmy na to. Tak de facto  nie do końca podchodzą pod tę definicję, jeśli dobrze zrozumiałem. Trochę próbują się ogrzać w ciepełku tej definicji SDN, natomiast nie do końca podpadają pod tego typu definicje sieci. Dobrze to zrozumiałem? 

 

Tak, jeśli mielibyśmy być tacy bardzo precyzyjni, to one nie podpadają. To jest tak jak z różnego rodzaju hasłami, dzisiaj wszyscy są agilowi, a jest pewien zbiór punktów, który to definiuje, nawet jeśli nie spełniamy wszystkich, albo czujemy, że idziemy w duchu tych haseł, zasad, które są tam spisane, to mówimy, że jesteśmy agile. Tutaj — w porządku — z jednej strony to jest być może trochę wygrzebanie się przy tych dużych projektach i wykorzystywanie tego hype’u. Z drugiej strony wydaje mi się, że ten kierunek SDN-owy właśnie spokojnie możemy rozszerzyć na wszelkie innego typu rozwiązania, gdzie coraz więcej jest uwalniania się od specjalistycznego sprzętu, od firm, które tworzą rozwiązania zamknięte w stronę takiego otwartego oprogramowania i oprogramowania, które może być wykorzystywane generycznie. To powoduje, że mamy bardzo dużo różnych zalet tego typu podejścia. 

 

Tak, jak powiedziałeś, że te rozwiązania typu SD WAN, czy też NFV, one być może nie podpadają pod tę definicję, ale uważam, że są bardzo fajnym kierunkiem, w którym to wszystko zmierza.

 

Jasne. Tak sobie myślę, że to, co powiedziałeś, że dajmy na to, na te różne urządzenia sieciowe przy SDNie, można wgrywać te wszystkie konfiguracje w sposób zdalny, nie trzeba już w jakiś sposób logować się do każdego urządzenia i konfigurować jak gdyby per urządzenie, to m.in. może wpływać na to, że bezpieczeństwo przesyłu informacji w takiej sieci może być zwiększone. Czy mówi się o takim zagadnieniu, czy to jest faktycznie coś, z czym mamy do czynienia? Czy w sieciach SDN powiedzmy, można mówić o zwiększonym bezpieczeństwie przepływu danych?

 

Wydaje mi się, że możemy na pewno mówić o zwiększeniu bezpieczeństwa, ale równocześnie też zmniejszeniu w innych aspektach tego bezpieczeństwa. 

 

Przez to, że jesteśmy właśnie elastyczni, że możemy w bardzo szybki sposób, wręcz automatyczny, rekonfigurować taką sieć, izolować pewne fragmenty tej sieci, przekierowywać ruch poprzez inne urządzenia i trasy, co wcale nie byłoby takie łatwe, gdyby nie ta decyzja o tym, jak jest kierowany ruch, była podejmowana zbiorczo przez każde z urządzeń, ponieważ tam czas propagacji, że tak powiem, te informacje, które z urządzeń jest zainfekowane, albo która ze ścieżek powinna być pominięta i tak dalej. 

 

Tutaj mamy te informacje od ręki, w jednym miejscu, więc możemy sobie w bardzo fajny sposób pracować różnego rodzaju algorytmami, które będą sprawnie i szybko reagowały i aplikowały te nowe polityki już w sieci. Coś, co byłoby trudne i czasochłonne do wykonania człowiekowi manualnie. Tu na pewno mamy zwiększenie bezpieczeństwa. Z drugiej strony jednak, mamy też ten jeden punkt, który jest podatny na awarie, jeden, który jest podatny na ataki, czyli ten kontroler. Kontroler to jest tak naprawdę nic innego, jak zbiór usług, aplikacji działających na generycznych serwerach i wtedy jeden punkt ataku może zabić całą sieć. Jeśli jesteśmy w stanie przejąć taki kontroler, mamy właściwie całą sieć. 

 

Z drugiej strony bronimy się w jednym miejscu, a nie na wszystkich urządzeniach z osobna. Ten kontroler musi też komunikować się z tymi urządzeniami sieciowymi, którym narzuca te różne konfiguracje, polityki i tutaj też może być jakiś atak man in the middle może dojść do tego typu ataków, gdzie jesteśmy w stanie też zmienić konfigurację każdego z urządzeń. 

 

Same te urządzenia też potrzebują ciągłej komunikacji z kontrolerem, więc jesteśmy w stanie zainfekować lub zaatakować te urządzenia, to też może być niebezpiecznie. Jak to w życiu bywa — nigdy nie jesteśmy w stanie znaleźć jakiegoś super rozwiązania. Wydaje mi się jednak, że to są problemy, z którymi potrafimy sobie już w jakiś sposób radzić. To są problemy, które dotyczą dzisiaj praktycznie większości systemów i rozwiązań aplikacyjnych.

 

Pewnie. Jak to właśnie powiedziałeś, jak to w życiu — nie ma nic za darmo, a czasem trzeba wybrać mniejsze zło. 

Okej. Chciałbym zapytać cię o kwestię, której trochę powiedziałeś. Z SDNami wiąże się jeszcze koncept takiej architektury sieciowej, nazywanej NVF, prawda? Czyli Network Function Virtualization. Powiedziałeś, że to nie do końca wpasowuje się być może w definicję SDN, ale często w różnych artykułach, blogach itd., gdzieś te dwa pojęcia leżą blisko siebie.

Mógłbyś pokrótce powiedzieć, czym jest ten koncept, w jaki sposób wiąże się z SDNami właśnie? 

 

Tak. Mówiąc wprost, NFV, to jest wirtualizacja funkcji sieciowych. Funkcje sieciowe typu Firewall, typu szyfrowanie, deszyfrowanie wysyłanych treści, pakietów. Usługi typu NAD, DNS, jakieś cachowanie w sieciach. Coś, co nadal jest realizowane za pomocą fizycznych urządzeń. Oczywiście, na tych fizycznych urządzeniach też działa software, ale do tej pory były realizowane jako niezależne, oddzielne funkcje, dostarczane przez wyspecjalizowane w rozwiązaniach firmy. 

 

Powodowało to dużo problemów. Po pierwsze, taki sprzęt jest o wiele droższy. Po drugie, jest dużo mniej elastyczny, bo nagle okazuje się, że aby zmienić albo dołożyć trzeba po prostu dołożyć kolejne urządzenie ze swojej szafy rackowej. Zwiększenie poboru energii, tego typu problemy. 

 

Natomiast idea jest taka, żeby zamiast używania takiego specjalistycznego sprzętu, dobrać generyczny serwer i na nim tak naprawdę postawić jakieś serwisy, usługi, realizowane czysto programowo. Dzięki temu możemy sobie dowolnie dodawać kolejne usługi, dowolnie je skalować, możemy w łatwy sposób aktualizować ich wersje, dodawać całe funkcje do nowych sieci. Jest to więc bardzo fajny koncept. 

 

Natomiast idea jest taka, żeby zamiast używania takiego specjalistycznego sprzętu, dobrać generyczny serwer i na nim tak naprawdę postawić jakieś serwisy, usługi, realizowane czysto programowo. Dzięki temu możemy sobie dowolnie dodawać kolejne usługi, dowolnie je skalować, możemy w łatwy sposób aktualizować ich wersje, dodawać całe funkcje do nowych sieci. Jest to więc bardzo fajny koncept.

 

Znowu mamy też słabsze strony tego rozwiązania: czasem jest to kwestia wydajności. To jest chyba jedne z większych problemów, ale też z drugiej strony taki czysto ludzko — procesowy, bo jednak włożenie nowego urządzenia do szafy rackowej, wpięcie kilku przewodów, to jest takie bardzo namacalne. Łatwe do zrozumienia. Zainwestowaliśmy pieniądze, w ostateczności przerobimy na szafkę. 

 

Natomiast tutaj, gdy mamy to zwirtualizowane, jednak trudniej się tym zarządza. Trudniej i łatwiej: trudniej z punktu widzenia tego, że nie jest to namacalne, trzeba więc znaleźć też trochę innych ludzi, którzy będą to instalowali, którzy będą się tym opiekowali. Tutaj dużo bardziej złożony jest ten koncept, w związku z czym to też wymaga trochę zmiany podejścia. Jednak bardzo fajna rzecz, szczególnie gdy nagle sobie uzmysłowimy, że mamy jedną z usług zwirtualizowaną, uruchamianą na jakimkolwiek serwerze, no to nagle możemy dołożyć trzecią, czwartą i możemy spostrzec, że właściwie nigdzie nie ma żadnego przewodu. Tak zwany service chaining, możemy łączyć sobie fajnie te usługi ze sobą, możemy dynamicznie przełączać ruch między jedną tego typu usługą a drugą. Jest całe mnóstwo możliwości przed tego typu rozwiązaniami.

 

No właśnie, gdy czytałem sobie o tym koncepcie, to znalazłem, że w połączeniu z SDN-em, może to być używane to tak zwanego edge computingu. Mógłbyś powiedzieć, czym jest edge computing i do czego służy? 

 

Tu też edge computing dość szeroko może być rozumiany, to też jest jeden z naszych dzisiejszych base wordów, który mocno chwyta. 

 

Tak jak powiedziałeś — przy zastosowaniu NFV, nagle okazuje się, że możemy przenieść przetwarzanie bądź też przechowywanie pewnych danych bliżej klienta i możemy zrobić to zdalnie i automatycznie. Edge computing może być rozumiany jako kamera internetowa, która ma funkcje wytwarzania obrazu i wykrywa ruch albo też osoby znajdujące się w kadrze, ale z drugiej strony to może też być w przypadku operatorów sieciowych przerzucenie usługi firewalla na przykład, czyli takiej zapory ogniowej, na stronę infrastruktury klienta. Może to być zarządzane przez tego operatora. Możemy też takie szyfrowanie, deszyfrowanie także przerzucić bardzo blisko klienta — tutaj też zwiększamy bezpieczeństwo. 

 

Dane mogą być szyfrowane najbliżej źródeł. Dzięki temu możemy również zmniejszyć latency, czyli opóźnienia w komunikacji. Jaki jest sens przesyłania danych, które miały być zaszyfrowane gdzieś tam daleko, na centralny serwer, umieszczony gdzieś w data centre Google’a, jak możemy część z tych operacji wykonać już blisko klienta. Generalnie fajna rzecz: elastyczność i to jest możliwe tylko dzięki temu, że pewne funkcje możemy mieć zwirtualizowane. Wysyłanie paczką, kurierem urządzenia sieciowego do klienta też wchodziłoby w grę, ale jednak trochę bardziej problematyczne. 

 

Powiedziałeś mniej więcej, czym są sieci SDN. Zastanawiam się, jakie są wady i zalety, bo na pewno taki i takie są. Tutaj zarówno od strony technicznej, jak i biznesowej, czym się charakteryzują pozytywnie i negatywnie sieci tego typu? 

 

Pewnie gdzieś już o tym mówiliśmy wcześniej — na pewno jest to szybsze i pewniejsze wdrażanie tych zmian. W momencie, gdy mamy wszystko w jednym miejscu możemy w bardzo łatwy sposób aktualizować sobie polityki tych sieci, konfiguracje i tak dalej. Te programowalne elementy sieciowe pozwalają nam też wdrażać bardzo szybko nowe funkcje. Podsumowując: większa elastyczność, mniejsze koszty operacyjne, ale być może też inwestycyjne. 

 

A z punktu widzenia stricte funkcjonalnego, bardzo fajny case przerabialiśmy jakiś czas temu. On jest też dostępny publicznie. Na przykład, wdrożenie systemu SD WAN, w sieci Rossmann. Wyobraźmy sobie 1200 sklepów i tylko trzech administratorów, którzy są w stanie nad tym wszystkim zapanować. Dzisiaj taki sklep to jest mnóstwo technologii. Od systemów wizyjnych, poprzez systemy kasowe, access pointy dla klientów i tak dalej, i tak dalej. 

 

Każda firma korzysta z sieci, nawet gdy nie jest tego w pełni świadoma, bo dla niej są to jakieś produkty końcowe. To też pokazuje, jak fajnie można sobie zredukować ludzkie koszty. NA pewno też jest zwiększona widoczność, tak zwana visibility tego, co się w sieci dzieje, jak ona wygląda. Coś, co musielibyśmy kiedyś odtwarzać oddolnie, bo mieliśmy mnóstwo urządzeń, które były ze sobą jakoś fizycznie połączone. Dzisiaj my wiemy odgórnie, na poziomie kontrolera, jak ta topologia wygląda. Też dużo łatwiej się o niej rozmawia, planuje. To są tego typu zalety. O wadach też mówiliśmy. To jest ten jeden punkt krytyczny.

 

Na pewno nie ma też jeszcze standardów. Mówiliśmy też o tym klasycznym SDNie i protokole Open Flow, który jest swego rodzaju standardem dzisiaj, ale tam nadal trwa, wydaje mi się walka i nie ma jednoznacznie ustalonych standardów, które byłyby zaakceptowane przez całą społeczność. No i dwa lata to jest nowa technologia, więc to wymaga naprawdę dużej zmiany po stronie mindsetu. Zmiana też ludzi, którzy do tej pory zajmowali się sieciami. Klasyczny administrator musi zdobywać coraz to nowe kompetencje, poznawać techniki, z którymi być może nie miał do czynienia, więc to jest taka duża zmiana organizacyjna, więc to jest chyba coś, co jeszcze wstrzymuje te sieci przed byciem wykorzystanymi globalnie i przez mniejsze firmy. 

 

dwa lata to jest nowa technologia, więc to wymaga naprawdę dużej zmiany po stronie mindsetu. Zmiana też ludzi, którzy do tej pory zajmowali się sieciami. Klasyczny administrator musi zdobywać coraz to nowe kompetencje, poznawać techniki, z którymi być może nie miał do czynienia, więc to jest taka duża zmiana organizacyjna, więc to jest chyba coś, co jeszcze wstrzymuje te sieci przed byciem wykorzystanymi globalnie i przez mniejsze firmy.

 

 

Okej, czyli powiedzmy, biznesowo jest to szansa na oszczędności, patrząc długoterminowo i długofalowo, dla biznesu, natomiast krótkoterminowo to jest też kwestia pozyskania odpowiednich kompetencji. Odpowiednich osób, które będą w stanie się takimi sieciami na co dzień zajmować. 

 

To może być problem, przynajmniej aktualnie. Jak powiedziałeś, technologia jeszcze świeża, więc siłą rzeczy na rynku jest mało osób, które znają się i mają doświadczenie w tej technologii. 

 

Tutaj właśnie chciałem pociągnąć ten temat. Wspomniałeś o Rossmannie jako takim przykładzie wdrożenia, które zakończyło się sukcesem. Chciałem zapytać, kto powiedzmy, pod względem jakichś branż czy typów firm wykorzystuje w tej chwili SDN, bo powiedziałeś o sporej ilości zalet tych sieci. Jednak z tego, co się orientuję, nie jest to jeszcze szeroko wykorzystywana technologia. Czy dysponujesz jakimiś przykładami, informacjami, statystykami kto, jaki jest profit firm wykorzystujących obecnie SDN?

 

Na pewno są to dostawcy chmur albo firmy, które mają swoje prywatne chmury już bardzo rozbudowane, Amazon, Facebook. Tam nie ma już innej opcji niż korzystanie z jakiejś formy właśnie softwarowego podejścia. Operatorzy telekomunikacyjni, to jest też taka duża grupa, gdzie to też powoli zaczyna wchodzić. Również to są bardzo fajne rozwiązania dla takich firm RND. które tworzą, testują różnego rodzaju oprogramowanie, rozproszone. 

 

Taka więc możliwość re-konfigurowania i centralnego zarządzania swoją infrastrukturą może pozwolić na tworzenie w łatwy sposób środowisk testowych i scenariuszy dla deweloperów, które będą próbowały odzwierciedlać środowiska produkcyjne. To też jest bardzo fajne miejsce, gdzie można byłoby z tego korzystać i niektóre firmy też właśnie z tych rozwiązań korzystają. Też jak powiedziałem, sieci sklepów, kawiarnie, jeśli chodzi o rozwiązania takie SD WAN-owe, to jest też bardzo fajny obszar, gdzie można sporo tutaj zaoszczędzić.

 

Jasne. Okej, chciałem teraz powoli przejść do takiego drugiego, wątku, który na początku zaczęliśmy jako o tematyce tego podcastu. Czyli o alternatywnej, powiedzmy, ścieżce rozwoju dewelopera. 

W tej nazwie Software Defined Networking na początku jest software. Stąd moje pytanie do ciebie: kto może tworzyć oprogramowanie przeznaczone do SDN-ów, jakie powiedzmy, kompetencje są wymagane, żeby pójść w tym kierunku, pokierować karierę? 

 

Z mojego doświadczenia, chyba wszyscy programiści. Tak jak powiedzieliśmy, ten software na poziomie kontrolera, ale też jest poziom jeszcze wyżej: poziom aplikacji, które korzystają z tego kontrolera. Dzięki niemu możemy realizować bardziej złożone usługi. 

 

To jest zwyczajna aplikacja. Taka aplikacja webowa. Frontend deweloperzy, backend deweloperzy, spokojnie odnajdą się w tej części. Jeśli chodzi o sam kontroler, to tu już bywa trochę trudniej. To są najczęściej już usługi często w architekturze mikro-serwisowej systemy realizowane, no i to już wymaga trochę tej wiedzy dziedzinowej, żeby poznać tę specyfikę, trzeba zapoznać się z różnymi, technicznymi specyfikacjami. Na przykład tego typu protokołów jak openflow. Trzeba też powoli zaczynać rozumieć protokoły komunikacyjne, routingowe, pomiędzy urządzeniami sieciowymi. Tu już się robi ciekawiej. 

 

Tak naprawdę możemy zejść jeszcze niżej, bo nigdy nie pozbędziemy się tego urządzenia fizycznego. Czyli programiści embedded też są w stanie znaleźć tutaj swoje miejsce i wykorzystać wprost swoje kompetencje. Dlatego uważam, że to jest bardzo fajna dziedzina dla programisty, z tego względu, że raz: mamy pełen przekrój, wszystkie najnowsze technologie, tego typu rozwiązania nie odbędą się bez najnowszych trendów w technologii. To jest pod tym względem ciekawe. Wydaje mi się też, że ciekawe jest to, że sama dziedzina jest techniczna, w związku z czym dla większości programistów, poznawanie tej dziedziny to już może być sporo radości i sporo ciekawych wyzwań. 

 

Jasne. Czyli z jednej strony, powiedzmy, szlifujemy swoje rzemiosło programistyczne, a z drugiej strony obracamy się w dziedzinie, która z definicji jest też techniczna, więc jak gdyby możemy swoje kompetencje wykorzystywać, albo powiedzmy, rozwijać i stąd jak rozumiem, może być to dobra właśnie ścieżka rozwoju naszej programistycznej kariery. 

 

Z tego, co powiedziałeś, dosyć szeroki jest wachlarz umiejętności, kompetencji, które są wykorzystywane podczas pracy nad tego typu projektami. Chciałem cię zapytać, w związku z tym, jak na co dzień wygląda praca z projektami właśnie w tym zakresie. Czy to się różni od pracy w Software House albo nad jakimś produktem internetowym? 

 

Nie wydaje mi się, żeby jakoś mocno odbiegała ta praca od innych projektów softwarowych, poza tym, że często product ownerami, bądź osobami definiującymi wymagania są osoby techniczne. Dużo łatwiej się dogadać programiście z osobą techniczną, ale z kolei to jest trochę trudność dla takich działów UX. 

 

Z kolei tutaj, tak jak w klasycznych aplikacjach mobilnych, czy portalach internetowych, social media i tak dalej, no to tym klientem końcowym, użytkownikiem może być każdy z nas. Tak naprawdę dużo łatwiej się rozmawia. Tutaj najczęściej w przypadku tego typu rozwiązań rozmawia się z osobami technicznymi, więc trzeba przetłumaczyć trochę w drugą stronę te wymagania i je upraszczać wyżej. To jest więc chyba taka specyfika odmienna tych projektów.

 

Wydaje mi się też, że dużo trudniejsze i o wiele więcej wyzwań sprawia testowanie tego typu rozwiązań. Właśnie tutaj wirtualizacja, też funkcji sieciowych, więc większość urządzeń ma jakąś swoją reprezentację w wirtualnym świecie, softwarową, którą można sobie uruchamiać. To testowanie nie jest łatwe, ale jest za to bardzo ciekawe, bo tutaj nie ma miejsca na testowanie manualne. Powiedziałbym, że 95% to jest testowanie automatyczne i tylko w ten sposób jesteśmy w stanie udowodnić sobie, że te nasze rozwiązania mają określoną jakość, której oczekujemy. 

 

Właśnie kontynuując jeszcze ten wątek testowania, czy CICD ma tutaj jakieś zastosowanie? I właśnie: czy nie obędzie się w pewnym momencie bez tych fizycznych urządzeń? Bo, co prawda, wirtualizacja może nam pomóc, natomiast nie raz nie odda w pełni wszystkich, powiedzmy ograniczeń czy warunków, z jakimi musimy się spotkać w momencie, w którym wychodzimy w świat rzeczywisty. Podobna sytuacja jak z testowaniem aplikacji mobilnych. Część można testować w symulatorach, ale mimo wszystko, większość firm i tak posiada spory zbiór urządzeń fizycznych i dopiero gdzieś te finalne testy są na tych urządzeniach przeprowadzane. Zastanawiam się, czy tu w przypadku sieci SDN też jest konieczność wprowadzania na którymś etapie testów na urządzeniach fizycznych, czy też można się bez tego obyć? Czy taki continuous integration, continuous deployment czy to jest coś, co ma tutaj też zastosowanie? 

 

Tak. Continuous integration, continuous deployment ma szerokie zastosowanie i nawet, z doświadczenia uważam, dużo głębsze niż klasycznego rodzaju projektach. 

 

Zdarzają się na przykład takie rozwiązania — mieliśmy taki projekt, gdzie my mieliśmy własne rozwiązanie CICD, które to rozwiązanie wdrażało inne CICD na predefiniowanej infrastrukturze i to rozwiązanie CICD wdrażało kolejne. To wygląda jak dziwne rozwiązanie, ale to miało sens. Dzięki temu wiele rzeczy się upraszczało. Automatyzacja jest powszechna przy tego typu rozproszonych, złożonych systemach i tego typu podejście powoduje, że CICD jest nie tylko podejściem ale też staje się produktem, który można wdrożyć u takiego operatora telekomunikacyjnego. To CICD jest bardzo istotne w tego typu projektach.

 

Wykonanie wszystkich testów trwa dużo dłużej niż w prostych aplikacjach bazodanowych, bo jednak trzeba testować też ten data plane, czyli tę część związaną z ruchem sieciowym. 

 

Często gra dzieje się też o wydajność. Ruch sieciowy ma się odbywać też bardzo szybko, szybko mają być przesyłane dane. Tak jak powiedziałeś — części testów nie jesteśmy w stanie wykonać tylko i wyłącznie za pomocą zwirtualizowanych urządzeń. Często jest tak, że urządzenia fizyczne są włączane do tego typu automatycznych testów, ale one z założenia są gotowe na sterowanie z zewnątrz. Z zasady są programowalne, w związku z czym tutaj jest dużo łatwiej niż innego typu urządzeniami. Tak jak wcześniej miałem do czynienia z telewizorami czy komórkami — wydaje się, że tutaj jest dużo łatwiej, bo one od początku projektowane są w ten sposób, żeby można było je w łatwy sposób programować i kontrolować. 

 

Często gra dzieje się też o wydajność. Ruch sieciowy ma się odbywać też bardzo szybko, szybko mają być przesyłane dane. Tak jak powiedziałeś — części testów nie jesteśmy w stanie wykonać tylko i wyłącznie za pomocą zwirtualizowanych urządzeń. Często jest tak, że urządzenia fizyczne są włączane do tego typu automatycznych testów, ale one z założenia są gotowe na sterowanie z zewnątrz. Z zasady są programowalne, w związku z czym tutaj jest dużo łatwiej niż innego typu urządzeniami.

 

Czyli łatwiej jest, powiedzmy, do takiego procesu CI włączyć. Ponieważ, tak jak powiedziałeś, one są z definicji przystosowane do tego, żeby je programować z zewnątrz, nazwijmy to w ten sposób. 

Okej. Jakich języków programowania, frameworku, bibliotek, technologii używa się na co dzień w pracy? Wiadomo, jeśli jest to część aplikacyjna, frontendowa – tu jest osobny stack technologiczny. Bardziej chodzi mi o tę część związaną z samą siecią — czy są jakieś języki programowania, które bardziej nadają się do takich zastosowań? 

 

Jeśli chodzi o programowanie kontrolerów, to tu jest właśnie klasyczne podejście. Tutaj więc najbardziej popularny jest Golang i Python. Wszystkie serwerowe systemy rozproszone od tego nie odbiegają. Aczkolwiek, początki SDNów to są lata ’90, więc też zdarzają się projekty kontrolerów, które były pisane w Javie. To raczej nie jest popularne w tym momencie.

 

Takim dość nowym tematem, bo wcześniej mówiliśmy, że cała walka tutaj z tymi SDN-ami to jest możliwość programowania na poziomie tego control plane’u. To, w którą stronę teraz idziemy, to jest programowanie data plane’u. Tutaj pojawiają się specyficzne języki do układów programowalnych, które możemy wykorzystać do elastycznego re-konfigurowania tego, jak ten sprzęt się zachowuje. Na przykład język P4. Bardzo ciekawa rzecz, gdzie z jednej strony trochę przypomina składniowo C, ale z drugiej strony ma bardzo rozbudowaną bibliotekę do programowania data plane’u. 

 

Po cichu obstawiałem, że wspomnisz też tę Javę, bo dziwne by było, żeby również tutaj jej nie było, ale w porządku. Powiedzmy, że Golang i Python jako takie przodujące języki programowania obecnie. 

 

Czy myślisz, że praca jako deweloper w tym obszarze to jest ciekawa ścieżka rozwoju kariery? W jaki sposób możemy, będąc programistą, pracując w SDN rozwijać się, pracując nad tego typu problemami? Bo to jest jakaś dziedzina, domena, która jest mimo wszystko wąska. Czy sądzisz, że tutaj jest możliwość na dynamiczny rozwój dla programisty, który chciałby pójść w tym kierunku? 

 

Wydaje mi się, że może dziedzina wydawać się wąska — w końcu to tylko komunikacja sieciowa. Mnogość rozwiązań jednak, które powodują, że sieci i ta cała infrastruktura może być w łatwy sposób zarządzana, konfigurowana — deployment jej i tak dalej. Tam jest więc mnóstwo takich tematów, które zahaczają o sieci, ale niekoniecznie też wymagają bardzo głębokiej znajomości każdego z protokołów komunikacyjnych na przykład. 

 

Uważam, że to jest bardzo ciekawa dziedzina, bo po pierwsze ona się rozwijała, rozwija i jeszcze długo będzie rozwijać. Tutaj nie ma odwrotu. Za chwilę będziemy mieć do czynienia z sieciami 5G, więc bez SDN-ów, bez wirtualizacji funkcji sieciowych tego nie dałoby się zrealizować, tego typu infrastruktury. Wydaje mi się więc, że jest bardzo ciekawa. Tak jak powiedziałem, sama dziedzina jest techniczna, w związku z czym wszystkie osoby, które kiedyś pracowały ze specyfikacjami technicznymi i programowały urządzenia embedded też znajdą tutaj bardzo wiele fajnych wyzwań. Uważam, że to jest bardzo fajna ścieżka, bardzo ciekawa. Mógłbym pewnie długo jeszcze mówić, ale generalnie nie widzę końca! Sam niedawno wszedłem w tę dziedzinę, wcześniej pracowałem w systemach embedded i powiem, że ja końca nie widzę. Nie widzę, gdzie można byłoby się zatrzymać, wręcz problem jest taki, w którą stronę pójść, bo jednak każda odnoga wymaga dużej specjalizacji. 

 

Uważam, że to jest bardzo ciekawa dziedzina, bo po pierwsze ona się rozwijała, rozwija i jeszcze długo będzie rozwijać. Tutaj nie ma odwrotu. Za chwilę będziemy mieć do czynienia z sieciami 5G, więc bez SDN-Fów, bez wirtualizacji funkcji sieciowych tego nie dałoby się zrealizować

 

To na pewno może być ciekawy obszar do zbadania. W momencie, kiedy zainteresowałeś się tą dziedziną i zacząłeś przechodzenie w tym kierunku, to, z jakich źródeł czerpałeś wiedzę? Co mógłbyś polecić osobom, które powiedzmy, w jakiś sposób są zainteresowane tym tematem, chciałyby ten obszar jakoś zbadać. Z jakich książek, materiałów online można skorzystać? 

 

Nie wiem, czy jestem w stanie polecić jakieś konkretne książki. Jest tego sporo na rynku. Wydaje mi się jednak, że bardzo fajnym punktem startowym jest strona ONF. To jest taka organizacja, która prowadzi bardzo ciekawe projekty. Język P4, o którym wspomniałem, to też jest ich projekt. 

 

Są również bardzo fajne rozwiązania typu mininet, gdzie można sobie takie zwirtualizowane środowisko do testowania i rozwoju takich sieci przygotować na własnym laptopie. To też jest, uważam, bardzo fajny punkt startowy. Polecam też podcasty w tym temacie. Aczkolwiek, to raczej z punktu widzenia takiego biznesowego, żeby zrozumieć, jakie problemy rozwiązujemy. 

 

Kolejne ścieżki, kolejne kroki to są specyfikacje różnego rodzaju, dostępne publicznie. Różnego rodzaju protokołów sieciowych i tego typu materiały. A najlepiej to chyba zacząć w tym po prostu pracować. 

 

Właśnie, chciałem to dodać, że chyba najlepiej w praktyce. Mimo wszystko, to zawsze tak działa, że w praktyce uczymy się najwięcej. 

 

Chciałem cię jeszcze zapytać o rolę administratora, bo wspomniałeś, że ten zestaw kompetencji, który potrzebny jest przy SDNach, w stosunku do tradycyjnych sieci może się trochę różnić. Czy to według ciebie może znaczyć, że osoby, które będą się zajmować, czy zajmują tego typu sieciami, będą musiały jak gdyby siłą rzeczy bardziej iść w kierunku programowania i znajomości protokołów, języków i tak dalej? 

 

Tak. To wydaje mi się, będzie nieuniknione na przestrzeni kilku najbliższych lat. To chyba tak naprawdę już się dzieje. Większość dzisiejszych administratorów sieciowych, oni w taki bądź inny sposób i tak automatyzują sobie już zarządzanie tego typu urządzeniami. To już się dzieje, a wydaje mi się, że będzie jeszcze bardziej istotne w przyszłości.

 

Jako CodiLime zajmujecie się właśnie tego typu rozwiązaniami. Czy takie rzeczy funkcjonują już na naszym rodzimym rynku, czy to może jest za wcześnie, na razie to jest domena bardziej rozwiniętych krajów? 

 

Często jest tak, jak ten przykład Rossmanna. Wydaje mi się, że korzystamy, nawet nie wiedząc, to na pewno. My jako firma współpracujemy raczej z dużymi twórcami tego typu rozwiązań, w związku z czym współpracujemy z działami R&D, tych firm. Takich w Polsce chyba nie ma zbyt wiele, które mogłyby sobie pozwolić na inwestycję w tego typu rozwiązanie, tworzenie ich od nowa bądź rozwijanie. Wydaje mi się więc, że tutaj, w Polsce byłoby dość trudno znaleźć takie miejsce, gdzie można byłoby bezpośrednio z tego typu rozwiązaniami pracować.

 

To wobec tego, jak według ciebie będzie wyglądała przyszłość tej branży? Jakie trendy są na dzień dzisiejszy widoczne? Co myślisz, będzie takim dominującym trendem w najbliższej przyszłości? 

 

Tak jak powiedziałem, teraz bój będzie się toczył raczej o to, żeby móc programować też tę część, która do tej pory była tylko zarezerwowana dla urządzeń, które były programowane, albo wręcz na poziomie układów cyfrowych, definiowane raz i zachowywały się w ten sam sposób przez cały swój cykl życia. 

 

Natomiast teraz chyba będzie bój o to, żeby móc już na tym poziomie fizycznym programować te urządzenia w taki sposób, żeby mogły bez wymiany samego urządzenia jako takiego, mogły zacząć obsługiwać nowe protokoły. Czy też zacząć obsługiwać protokoły wyższych warstw? Wydaje mi się, że to chyba jest taki trend, który w najbliższej przyszłości będzie najbardziej istotny, ponieważ SDNy w rozumieniu tym klasycznym… One już są. Są gotowe, to jest kwestia wdrażania ich w kolejnych firmach. Na poziomie RND, rozwoju oprogramowania, w tej chwili to właśnie chyba jest ten trend. 

 

Czyli ten język P4 może wspierać coś takiego i ogólnie układy programowalne, typu FPGA, które z szybkością sprzętu i na poziomie bramek logicznych są w stanie przetwarzać dane. Z drugiej strony mogą być w dowolnym momencie przeprogramowane. To chyba jest ten trend na najbliższe lata.

 

Fajnie! Jest to bardzo ciekawa dziedzina, muszę powiedzieć i dla osób, programistów, którzy myślą o rozwoju swojej kariery, a także pracę w domenie, która jest techniczna, myślę, że jest to świetny kierunek. Krzysztof, ja ci bardzo dziękuję za ciekawą rozmowę! Powiedz proszę na końcu, gdzie cię można znaleźć w Internecie, ewentualnie jak poszukać więcej materiałów na temat tego, czym SDNy są i jak z nimi działać? 

 

Wydaje mi się, że jeśli chodzi o materiały, to będziemy mogli coś później podlinkować, przesłać jakieś fajne skróty, takie punkty startowe. Jeśli chodzi o mnie — raczej nie ma mnie w Internecie, jestem na LinkedInie i to chyba wszystko, jak do tej pory. Nie udzielałem się społeczności jakoś specjalnie mocno do tej pory!

 

Jasne! To twój profil na LinkedInie plus oczywiście te materiały, o których wspomniałeś, podlinkujemy w notatce do tego odcinka. Jeszcze raz bardzo dziękuję za wartościową rozmowę. Do usłyszenia, cześć! 

 

Dziękuję, cześć!

 

I to tyle z tego, co przygotowałem dla ciebie na dzisiaj. Muszę przyznać, że to była dla mnie bardzo odkrywcza rozmowa, gdyż na co dzień nie obracam się w świecie sieci komputerowych. Myślę jednak, że praca w tej domenie, jako programista, jest ciekawa i może być dobrą alternatywą do pracy w firmach finansowych czy ubezpieczeniowych. 

Mój rozmówca z poprzedniego odcinka, 58. odcinka podcastu, Adrian Sasin właśnie wystartował kurs dla osób, które rozpoczynają swoją przygodę jako managerowie w IT. Z Adrianem rozmawiałem o tym, jakie wyzwania stają przed takimi osobami.

Sam kilka razy przechodziłem tę drogę i żałuję, że wówczas taki kurs nie był dostępny, bo bardzo by mi to ułatwiło życie. Miałem już okazję zakulisowo zerknąć na materiały, które przygotował Adrian i szczerze polecam! Kurs można kupić pod adresem szkolakierownikow.pl/kurs a z kodem POID10 dostępny jest rabat 10%. Szczerze polecam! 

Jeśli spodobał ci się ten odcinek i nie chcesz przegapić kolejnych epizodów podcastu, zasubskrybuj go w swojej aplikacji podcastowej. Jeśli nie wiesz, jak to zrobić, wejdź na stronę porozmawiajmyoit.pl/subskrybuj 

Zapraszam też do mojego drugiego nieco luźniejszego podcastu.

Wyszukaj: Krzysztof Kempiński- podcast w swojej aplikacji. Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl 

Nazywam się Krzysztof Kempiński a to był odcinek podcastu Porozmawiajmy o IT

o sieciach SDN i karierze dewelopera związanej z tym zagadnieniem. 

Zapraszam do kolejnego odcinka już za tydzień. Cześć! 

mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.