Sylwia: Technologia telekomunikacyjna zmienia się na naszych oczach. To co kiedyś było marzeniem, dziś staje się rzeczywistością. SDN, czyli sieć definiowana programowo to święty Graal telekomunikacji XXI wieku. Filozofia SDN nabrała kształtu w okolicach 2010 roku, a dziś podbija świat technologii telekomunikacyjnych na całym świecie i tworzy nowy rynek, którego wartość w 2027 roku szacowana jest na aż 43 miliardy dolarów. W praktyce SDN oznacza telekomunikacyjną rewolucję. Dzięki filozofii SDN firmy takie jak EXATEL, które samodzielnie piszą oprogramowanie i tworzą własne technologie, mogę kreować elastyczne rozwiązania na najwyższym światowym poziomie. W tym programie rozmawiam z osobami które tworzą rozwiązania oparte na filozofii SDN. Programistami, architektami, analitykami. Czyli praktykami, którzy o technologiach sieci programowalnych wiedzą po prostu najwięcej.

Serdecznie zapraszam na kolejny odcinek podcastu „SDN bez tajemnic”. Sylwia Buźniak, HR Biznes Partner EXATEL.

***

Sylwia: Dzień dobry, dzisiaj moim i państwa gościem jest Kamil Kaczorowski programista Java pracujący w dziale rozwoju SDN. Cześć Kamil!

Kamil: Witam serdecznie.

Sylwia: Dzięki Kamil, że skorzystałeś z zaproszenia. Chciałam porozmawiać o Twojej pracy w EXATEL i o tym jak wygląda rola Java Developera w projekcie SDN. Ale zacznijmy standardowo: dlaczego zdecydowałeś się w ogóle dołączyć do EXATEL do pracy w projekcie sieciowym?

Kamil: Gdy przeglądałem oferty pracy, ważne było dla mnie to, aby nie była to praca która będzie związana tylko i wyłącznie z zyskiem. Wiele firm, szczególnie w branży komercyjnej, koncentruje się na zysku i nie ma żadnej wartości dodanej. Miałem wcześniej okazję pracować czy to w Orange, czy w Samsungu, w firmach które są duże i znane. Brakowało mi natomiast czegoś więcej w nich. Stąd po pewnym czasie pojawił się pomysł aby dołączyć do EXATEL. Firma państwowa, a zatem mająca też pewien cel, pewną misję, coś co my nazywamy w firmie cybersuwerennością. To było jednym z aspektów, który istotnie przyczynił się do mojego dołączenia do zespołu EXATEL.

Sylwia: Masz background telekomunikacyjny? Jakie masz wykształcenie?

Kamil: Tak, skończyłem telekomunikację na Politechnice Warszawskiej. Były to studia pięcioletnie zakończone tytułem magistra-inżyniera. Ten background telekomunikacyjny jest oczywiście połączony z umiejętnościami programistycznymi, które rozwijałem już na etapie liceum, a potem studiów.

Sylwia: Super! Generalnie takich osób jak Ty poszukujemy do projektu. Osób, które nie tylko programują, ale mają też wiedzę domenową – tutaj konkretnie o sieciach telekomunikacyjnych. W EXATEL pracujesz półtora roku. Jak wyglądały Twoje początki?

Kamil: Początki nie były łatwe. Było dużo nowych rzeczy. Trudności były związane z zapoznaniem się z systemami, które tutaj są, z całą tą otoczką. To jest domena każdej nowej pracy do której przychodzimy, że musimy się rozeznać w tym co można, jak można, jakie są procesy. Natomiast po pewnym czasie myślę, że przyszło takie większe zrozumienie jak podchodzić do zadań. Czasu wymagało też samo wdrożenie w tworzone oprogramowanie, w tworzony system. To wdrożenie trwało myślę, że około trzech miesięcy, tak, aby w pełni to zrozumieć. Aczkolwiek praca którą mamy, jest na tyle rozwijająca i na tyle angażująca, że zawsze znajdzie się coś nowego, co wymaga od nas ciągłego rozwoju.

Sylwia: Jak to w projektach badawczo-rozwojowych. Mamy tę literkę R, która rozumiem że jest stale w projekcie obecna. Dużo jest tego researchu?

Kamil: Tak, dokładnie. Z założenia mamy tutaj Research and Development. Można powiedzieć, że w pierwszej części projektu, zakończonej tzw. MVP0, czyli takim bazowym wdrożeniem, było dużo researchu i troszkę mniej developmentu. Obecnie można powiedzieć, że jest to przede wszystkim development, rozwijanie produktu, który swój zalążek już ma i funkcjonuje. Dla nas teraz jest bardzo ważne to, żeby to rozwinąć, żeby ten nasz „kwiatuszek” okazał się w pełni funkcjonalny.

Sylwia: A jak wyglądało to wdrożenie, moment MVP0? Jakie zadania Twój zespół Javowy – bo żeby była jasność, w SDN-ie działamy w dwóch strumieniach C++ Python to jeden strumień, drugi to zespół Javo-wy – miał w projekcie?

Kamil: Nasza rola polegała głównie na rozwijaniu kontrolera SDN-owego. Jesteśmy podzieleni jeszcze na dwa zespoły. Jeden zespół zajmował się bardziej kwestią związaną z Front-endem, portalem, z pewną wizualizacją naszego produktu. Zespół w którym ja byłem, tj. druga odnoga zespołu Javowego, była bardziej związana z kontrolerem, z rozwijaniem aplikacji, funkcjonalności które ten kontroler dostarcza. Było dużo zadań wymagających od nas nietuzinkowych zdolności i nietuzinkowego podejścia do rozwiązywania problemów. Mogę tutaj chociażby przytoczyć mechanizm tzw. intencji, który znajduje się w kontrolerze, rekompilacje tych intencji. Intenty (z ang. Intents) jako takie odpowiadają za instalacje reguł OpenFlow, gdyż staramy się w projekcie korzystać z tego protokołu. Wymagało to od nas wejścia w ten mechanizm, zrozumienia jak intenty działają, jak są zaimplementowane i wprowadzenie odpowiedniej modyfikacji. To nie jest proste wejść w kod, który już funkcjonuje i który już ktoś napisał. Rozłożyć ten kod na czynniki pierwsze i znaleźć w nim to konkretne miejsce, które wymaga od nas zmiany aby ów kod działał tak, jak my tego chcemy. Zazwyczaj mamy jednak tendencję to pisania kodu na nowo, od zera, myśląc że jeżeli napiszemy wszystko od zera, po swojemu, to będzie lepiej. Dlatego też ta praca wymaga od nas zdolności do adaptacji, do tego co jest, tak aby wykorzystać potencjał który oferuje rozwiązanie i usprawnienie tego rozwiązania, wykorzystanie tego potencjału.

Sylwia: Skoro już wspomniałeś o kontrolerze to powiedz jak rozumieć kontroler, do czego służy i jak ma być stosowany?

Kamil: Kontroler jest taką jednostką sterującą w całej sieci SDN, która odpowiada za komunikację z urządzeniami będącymi w tej sieci. Można ogólnie powiedzieć, że SDN to taka trochę scentralizowana sieć w której mamy wiele urządzeń komunikujących się z jednostką sterującą. W tym przypadku kontrolerem, który to może w sposób aktywny lub pasywny decydować o tym, jak przesłać ruch z punktu A do punktu B, gdzie punkt A rozumiemy jako jeden z końców na urządzeniu, na switchu, a punkt B jak drugi koniec na jakiś innym switchu. Teraz, kontroler odpowiada za to żeby przeanalizować topologię w której znajdują się te switche i wybrać optymalną ścieżkę na podstawie algorytmów. Tutaj na przykład bardzo popularny algorytm Dijkstry. Można też dodać tutaj  wagi na danych łączach i na podstawie tego zadecydować, która ścieżka będzie optymalna. Przy tym kontroler daje nam duże możliwości jeśli chodzi o tak zwany QoS czyli  Policing, Scheduling,  ogólnie kształtowanie ruchu – szeroko pojęty traffic engineering.

Sylwia: Czy kontroler umożliwia też programowanie i sterowanie urządzeniami i nadawanie im rożnych funkcji?

Kamil: Tak. To jest pewnego rodzaju odkrycie które w tym projekcie poczyniliśmy, o czym może wcześniej nie zdawałem sobie sprawy, że kontroler daje nam możliwość sterowania również urządzeniami starszego typu (z ang. legacy). Czyli nawet jeżeli mamy w naszej sieci operatorskiej urządzenia, które do tej pory programowaliśmy ręcznie (administratorzy sieci logowali się po protokole SSH do takiego urządzenia, czy to Cisco czy jakiegokolwiek innego i to urządzenie konfigurowali), to okazuje się że odpowiednio zaprogramowany kontroler może to w pełni zautomatyzować. I to jest bardzo duża wartość dodana takiego kontrolera, bo nie dość że mamy możliwość podejrzenia całej tej topologii, to równocześnie możemy  skonfigurować wiele urządzeń.

Sylwia: Jaki wpływ ma praca zespołu Javowego na pracę zespołu C++/Pythonowego? Na ile prace obu zespołów korespondują ze sobą?

Kamil: W dużej mierze jesteśmy zależni od siebie. Można powiedzieć, że zespół C++ to zespół, który jest odpowiedzialny przede wszystkim za dostarczenie nam oprogramowania do switcha, przygotowanie i oprogramowania switcha  SDN-owego. Natomiast my potem ten switch możemy w formie zwirtualizowanej lub fizycznej wykorzystać w tworzonej przez nas topologii. Topologii, która jest zapinana do kontrolera i który to kontroler może na tej topologii testować ruch. Można powiedzieć, że jest pewnego rodzaju hierarchia potrzeb, czyli zespół C++  przygotowuje pewnego rodzaju switch, bazowe urządzenie wraz z oprogramowaniem. Potem ten switch trafia do naszego zespołu, który jest w dużej mierze odpowiedzialny za oprogramowanie kontrolera i wykorzystanie przy tym właśnie tych switchów. Na szczycie tego wszystkiego jest portal operatorski, który pozwala nam na wizualizację tego i podanie na tacy użytkownikowi końcowemu, czyli np. administratorowi sieci telekomunikacyjnej, który może poprzez wyklikanie różnych rzeczy skonfigurować odpowiednio całą sieć, nie musząc ingerować gdzieś głęboko w to, jak działa cały system pod spodem.

Sylwia: Jakich technologii używacie?

Kamil: Jeśli chodzi o zespoły C++, to jest to głównie Python, Docker, jest jeszcze PyCharm jeśli chodzi o środowisko deweloperskie. Jeśli chodzi o nas, o Javowców, to będzie to przede wszystkim IntelliJ, jako środowisko deweloperskie to będzie Docker, Docker Compose, Kubernetes. Dużo technologii, które są szeroko wykorzystywane na rynku.

Sylwia: Przeszliście teraz chyba na K8s?

Kamil: Właśnie K8S, Kubernetes, to platforma którą wykorzystujemy do połączenia tych wszystkich skonteneryzowanych elementów naszej sieci SDN-owej. Kubernetes pozwala nam zorkiestrować wszystkie komponenty, takie jak kontroler, portal operatorski, komponenty pozwalające na integracje z trzecimi stronami, czyli jakimiś systemami operatorskimi wykorzystywanymi już w firmie. Kuberentes ma tę wartość orkiestrującą to wszystko. W sytuacji w której załóżmy dany kontener padnie, to Kubernetes jest w stanie podnieść go i ponownie uruchomić. Jest to duża wartość tego rozwiązania.

Sylwia: Chyba wszystkie zespoły pracują pod Linuxami, prawda?

Kamil: Tak, tak wszyscy jesteśmy pod linuxową domeną. Wykorzystujemy na ile możemy potencjał tego systemu operacyjnego. Wygodniej jest pracować na Linux-ie z tego względu, że daje dużo większe możliwości deweloperowi pod względem developmentu, pod względem zarządzania tym systemem i tego co można robić w ogóle w systemie.

Sylwia: Na ile macie wpływ jako deweloperzy na wybór technologii?

Kamil: To co charakteryzuje EXATEL i ogólnie pracę przy projekcie SDN-owym, to bardzo duża elastyczność. Zarówno pod względem sofware’owym jak i hardware’owym. Jeśli chodzi o system operacyjny, to mamy pełną kontrolę nad tym co się w nim dzieje, dzięki czemu możemy bez przeszkód tworzyć zwirtualizowane topologię i bez przeszkód modyfikować różne rzeczy w tym systemie operacyjnym. Jeżeli mamy potrzeby co do hardware’u, to składamy odpowiednie wnioski i firma bardzo szybko potrafi nam dostarczyć odpowiedni sprzęt, kable czy wkładki światłowodowe, które są tutaj niezbędne. Możemy pójść potem do Labu to wszystko spiąć i w połączeniu z naszym softwarem uruchomić. Możliwości są więc bardzo duże i elastyczność jest bardzo duża, co jest dużą wartością dodaną pracy w tej firmie. Przede wszystkim gdy porównuje ją do jednej z poprzednim firm gdzie panował trochę taki „koreański dryl”.

Sylwia: Pracujemy w projekcie w którym mamy wpływ na wybór technologii, kierunków w których działamy i decyzje zapadają tu i teraz. Na pewno jest to dużo większy komfort pracy. Wspominałeś o laboratorium. Jak wygląda SDN Lab?

Kamil: SDN Lab to kilka szaf rackowych w których mamy głównie switche, które możemy oprogramowywać i konfigurować. Całość jest spięta za pomocą światłowodów z odpowiednimi wkładkami. Wszystko to jest zmapowane na dokumentację w której mamy to wszystko rozpisane. Do samego Laba mamy dostęp zdalny, więc możemy w bardzo elastyczny sposób zarządzać nim, chyba że trzeba coś przepiąć. Wtedy faktycznie trzeba przyjechać do firmy i pozmieniać na miejscu. Sam Lab nie jest duży, natomiast jest w nim dużo sprzętu. Na pewno wymaga dobrej orientacji to, gdzie co jest, jak co jest podłączone, co jest czym. Przydaje się też staż pracy. Pomaga on zrozumieć czy zorientować się w tym, jak ten Lab wygląda oraz pomaga zorientować się co może być potencjalnym problemem w sytuacji gdy coś nam nie działa.

Sylwia: Z jakimi wyzwaniami obecnie mierzysz się Ty i twój zespół? Wasza praca jest zsynchronizowana i połączona. Nie jesteście oddzielnymi jednostkami, które robią coś dla siebie, ale praca jednej osoby ma wpływ na drugą. Nad czym teraz pracujecie? Z czym się mierzycie?

Kamil: W chwili obecnej dopracowujemy to, co wcześniej osiągnęliśmy. Na horyzoncie mamy natomiast rozpisane zadania na nowe usługi. Do tej pory stworzyliśmy jedną usługę bazową. Teraz chcemy pójść szerokim torem i bardzo uelastycznić nasze portfolio usługowe, i rozszerzyć je o nowe możliwości. Tak więc jeden strumień dotyczy poszerzenia zakresu software’owego, który jest dostarczany poprzez kontroler SDN-owy. Z drugiej strony jest to poszerzenie obsługiwanych urządzeń. Chcemy też kolejne switche, z których firma korzysta, użyć w tym projekcie tak, aby można było ten projekt – czy ogólnie sieć SDN-ową – wdrożyć na szeroką skalę np. w naszej firmie.

Sylwia: I finalnie to komercjalizować. Generalnie projekty w EXATEL nie realizujemy na półkę, tylko staramy się je komercjalizować. Przykładem jest choćby TAMA, nasz pierwszy projekt R&D, oprogramowanie dla cyberbezpieczeństwa. Powiedz Kamil, dla kogo projekt SDN-owy może być ciekawy? Obecnie jest ogromne zapotrzebowanie na deweloperów różnej maści z różnym backgroundem, a unikalność projektu jest dosyć wyraźna. Dla kogo projekt SDN-owy może być ciekawy?

Kamil: Pytasz mnie pod kątem potencjalnych klientów czy pod kątem tych, którzy tworzą?

Sylwia: Na razie osób tworzących.

Kamil: Jeśli chodzi o deweloperów czy o osoby które mogą wejść w ten projekt, to myślę że jest to praca dla osób ambitnych, które nie boją się wyzwań i rozwiązywania nietuzinkowych problemów. Ta praca wymaga dużej elastyczności i zdolności do adaptacji do istniejących środowisk, czyli wejścia w coś, co już istnieje i rozwoju tego, a przy tym swoich indywidualnych zdolności. Myślę, że jest to tego typu praca. W tej pracy ciągle coś się dzieje. Ciągle jest coś nowego do odkrycia. Nie ma monotonii. Jeśli jest osoba, która lubi takie zmiany i bardzo dynamiczny rozwój… Jest tutaj bardzo dużo technologii, które z dnia na dzień się pojawiają i trzeba w nie szybko wchodzić, gdyż działamy w Sprintach, co też jest istotne. Ten Sprint narzuca nam pewien rytm pracy i musimy się szybko adaptować, szybko rozwijać nasze umiejętności. Jeśli ktoś lubi tego typu pracę, to myślę że jest to praca dla niego.

Sylwia: Teraz druga cześć pytania, którą sam sobie zadałeś. Dla kogo? Dla jakich klientów?

Kamil: Myślę, że w pierwszej kolejności SDN jest dla nas, dla EXATEL. Dzięki temu możemy wypracować pewnego rodzaju przewagę technologiczną nad innymi telekomami na rynku polskim czy też światowym. Natomiast myślę, że SDN jest ogólnie dla każdego, dla każdej firmy która chce w sposób zautomatyzowany zarządzać swoją siecią. Sądzę, że po pierwotnym wdrożeniu w naszej firmie, rysuje się perspektywa dostarczania czy sprzedaży tego rozwiązania również klientom zewnętrznym. Uważam, że jest to bardzo duża wartość dodana samego SDN-a, projektu który z jednej strony jest researchowy, a z drugiej bardzo mocno osadzony na developmencie, gdyż nie jest to projekt na półkę.

Sylwia: A jak wygląda tworzenie architektury rozwiązania i kto u was podejmuje się tych działań, dekompozycji tych zadań, architektury?

Kamil: Ogólnie to zmieniało się to na przestrzeni całego projektu. W pierwszej części projektu, która wymagała od nas większego researchu, mieliśmy szerokie grono architektów, którzy odpowiadali za przygotowanie rozwiązania, wyznaczenie ścieżek rozwoju. W chwili obecnej, gdy stawiamy troszeczkę bardziej na development, jak również większa jest świadomość projektów w samych zespołach, ten proces architektoniczny został troszeczkę przesunięty w kierunku zespołów. My jako zespół jesteśmy w stanie sami się zorganizować, wiemy mniej więcej jakie są potrzeby, potrafimy do tego dostosować też szczegółową architekturę.

Sylwia: Czyli LLD jesteście już sami sobie w stanie zrobić?

Kamil: Dokładnie tak. Do pewnego czasu architekci byli odpowiedzieli za przygotowanie HLD, jak również LLD. Natomiast w chwili obecnej LLD jest po stronie zespołów, co rozwija również kompetencje samego zespołu w zakresie planowania architektury. Znów jest to kolejna wartość, nie tylko development, ale również to podejście architektoniczne. Rozwój architektury jest czymś bardzo interesującym.

Sylwia: Jak wygląda Twój kierunek rozwoju? Wiem, że w EXATEL działamy również  w ramach IPR-ów, tj. indywidualnych planów rozwojowych. Jak się rozwinąłeś technicznie do tego momentu i jaka jest twoja perspektywa dalszego rozwoju?

Kamil: Rozwijałem swoje umiejętności deweloperskie, natomiast na pewnym etapie zasugerowano mi wejście troszeczkę w rolę Scrum Mastera zespołowego. Mój kierunek rozwoju jest zarówno od tej strony deweloperskiej, jak i pojawił się również kierunek DevOps-owy, przede wszystkim od strony CI/CD, tak aby można było pomóc testerom w procesie testowania, przygotowania środowiska testerskiego. I też się zacząłem dobrze w tym odnajdywać. Tak jak wspomniałem wcześniej, ten aspekt Scrum Masterski, to trochę umiejętności miękkich, zrozumienia procesu, czuwania nad nim tak, aby w zespole wszystko przebiegało w odpowiednich ramach. Osobiście lubię się rozwijać wielotorowo. Nie lubię  jednego konkretnego kierunku, także ten aspekt umiejętności miękkich, umiejętności deweloperskich, czyli właśnie SDN, też w pewnym sensie troszeczkę researchów w kierunku SD-WANa, jak również aspekt CI/CD, czyli przygotowanie środowisk testerskich. To są te trzy elementy w których staram się rozwijać.

Sylwia: Jak testujecie?

Kamil: Pytasz mnie o konkretne narzędzie do testowania?

Sylwia: Pytam o samą formę testowania. Wiem, że nie stosujecie testów manualnych. Więc tak jakby automatyzacja testów, ale tak naprawdę w ścieżce testerskiej zaczynamy od testowania manualnego, potem testowanie automatyczne i tak naprawdę tą finalną rolą jest Software Development in Test, czyli programista testów. Jak to wygląda w projekcie SDN-owym?

Kamil: W projekcie SDN-owym każde zadanie musi zostać w pierwszej kolejności zaimplementowane. Czyli w ramach każdego zadania musi być implementacja, testy i review, czyli jakaś recenzja zadania. Dopiero po tych trzech elementach możemy uznać, że zadanie jest zrealizowane i kod może zostać dołączony do głównej gałęzi, tzw. Mastera. Jeżeli chodzi o sam proces testerski, to mamy do tego dedykowane środowisko, które jest oparte właśnie o tę topologię fizyczną lub zwirtualizowaną. Mamy przygotowane testy zarówno po stronie kontrolera, jak również po stronie portalu operatorskiego. Te testy wykorzystują HTTP REST  API, które jest dostarczane przez kontroler oraz wiersz poleceń (z ang. command-line), który jest dostarczany przez kontroler. W ramach tych funkcjonalności jesteśmy w stanie w czasie testu przekazywać stosowne komunikaty czy polecenia do kontrolera lub do portalu i obserwować zachowanie tego portalu lub kontrolera: czy usługa się poprawnie zestawia, czy urządzenia poprawnie reagują na stworzoną usługę. To wszystko odbywa się w ramach testów zarówno manualnych (mamy dedykowanych testerów w zespole), jak i testów automatycznych, które są wymagane w procesie tworzenia implementacji w tasku czy zadaniu przed mergem do gałęzi głównej, masterowej. Czy to wyczerpało Twoje pytanie?

Sylwia: Tak, zdecydowanie tak. Jesteś bardzo precyzyjny, dzięki. Ciekawi mnie jeszcze współpraca zespołu wytwórczego z interesariuszami, odbiorcami produktu, administratorami którzy pracują u nas w NOC-u lub w Biurze Zarządzania Siecią. Jaki oni dają wam feedback?

Kamil: Ten feedback jest nam przekazywany w ramach odbywającego się co dwa tygodnie review. Pracujemy w Scrumie, więc każdy taki Sprint, u nas dwutygodniowy, kończy się review na którym są zarówno zespoły deweloperskiej jak i osoby z pionu sieciowego. Od nich dostajemy informacje co można by było poprawić, jakie są ich nowe feature requesty i staramy się w ramach naszych kolejnych epików dodawać te zadania. Jeżeli jest to bardzo istotna zmiana, to jesteśmy w stanie zaplanować to nawet na jeden z kolejnych sprintów. Staramy się dość szybko wdrażać zmiany, których oczekuje od nas zespół sieciowy.

Sylwia: Czy oni testują na bieżąco? Bo jesteście po MVP0, czyli wdrożenie na produkcję było. Czy oni fizycznie już korzystają z waszej pracy?

Kamil: Na chwilę obecną rozwiązanie okazało się na tyle stabilne, że nie potrzebuje nawet zbyt wielkiej ingerencji ze strony zespołu sieciowego. Myślę że bliżej kolejnego wdrożenia będą intensywniejsze testy ze strony pionu sieciowego. To są między innymi testy FOA, testy weryfikujące potencjalne opóźnienia przy przełączaniu ruchu jeżeli jakiś link padnie. W chwili obecnej jesteśmy bardziej skoncentrowani na developmencie po naszej stronie i myślę że mniej testów jest po stronie pionu sieciowego. Natomiast im bliżej kolejnego wdrożenia, tym większy będzie feedback i większa porcja testów z ich strony.

Sylwia: Do czego SDN-y mogą być wykorzystywane?

Kamil: Powiem szczerze, że interesowałem się dość mocno jeszcze w czasie studiów i tuż po studiach, kiedy zaczynałem na rynku pracy, czymś co nazywamy internetem rzeczy, czyli IoT. Myślę ze sieć SDN jest świetnym rozwiązaniem dla tego typu technologii. Ogólnie w IoT mamy do czynienia z wieloma urządzeniami, które muszą być zdalnie konfigurowane i zarządzane. Taka sieć SDN-owa poniekąd może nam się przydać, jeśli chcielibyśmy komunikować takie urządzenia między sobą. Możemy wyobrazić sobie sytuację w której mamy samochody autonomiczne, które chcemy aby komunikowały się ze sobą. Zauważmy, że taki samochód może być jak switch w naszej sieci i my możemy poprzez jednostkę centralną, sterująca, decydować o tym jak przekazać informację wykorzystując samochody, które są aktualnie na drodze blisko siebie. Możemy rzutować topologię takich samochodów na widoczną przez kontroler sieć i decydować o tym jak szybciej komunikat przesłać, wykorzystując te samochody, zamiast np. wykorzystywać dedykowaną sieć operatorską lub stacje bazowe, które są gdzieś daleko rozmieszczone. Czyli krótko mówiąc możemy zminimalizować opóźnienia przekazu takiej informacji z punktu A do punktu B. Myślę, że w tym na przykład mogłoby to zostać wykorzystane.

Sylwia: A jeśli chodzi o gospodarstwa domowe?

Kamil: Sieci SDN-owe są rozwiązaniami dużej skali, także trudno mi powiedzieć czy w gospodarstwach domowych moglibyśmy je wykorzystać. Jeżelibyśmy jako operator byli w stanie umieścić nasze urządzenie w gospodarstwie domowym, załóżmy switch SDN-owy, to wtedy faktycznie jesteśmy w stanie na bardzo szeroką skalę zarządzać takim ruchem, jak również konfigurować te urządzenia, co jest wartością dodaną. Możemy wtedy np. mieszkańcom gospodarstwa domowego zaktualizować software, jak również wykonać dużo różnych niestandardowych operacji na grupie osób  np. z danej miejscowości. Tutaj pojawiają się aspekty takie jak Big Data. Centralizacja sieci daje nam bardzo szerokie spektrum możliwości, jeśli chodzi o konfigurowanie, kreowanie i kształtowanie sieci. Myślę ze wartość dodana znajdzie się wszędzie.