EXATELLERS to rozmowy o technologii, biznesie i trendach w obszarze telekomunikacji i cyberbezpieczeństwa. W tym podcaście rozmawiamy o tym, jak w EXATEL łączymy telekomunikację z innowacjami i dlaczego prowadzimy działania R&D tworząc własne rozwiązania. Ja nazywam się Sylwia Buźniak, jestem senior HR Business Partnerem i do tego programu będę zapraszać ekspertów EXATEL, aby poznać kulisy ich pracy i zrozumieć, które technologie są kluczowe dla rozwoju biznesu. Zapraszam.

***

Sylwia:  Dzień dobry, w dzisiejszym odcinku podcastu, moim i Państwa gościem jest Michał Szczęsny, Dyrektor Biura Architektury i Planowania Sieci. Cześć Michał!

Michał:  Cześć Sylwia, dzień dobry drodzy słuchacze.

Sylwia: Dzięki Michał, że skorzystałeś z zaproszenia. Chciałabym z Tobą porozmawiać o szeroko rozumianych SDN-ach. Jako że jesteś właścicielem biznesowym projektów SDN w EXATEL, to chciałabym zacząć od najważniejszych trendów w dziedzinie SDN, które obecnie kształtują przyszłość sieci. Jakie jest Twoje zdanie w tym temacie?

Michał:  Tak, rzeczywiście sieci programowalne mają już jakiś kawałek historii za sobą, bo tak naprawdę startowały w końcówce lat 90’ od tzw. sieci aktywnych (Active Networks). I to był protoplasta aktualnych sieci SDN, które miały swój początek jakieś 10 lat później, po tym pierwszym projekcie. To była DARPA, która tak samo jak budowała to, co nas otacza jeśli chodzi o cyberprzestrzeń i Internet i w takim samym wymiarze budowała sieci aktywne. To miała być w ogóle tak naprawdę rewolucja w podejściu do tzw. sieci pakietowych i budowa nowej architektury sieci, gdzie w takim ekstremalnym wydaniu, każdy pakiet byłby programem. Oczywiście z punktu widzenia bezpieczeństwa jest to mało realne, żeby każdy pakiet był programem. Ale ewolucja tego pomysłu sieci aktywnych z końcówki lat 90’, zaowocowała sieciami programowalnymi, trochę mniej złożonymi, ale dającymi dużo korzyści operatorom, klientom i w ogóle całemu środowisku sieciowemu. Kiedy mówimy o tym, że w pewien sposób unifikujemy warstwę sprzętową z jednej strony, a z drugiej tak naprawdę kształtujemy dane rozwiązanie, jaką ono ma funkcję w sieci, czy jest elementem rdzeniowym sieci, czy jest elementem gdzieś na brzegu, czy jest wręcz po stronie użytkownika. Stanowi o tym kod i tzw. software – oprogramowanie. Dlatego też sieci definiowalne programowo. Na początku była cała koncepcja związana z OpenFlowem, z dedykowanym protokołem, jak to wszystko ma funkcjonować. Rzeczywiście bardzo duża zmiana. I zawsze tak jest, że jeśli mówimy o takiej dużej zmianie i ona pada na taki grunt już ustabilizowanych, dużych dostawców, którzy mają swoje technologie opracowywane od lat, to nigdy to nie jest trywialne, żeby wdrożyć nową technologię. Zwłaszcza w takim wymiarze, że jest to po prostu nowy protokół i „zapomnijcie o tym co było do tej pory, idziemy nową ścieżką. Wdrażajcie OpenFlow, wszystko będzie teraz programowalne, zunifikujmy sprzęt, wirtualizujmy”. Za SDN zawsze kroczyło NFV, czyli Network Function Virtualization, tj. wirtualizacja pewnych funkcji sieciowych. To może nie brat bliźniak, ale z pewnością kuzyn SDN. Wiadomo, że bardzo często jak budujemy dom, to łatwiej go zbudować niż wyremontować, więc dostawcy adaptują to bardzo średnio. Widzą taki pomysł czy technologię i duzi dostawcy oczywiście w swoich komunikatach, w takim mainstreamie, informują że oczywiście „wspieramy, próbujemy wypuszczać takie produkty”, ale jednak one wykorzystują 10 – 15% możliwości, które daje taka nowa zmiana, nowy protokół, nowa technologia. Ten ogon technologiczny, który ciągną te wszystkie swoje stare rozwiązania, zachowanie kompatybilności wstecz, było bardzo trudne. Ciężko było przekonać klienta, że przez ostatnie 15-20 lat sprzedawaliśmy takie rozwiązanie, cały ekosystem rozwiązań, a teraz po prostu wprowadzamy totalnie coś nowego, bo będzie sensowniejsze i „wymieńcie to co macie na to, co teraz wam oferujemy”. To jest po prostu niemożliwe dla nich. Oni muszą utrzymać pewnego rodzaju ciągłość, kompatybilność wsteczną i muszą to robić zdecydowanie bardziej ewolucyjnie niż rewolucyjne. I ten SDN, powiedzmy że mamy +/- 15 lat, od kiedy ta koncepcja rzeczywiście nabrała realnych kształtów i on jakby kiełkował i nie było rozwiązania, które jest takim czarnoziemem czy podatnym gruntem, na które padły te ziarna SDN. To się zaczęło zmieniać i dużą rolę mają w tym, tzw. hyperscalersi czy gracze OTT (Over-the-Top) tacy jak Facebook, Google, Amazon czy poniekąd Microsoft. Mówimy też o dostawcach chmur publicznych, czyli GCP, AZURE i AWS, którzy stwierdzili, że przy tak wielkoskalowych operacjach które mają, przy tych setkach tysięcy czy milionów jednostek obliczeniowych potocznie zwanych serwerami, to wszystko trzeba połączyć, zunifikować całą tę warstwę sieciową, że należy w pewien sposób dokonać dużych zmian. Oni zaczęli z jednej strony otwierać tę architekturę, że każdy może jak ma ochotę sobie ściągnąć z sieci, są inicjatywy typu OCP (Open Compute Platform), można sobie ściągnąć diagramy jak należy zbudować takie urządzenie sieciowe, można też w zaciszu domowym polutować taki switch, router czy serwer, który np. ma Amazon w swoich serwerowniach i zbudować. I to był taki element, który jakby przekroczył horyzont zdarzeń, gdzie z jednej strony mieliśmy możliwość dostępu do hardware’u, który był bardzo elastyczny, otwarty, gdzie tak naprawdę obsługiwał duże strumienie ruchu. Że to nie była architektura oparta o architekturę klasyczną x86, gdzie mamy strumienie rzędu kilkudziesięciu Gbps w tych dużych instalacjach opartych o sensowne karty sieciowe. Ale rzeczywiście mając dedykowane układy sieciowe, jesteśmy w stanie przepuszczać ruch idący w Tbps. Z punktu widzenia sieci mieliśmy z jednej strony otwarte, elastyczne platformy sprzętowe, obsługujące ruch sieciowy, dostępne w atrakcyjnych cenach, z otwartym interfejsem, w dużej mierze bazujące na układach scalonych które dostarcza najczęściej Broadcom. Ale dostarcza też specyfikację, można tak naprawdę napisać do nich oprogramowanie i mogą to zrobić różne firmy. Czyli można tworzyć różne systemy na bazie jednego, zunifikowanego układu sieciowego. Nie będę wymieniał nazw, ale mamy kilka takich firm sieciowych, które też produkują takie układy, ale one są oczywiście zamknięte i może je tylko dana firma rozwijać i taki system operacyjny na swoim układzie uruchamiać. I z jednej strony mieliśmy te rozwiązania sprzętowe, a z drugiej strony rzeczywiście dużą siłę, która wzbierała w różnych inicjatywach jeśli chodzi o sieci programowalne ale też to, co przyjęło taką nazwę Disaggregated Network czy Open Networking, także otwarte sieci i rozwiązania, które pozwalają budować sieć niezależnie od monolitycznych rozwiązań przez dostawców, którzy dominowali na rynku i poniekąd jeszcze dominują, co spowodowało, że jeśli ktoś w  chwili obecnej ma odpowiednie zasoby – bo to też nie jest tak że to jest trywialne; nie każdy mówiąc kolokwialnie z ulicy po prostu sobie podejdzie, może oczywiście zlutować mały switch, ale trzeba mieć dużo umiejętności, dużą wolę i później jeszcze złączyć ten hardware z odpowiednim oprogramowaniem, napisać to oprogramowanie, mieć możliwości stworzenia niskopoziomowego programowania dla tych układów sieciowych, np. które dostarcza Broadcom. To jednak też jest kawał ciężkiej pracy i wymaga odpowiednich zasobów, kompetencji, sprawnych programistów, architektów, analityków, całego sztabu ludzi, którzy są w stanie to zrozumieć i później stworzyć takie rozwiązanie. Tutaj cała ta otwartość, możliwość realizacji takich projektów spowodowała,  że na rynku pojawiały się pewne rozwiązania, które na razie należy traktować jak klocki Lego. Nie ma w chwili obecnej pełnych rozwiązań, gdzie jeden dostawca to oferuje. Ale to bardzo dobrze, bo z jednej strony jeśli byłby jeden dostawca, który oferuje cały ekosystem, to jest to zaprzeczenie tej otwartości, budowania sobie rozwiązań, taki disaggregated. Czyli ja mogę mieć urządzenie sieciowe od dostawcy A, drugie od dostawcy B, oprogramowanie na urządzeniu od dostawcy C, kolejne od dostawcy D, a jeszcze mój sterownik SDN będzie mój własny albo będzie jeszcze od innego dostawcy.

Sylwia: Czy to jest korzystne?

Michał: Tak, to jest właśnie kluczowe pytanie jeśli chodzi o taką korzyść. My jako EXATEL, ale też ja osobiście podchodzę do tego tak, że dzielę ten tort na dwie duże połowy. Pierwsza część to duzi operatorzy i oni idąc w taki model Open, disaggregated czy programowalne, wychodzą z dwóch kluczowych elementów, które są dla nich najważniejsze. Oni bardzo często nie muszą się martwić o klientów. Klienci są zunifikowani, obsługują rynek residential, klientów  masowych, małych klientów biznesowych, klientów SoHo. I kluczowym elementem dla nich jest po pierwsze cena. Bo rzeczywiście jeśli oni kupują w sposób powtarzalny te rozwiązania, które są tak zwane White Label, czyli takie OEM czasami na to mówimy – czyli że nie stoi za tym duża marka która bierze dużą marżę za to że jest po prostu jakąś konkretną firmą – tylko kupujemy te produkowane bardzo masowo rozwiązania, które są uniwersalne, to rzeczywiście te różnice w cenach są znaczące. To nie jest kilka procent. To jest rzeczywiście znacząca różnica i jest to pierwszy element, który jest bardzo ważny dla tych dużych operatorów. Kolejny, wielokrotnie przez nich podnoszony, to kwestia tak zwanego Vendor Locka. Oni w chwili obecnej argumentują to tym (my też obserwujemy to również w swojej działalności), że jeśli zdecydujemy się zwłaszcza na urządzenia, które są urządzeniami bardzo wydajnymi, działają w rdzeniu sieci, w agregacji, odpowiadają za ruch liczony w Tbps, to najczęściej są to poważne, dużą urządzenia, które są pakowane w różnego rodzaju moduły. Teraz oczywiście to się  zmienia, ale powiedzmy że dla uspójnienia wizji, jest to cały czas jednak znaczące urządzenie i ono ląduje na węźle operatora i jest później co najwyżej upgrade’owane. Tak jak mamy w domu komputer, wymieniamy sobie procesor, kartę graficzną itd., ale obudowa i wiele elementów cały czas pozostaje bez zmian. Ale cały czas jestem związany z jednym dostawcą umową utrzymaniową. Więc to są takie elementy, które wskazują ci duzi gracze, czyli oczywiście takie klasyczne ograniczenie kosztów i że mogą taki bardziej sourciongowy element, czyli mogą wprowadzić konkurencję pomiędzy swoimi dostawcami:„a to ja wezmę od tego, bo Ty jesteś za drogi dzisiaj. To weźmiemy tysiąc urządzeń od dostawcy B, ponieważ to są te same rozwiązania i tak per saldo to mogę działać też na innym”. I jest też druga połowa tortu: mniejsi dostawcy, bardziej ambitni jeśli chodzi o zastosowanie. Do takich dostawców zaliczamy się właśnie my – jesteśmy operatorem, który realizuje usługi dla dużych i bardzo wymagających klientów. Usługi te są bardzo często modyfikowane pod ich kątem, usługi są specjalizowane pod danego klienta i jego potrzeby. Mając takie rozwiązanie po naszej stronie, jesteśmy w stanie stworzyć taki garnitur, który będzie idealnie pasował. Jeśli klient  chce mieć jakiś wpływ na rozwiązanie związane np. z telemetrią albo na to jak ma wyglądać routing jego pakietu w naszej sieci, to będzie mógł na to w bardzo elastyczny sposób wpływać, albo będzie mógł to robić sam, albo my będziemy mogli robić to dla niego. Tylko w naszym przypadku oczywiście te dwa elementy, które były przy dużych operatorach, też grają rolę, bo nie ukrywajmy – te koszty, brak związku z tylko i wyłącznie jednym dostawcą, też jest olbrzymią wartością. Jest w zasadzie pewnym aksjomatem, jest niedefiniowalny i gra dla nas bardzo dużą rolę, ale dodatkowo oprócz tego co mają ci wielcy gracze z dużym gronem odbiorców końcowych i usługami, to jest kwestia tej elastyczności i otwartości naszej sieci.

Sylwia: A jakie są korzyści wynikające z wprowadzenia architektury SDN dla operatora sieci, chociażby takiego jak EXATEL?

Michał: Oprócz korzyści o których mówiłem, to jeszcze pewnie ze trzy kolejne dojdą. Nie będę ukrywał, że od samego początku patrzymy przez pryzmat budowy naszego własnego rozwiązania SDN-owego, przez takie okulary składające się z tych co najmniej pięciu czy sześciu szkiełek. Korzyści, które wymieniłem są oczywiste. Powiedzieliśmy sobie, że są to pewnego rodzaju aksjomaty, czyli obniżenie kosztu, niewiązanie się z konkretnym dostawcą. Ten trzeci – możemy go tutaj rozszerzyć bo dotyczy tak naprawdę bardzo ściśle naszej specyfiki, czyli operatora, który świadczy usługi bardzo specyficzne dla dużych klientów, bardzo jednostkowe. I to jest ten element, który jest dla nas bardzo istotny, bo pozwoli nam zatrzymać spadające marże – to będzie mogła być dosprzedaż usług. Będzie można tak naprawdę pójść w kierunku zaproszenia klienta. To też jest tutaj nasze nowe podejście, czyli otwieramy się nie tylko na to, że okej drogi klienci, jest elastyczność, ale tak naprawdę Ty w pewien sposób dostajesz wirtualną sieć na bazie tych komponentów, które my budujemy. Jesteś pewnego rodzaju współwłaścicielem tej sieci, twojej usługi. Z naszego punktu widzenia kolejnym tym szkiełkiem jest również kwestia bezpieczeństwa w wielu wymiarach. Jeśli będziemy w stanie dużo bardziej kontrolować te rozwiązania, to będziemy budować coraz bezpieczniejsze usługi dla naszych klientów. To też nie jest tajemnicą, że obsługujemy klientów typu Ministerstwo Obrony Narodowej, Ministerstwo Spraw Wewnętrznych i Administracji i odpowiadamy za sieci takie jak OST 112. Więc im EXATEL będzie miał większą wiedzę o tym, jak wyglądają takie rozwiązania i w szczególności sam będzie je budował, tym lepiej dla bezpieczeństwa takich rozwiązań i usług realizowanych na ich bazie. Bo jak będziemy mieli wgląd w hardware i będziemy mieli szczególny wgląd w oprogramowanie tego sprzętu, to z natury rzeczy oczywiście dużo bardziej to zabezpieczamy. Kolejnym elementem, który nas do tego motywował, była też chęć przejścia do tak naprawdę nowego wymyślenia poniekąd sieci. My też z jednej strony oczywiście budujemy tradycyjne usługi, ale z drugiej strony ta architektura sieci ma być architekturą uproszczoną, architekturą, która jest zgodna z tym co się dzieje np. w tych środowiskach wcześniej wymienianych gracza OTT czy hyperscalersów, że to jest bardziej takie rozwiązanie, które można powiedzieć Network as Code (NaC), czy że dużo bardziej ta kwestia oprogramowania. Są to techniki czy rozwiązania które są topowe teraz na rynku. Że nie jest to jakieś archeo techniczne, że to nie są urządzenia sieciowe napędzane na węgiel, tylko idziemy też z duchem czasu i rozwiązania, które implementujemy, mają taki duży pierwiastek i możliwość dużej zmienności. To nie tylko jest fun, jeśli to jest rozwiązanie, bo jest zgodne z nowymi trendami, wykorzystujemy najnowsze technologie itd., ale też że możemy wprowadzać szybko zmiany i modyfikacje. Że nie czekamy rok czy dwa, nie zgłaszamy jakiegoś zapotrzebowania do naszego dostawcy, tylko sami to zmieniamy.

Sylwia:  Plus wynika to też z potrzeb klientów, tak? Bo możemy sami wdrażać funkcjonalności. W zależności od tego jak zaprogramujemy urządzenie, to ono może mieć różne funkcje, tak?

Michał: Dokładnie tak.

Sylwia: Jakie według Ciebie są kluczowe funkcje? Wiadomo, że jest jakiś MVP, więc jest i pewien standard, taki must have. Ale mamy jeszcze takie wish to have, nice to have…

Michał: Jeszcze skończę ten poprzedni wątek, bo to też jest  pewnego rodzaju magnes dla naszych nowych pracowników, dla kadr, że mamy fajny projekt i to nie jest jakby ściąganie jakiś starych urządzeń z rynku, które trzeba konfigurować zgodnie z manualem, tylko że możemy kreować tę rzeczywistości. I to też jest bardzo fajne, bo to powoduje, że robimy naprawdę ciekawe projekty i w ten sposób budujemy dużą wartość dodaną. Wracając do Twojego kolejnego pytania, to jest to już rzeczywiście bardzo operacyjne pytanie. My patrzymy w pierwszym kroku oczywiście na nasze potrzeby. Czyli wdrożenie sieci SDN. Już jest w EXATEL, już mieliśmy ten ważny moment wdrożenia rozwiązania. Pierwsza faza budowy sieci. Sieć już funkcjonuje, a w niej kilkadziesiąt urządzeń. Są też uruchamiane pierwsze usługi. I dla nas były najważniejsze tzw. usługi realizowane w warstwie drugiej (warstwa druga zgodna z modelem ISO, czy z modelem TCP/IP), czyli usługi realizowane przez sieć Ethernet, w szczególności Carrier Ethernet. Czyli wdrażamy usługi, które są tak naprawdę realizacją dla klienta usług przenoszenia ruchu z miejsca A do miejsca B. Zestawiamy tzw. rurę, żeby przesyłać ruch z miejsca A do miejsca B. I to jest taka podstawowa usługa, którą teraz wdrożyliśmy. To jest pierwszy krok. Drugim krokiem będą usługi warstwy trzeciej. Oczywiście będziemy rozwijać jeszcze usługi w warstwie drugiej. Na razie mówimy głównie o usługach klasy E-Line. Będziemy wdrażać całe spektrum usług, które jest standaryzowane przez Metro Ethernet Forum, które standaryzuje usługi Ethernetowe czy Carrier Ethernetowe. Natomiast w warstwie trzeciej będziemy wdrażać usługi L3 VPN, czyli dla naszych dużych klientów, którzy mają np. rozproszone oddziały po całej Polsce. Budujemy dla nich sieć wydzieloną, tzw. sieć prywatną i to będzie kolejny krok dla naszych rozwiązań. Trzecim będą te wszystkie obszary związane z tradycyjnym tranzytem IP. To zostawiamy sobie na koniec, ale są to jakby takie duże kamienie milowe. Natomiast to o czym wcześniej mówiliśmy, czyli kwestia ekspozycji tych usług i zarządzania nimi czy kreowania tych usług na zewnątrz, budowa pewnych środowisk typu dedykowane API, dedykowane software development kity, będą towarzyszyły tym usługom z każdej z warstw. Czyli że usługi budujemy w chwili obecnej na nasze potrzeby, żeby migrować z aktualnych architektur. Będziemy wygaszać to, co mamy w chwili obecnej i migrować te usługi na nasze rozwiązanie. One będą już w tym modelu też wyjścia do klienta. To oczywiście będzie wielowymiarowe. Czyli migracja usług i od razu są efekty kosztowe, efekty braku Vendor Locka. Od razu dodajemy te nowe rzeczy, które mogą nam zwiększyć dosprzedaż, a z drugiej strony mamy jeszcze cały plan z wyjściem z rozwiązaniami na zewnątrz.

Sylwia: Korzyści są bezsprzeczne, natomiast na pewno też wiążą się one z wyzwaniami, jakie muszą stawić czoła takie firmy jak nasza, w procesie tych migracji do architektury SDN. O jakich największych wyzwaniach możemy mówić z Twojej perspektywy?

Michał: To jest bardzo dobre pytanie, bo z jednej strony mówimy o sieci, zwłaszcza że jesteśmy z niej dumni w dużej mierze, z jakości którą zapewniamy, stabilności. To też jest wymaganie i specyfika klientów dla których to realizujemy, że ta sieć musi być bardzo niezawodna. To jest oczywiście bardzo ludzkie i naturalne. To jakby klasyczny ciąg myślowy, że jak mamy rozwiązania które są sprawdzone, wygrzane, dostarcza je dostawca, który ma tysiące tych urządzeń u różnych operatorów na świecie i robi to 20 lat, to wiele błędów już zostało wyłapanych, przygotował rozwiązanie dojrzałe. To z pewnością duży plus takiego starego podejścia. Więc my tutaj musimy położyć olbrzymi nacisk – i to jest według mnie najtrudniejsze – na budowę bardzo stabilnej sieci, bardzo niezawodnej, gdzie będziemy migrować te usługi ze starego modelu na nowy, że rzeczywiście ta jakość nie zostanie zaburzona. To jest taki czynnik i wskaźnik, który pewnie będzie najważniejszy, że budowa tej sieci w takim podstawowym elemencie, zachowa nam po prostu co najmniej takie parametry jakościowe i niezawodnościowe, jakie ma aktualne rozwiązanie. To jest pierwsze – taki bardzo organiczny, najbliższy ciała element, który musimy uwzględnić. A drugi oczywiście, że te zmiany najbardziej interesujące dla klientów, ta otwartość, wystawienie naszych funkcji sieciowych, to zaproszenie klienta do tej wspólnej sieci, żeby te rozwiązania były wdrożone jak najszybciej, żeby też z tym nie czekać. Z jednej strony mamy coś, co nie zawsze jest łatwe do pogodzenia, czyli zbudowanie stabilnej sieci – wiadomo, że im coś prostsze, tym stabilniejsze – dla klientów, którzy wymagają dużej niezawodności, połączone z tym, że chcemy być bardzo elastyczni i chcemy mieć te nowe technologie i szybko wprowadzać zmiany, co może czasami się kłócić. To będzie prawdopodobnie największe nasze wyzwanie, żeby spróbować pogodzić jedno z drugim.

Sylwia: Na rynku mamy już rozwiązania SD-WAN. Jak to się ma do SDN?

Michał: To jest dobre pytanie. SD-WAN to takie małe ziarenko w świecie SDN-u. SD-WAN to jest tzw. sieć nakładkowa, czyli Software-Defined Wide Area Network, tak jak byśmy sobie to rozwinęli. Jest to zbudowanie na bazie niezależnej sieci dostępowej, różnych dostawców. Czyli mam jakąś sieć, jakąś grupę różnych lokalizacji, które chcemy podłączyć, są podłączone do różnych sieci, różnych operatorów i chcemy to wszystko sobie zunifikować. I wtedy bierzemy tego SD-WANa, czyli budujemy sieć nakładkową, czyli pewne tunele pomiędzy urządzeniami końcowymi, a innymi lokalizacjami. Powiedzmy, że to będzie w układzie gwiazdy – czyli jest jakaś centrala i ileś oddziałów, tak będzie najłatwiej. Jesteśmy w stanie sobie zbudować takie rozwiązanie, które niezależnie co jest w podkładzie, to zbuduje nam taką wirtualną sieć, którą będziemy mogli zarządzać, będziemy mogli sobie np. sterować tym ruchem, że czasami dana placówka ma dwa różne łącza i mogę sobie zarządzać żeby szło tym łączem albo tym, albo pół na pół, albo mogę to w fajny sposób monitorować. Osobiście traktuję SD-WAN jako taką drobną rzecz, czyli tak naprawdę sieć nakładkowa z bardzo przyjaznym interfejsem do zarządzania tą siecią. Tam nie ma takiej klasycznej programowalności o której mówiłem przy SDN, przy tym naszym projekcie. Tam nie modyfikujemy programowo urządzeń, żeby służyły nam do tego czy do czegoś innego. Tutaj bardziej mówimy, że jest to programowanie WANA, czyli najlepszym określeniem dla SD-WANa jest „elastyczna konfiguracyjnie sieć rozległa”. SD-WAN nawet ciężko nazwać jakąś znaczącą usługą w domenie SDN. Jest to po prostu wykorzystanie tej nazwy przy okazji budowy wydzielonej sieci prywatnej w sposób dużo bardziej elastyczny, niż miało to miejsce do tej pory.

Sylwia: SDN jest też czymś nadrzędnym, pewną filozofią. Możemy więc mówić o nim w szerszej perspektywie.

Michał:  Przedrostek SD jest wykorzystywany wielokrotnie w różnych rozwiązaniach, bo mamy oczywiście SD-WAN, mamy SDA czyli Software-Defined Access, sieć definiowalna, mamy SDR czyli Software-Defined Radio. Od jakiegoś czasu mamy układy radiowe, które mogą być definiowalne przez oprogramowanie i to też jest jakby SD. I te SD pojawia się wielokrotnie i nie jest to po prostu zbieżne z tym, co my tutaj rozumiemy jako SDN. Czy w ogóle czym jest samo SDN? To jest kwestia jakiejś tam zbieżności i prefiksów.

Sylwia: W jaki sposób technologia SDN wpłynie na rozwój internetu rzeczy i zastosowania chociażby dla inteligentnych miast?

Michał: Tutaj chyba najbardziej istotnym będzie ten element niezależności warstwy oprogramowania od warstwy fizycznej. Jeśli więc mówimy o IoT czy Smart City, to będziemy mogli sobie pójść w takim kierunku, że zunifikujemy sensory. To będzie np. duża optymalizacja kosztowa i architektoniczna, że będzie można modyfikować tę jednostkę centralną sensora. Sensory zawsze będą inne, bo inny sensor analizuje wodę, a inny jest sensor odległościowy. Tego software nie zmieni. To jest jednak fizyka i kawałek pewnego rodzaju sprzętu, który musi być konkretny i tego programowo nie zmienimy. Natomiast to, jak zachowuje się dany sensor, w jaki sposób funkcjonuje, z jaką siecią się łączy, np. mechanizm SDR-owy, czy on będzie sensorem, który działa w sieci LoRa, czy działa w sieci 5G, to możliwość wykorzystania SDN zdecydowanie nam uelastyczni działanie takiej sieci. Więc tak naprawdę to będzie w dużej mierze aspekt kosztowy, ale też taki szybkiej modyfikacji funkcjonowania takich sensorów.

Sylwia: Czy z  poziomu urządzenia SDN można centralnie kontrolować i wychwycić także błędy w sieci i szybciej to się wydarzy niż w przypadku tradycyjnych sieci nie SDN-owych?

Michał: Chyba jakiegoś kolosalnego przełomu bym się nie spodziewał. Bardziej to by było istotne przed dużo szybką adaptacją danych urządzeń i tej komunikacji w sieci. Czyli jak mamy jakieś sensory, End Pointy, czy urządzenia końcowe i one kiedy np. się komunikują jakimś protokołem – bardzo często wyspcjalizowanym, ale zakładamy, że to unifikujemy – to wtedy z wykorzystaniem takiej sieci programowalnej moglibyśmy np. w locie zmieniać warstwę transportową takiego protokołu. Będziemy mogli zmodyfikować np. czy zastosować lepszą modulację, inną korekcję błędu, że będzie dużo większa elastyczność niż takie fixed rozwiązanie, które zostało przygotowane przez producenta. Należy też pamiętać, że SDN to jest też trochę miecz obusieczny, który wymaga świadomego użytkownika albo partnera, który będzie w stanie to dla takiego klienta zrobić. To tak jak ze wszystkim, że z jednej strony możemy mieć rozwiązanie które jest zamknięte i ono zawsze zadziała tak samo w każdych warunkach, jest proste do obsługi. Natomiast jeśli pójdziemy w rozwiązanie, które jest bardzo konfigurowalne, że możemy sobie sami przeprogramować, możemy dać klientowi możliwość przeprogramowania, że ma wiele opcji, to musi posiadać większe kompetencje, ale będzie miał też dużo większe możliwości. I może korzystać z wiedzy operatora, ale to wtedy coś za coś. Ten SDN jednak pójdzie w takim kierunku też zwiększenia świadomości nie tylko operatora, ale też świadomości klienta i w szczególności w takich zastosowaniach typu Smart City czy IoT istotne będzie połączenie w ogóle SDN-u np. z technologami 5G, wykorzystanie slicing’u, dedykowanych w ogóle przestrzeni sieciowych, takich jak Network as a Service (NaaS) czy network slicing, że mam dedykowane elementy. Np. jak mam Smart City i mamy telemedycynę to wiemy, że tam musi być duża niezawodność. Może nie ma wymagania na duży ruch, ale wiemy, że jak jest jakiś pacjent podłączony do zdalnego KTG, to żeby te dane zawsze dotarły do szpitala. Więc to w innym reżimie działa. Jest inna część sieci dedykowana, mega niezawodna, która może być np. droższa. Ale taka sieć, która zbiera informacje że pojawił się samochód i sensor wyczuwa, że jest i pokazuje miejsca parkingowe, no nie jest  to takie krytyczne czy tam będzie 5 miejsc parkingowych plus czy minus. To nie jest takie istotne, więc wtedy może mieć tańszą tą sieć zbudowaną na takich zasobach, które nie są zawsze dostępne. Wtedy pewnie jest to mniej niezawodne, ale też jest tańsze dla użytkownika końcowego. A jak mamy kamery, mamy system wizyjny jakiejś telewizji przemysłowej, to nie zależy nam na tym, żeby tam była też mega niezawodność, a zależy nam żeby były tak naprawdę rury o dużych przepustowościach, że ten sygnał wideo dotrze do serwera, który odpowiada za analitykę wideo i przeanalizuje zdarzenie – co się dzieje gdzieś na rondzie, wypadek itd. To spowoduje, że programowalność połączona z sensowną bezprzewodową siecią dostępową, najlepiej 5G, da zupełnie nowe możliwości.

Sylwia: Temat 5G to temat rzeka, więc jak SDN wpłynie na rozwój sieci 5G, to zostawimy może na inną okazję. Ostatnie pytanie z mojej strony jest o takie najbardziej innowacyjne zastosowania technologii 5G, bo podałeś już fajne życiowe przykłady…

Michał: A jak innowacyjne to ma być?

Sylwia: Mogą być nawet przyziemne. Wspomniałeś o szpitalach. Nawet sobie nie zdawałam sprawy.
Coś co może słuchaczom otworzyć oczy, że to już się dzieje, że SDN jest stosowany w szpitalach, w sygnalizacji świetlnej, w IoT.

Michał: Ciekawym przykładem połączenia sieci programowalnej i trochę też sieci bezprzewodowej nowej generacji, są np. hodowle łososi w Norwegii. Są one hodowane w takich specjalnych pływających basenach i ze względu na to, że były duże straty (ponieważ są miliony tych łososi), to żeby zoptymalizować zarówno to by one nie chorowały i by do tego nie marnować karmy, jest wykorzystywana analityka wideo na wysokim poziomie. Czyli kamery o wysokiej rozdzielczości, również podwodne, które analizują całe czas to, co dzieje się w tych pływających basenach. Analizują one kształt ryb, kolor, jak wygląda ryba, ich płetwy. Analizują też jak następuje droga pokarmu: o której się pojawia na powierzchni, ile mniej więcej przechodzi, ile jest zjadanego, ile opada na dno. Żeby optymalnie tym wszystkim sterować. I tam chodziło o to, że te baseny cały czas są w ruchu, pływają i ciężko było przesyłać z nich te dane do jakiegoś centralnego miejsca sieci, żeby to wszystko analizować. Do tego duży ruch, bo to były olbrzymie strumienie wideo, zwłaszcza że to były setki kamer i właśnie z wykorzystaniem pewnej programowalności czyli takiej inteligencji brzegu sieci. Czyli na urządzeniach sieciowych na brzegu, zainstalowano oprogramowanie, które analizuje to wideo. I te wszystkie akcje były podejmowane na samym brzegu, czyli kamera analizuje że jest chora ryba albo jest zły pokarm lub za dużo pokarmu, następuje pętla zwrotna. Czyli jest analiza od razu na elemencie brzegowym. Urządzenie programowalne, tam instalujemy sobie jakiś serwer który analizuje to wideo i od razu informacja zwrotna, że tej karmy musi być mniej albo dane ryby w danym basenie wymagają opieki. To wszystko jest zautomatyzowane i jest to ciekawe zastosowanie technologii przy tych farmach łososi. Zdalne operacje, czy właśnie ten monitoring , to w szczególności kwestia budowy niezależnej sieci. Jeszcze przy okazji takich rozwiązań programowalnych możemy też sobie wyobrazić tak naprawdę możliwość budowy takich urządzeń również na bazie naszych komputerów domowych czy urządzeń mobilnych. Także wgrywanie odpowiedniego oprogramowania spowoduje, że my z naszego telefonu czy komputera będziemy mieli też urządzenie, które będzie częścią np. sieci. I to powoduje, że jeśli np. jesteśmy jednostką, która chce być w jakiejś sieci prywatnej, wydzielonej, a nie chcemy instalować dedykowanego urządzenia, to dzięki temu, że możemy zainstalować kawałek oprogramowania na naszym własnym urządzeniu fizycznym, to stajemy się elementem tej całości.

Sylwia: Super case’y na koniec. I tym optymistycznym akcentem bardzo dziękuję Ci za tę rozmowę. Mam nadzieję, że będziemy jeszcze mieli okazję porozmawiać czy to w temacie SDN, czy innych wątków sieciowych w kolejnym podcaście.