Cloud native jest technologią przyszłości. Jak pracujemy z nią w dużych projektach?

Metodologię cloud native spopularyzowały takie firmy jak Facebook, Netflix czy Amazon. Dzięki cloud native możemy efektywnie tworzyć i rozwijać aplikacje, wykorzystując potencjał usług chmurowych w zakresie skalowalności, produktywności i bezpieczeństwa. Rozmawialiśmy z dwoma inżynierami oprogramowania w Ericsson – Tomaszem Bosakiem i Aleksandrem Witkowskim, którzy podzielili się swoimi doświadczeniami pracy z tą metodologią.

Czym dla Was jest podejście cloud native?

Tomasz Bosak: Dla mnie cloud native to architektura mikroserwisowa, gdzie mamy w pewnym sensie uniezależnienie się od konkretnego sprzętu i elastyczność we wprowadzaniu nowej funkcjonalności.

A “po ludzku”?

Tomasz: Piszemy software dla bliżej niesprecyzowanego sprzętu, ukrytego za warstwą dostępową, podzielony na mniejsze kawałki niż z reguły w architekturze monolitycznej. Dzięki temu łatwiej zmienić każdy konkretny element, dostarczyć na nowo z poprawkami, wprowadzić nową funkcjonalność czy dorzucić jeszcze inny kawałek, inny mikroserwis.

Od strony klienta, architektura cloud native, moim zdaniem, cechuje się elastycznością w doborze funkcjonalności, które chce wdrożyć. Dzięki elastyczności może efektywnie wykorzystywać swoje zasoby sprzętowe. Co ważne, klient może dokonywać dowolnych zmian w konfiguracji w zależności od potrzeb, czyli zainstalować mniejszą wersję, zmieniać liczbę równolegle działających serwisów czy też ilość pracujących serwerów. Może w łatwiejszy sposób aktualizować i wprowadzać funkcjonalności, aktualizować istniejące i wprowadzać nowe elementy architektury.

Co z kosztami? Czy cloud native nie wymaga większego budżetu?

Tomasz: Architektura cloud native wymaga większego nacisku na testowanie i na integrację pomiędzy wersjami tej samej funkcjonalności, pomiędzy różnymi funkcjonalnościami, żeby wszystko ze sobą współpracowało, żeby się nie okazało, że wprowadzając nową wersję produktu X nie będzie on w stanie się dogadać z istniejącymi wersjami produktu Y. Dużą za to zaletą jest wymagane i wbudowane od podstaw bezpieczeństwo, z racji tego, że nie wiemy, którymi kanałami będą przechodzić wiadomości pomiędzy naszymi serwisami, czy będzie to pomiędzy np. procesorami, czy też pomiędzy węzłami Kubernetesa w ramach jednego klastra, czy pomiędzy różnymi klastrami. To jest chmura, my nie znamy topologii sieci, na której to rozwiązanie będzie pracować, więc musimy zapewnić bezpieczeństwo poprzez szyfrowanie. Cała komunikacja jest szyfrowana point-to-point i wszystkie informacje, które przechodzą, są zabezpieczone przed podsłuchem, manipulacją.

Aleksander, czym dla Ciebie jest cloud native?

Aleksander Witkowski: Tomek wyczerpał temat, ale podejście cloud native rozumiem jako pisanie od podstaw aplikacji, w której z założenia zakładamy, że będzie działać w cloudzie. To znaczy, że dzielimy daną funkcjonalność na mikroserwisy, które komunikują się ze sobą za pośrednictwem ustalonych interfejsów. Każdy z mikroserwisów odpowiada za mały fragment większego procesu, ponadto nie są one ze sobą tak mocno powiązane, jak miało to miejsce w monolitycznej architekturze.

Dlaczego Ericsson zdecydował się na wykorzystanie tego podejścia? Jakie problemy rozwiązujecie dzięki temu?

Aleksander: Zdecydowaliśmy się na cloud native ze względu na kilka aspektów. W tym podejściu dostajemy łatwość skalowalności, redundancję. Produkt tworzony w tym podejściu jest bezpieczny – gdy jeden mikroserwis zrestartuje się, Orchestrator zapewni nam podniesienie następnej instancji. W produktach telekomunikacyjnych jest to istotne, by dostępność sieci była wysoka. W cloud native dostajemy ją „out of the box”, kiedyś trzeba było samemu to zapewnić. Tak samo jest ze skalowalnością – w momentach większego zapotrzebowania na usługi możemy po prostu ruch sieciowy odpowiednio przeskalować w górę a np. w nocy w dół (oczywiście w ramach dostępnych zasobów).

Pracujemy w obszarze sieci 5G i sama standaryzacja zakładała podejście cloud native, a mówiąc konkretniej wymagała pracy na mikroserwisach.

Tomasz: Z racji doświadczenia wydaje mi się, że dla Ericssona technologia cloud native to nie była rewolucją a raczej ewolucją. Już w poprzednich generacjach oprogramowania (2G, 3G czy 4G) zawsze nasze produkty były traktowane jako zestaw węzłów, funkcjonalności, które musiały się ze sobą komunikować. Były to takie makroserwisy, które teraz podzieliły się na mikroserwisy. Zawsze to była kwestia odbierania, przetwarzania i przesyłania jakichś informacji, wiadomości w konkretnych protokołach. Teraz po prostu tylko przenosimy się na ustandaryzowaną wersję takiej architektury, gdzie wszystko dzieje się w protokole https.

A co w sytuacji, kiedy mamy już projekt i chcemy go trochę przemianować, wykorzystując podejście cloud native? Czy mieliście taki przypadek w Ericssonie i na jakiej podstawie podjęliście decyzję, że zostajecie przy poprzednim wyborze lub przechodzicie na cloud native?

Tomasz: Wydaje mi się, że mieliśmy taki przypadek, gdzie próbowaliśmy opakowywać monolityczne aplikacje w chmurę, czyli kontenery czy też maszyny wirtualne. Na dłuższą metę nie zdaje to “egzaminu”, bo wciąż mamy duże, ciężkie obrazy i duże serwisy, które ciężko jest zeskalować czy poprzenosić pomiędzy węzłami. Myślę, że wielkość i złożoność aplikacji są głównymi przeszkodami, żeby robić właśnie takie pierwsze próby przenoszenia dużych monolitów do chmury. Złożoność w sensie tego, że w ramach jednego serwisu działa nam i frontend, i backend, a do tego baza danych. Zależności pomiędzy nimi prowadzą do tego, że tak opakowany serwis nie zachowuje się, jak chmurowa aplikacja. Jeśli “wysypie się”, orchestrator powinien postawić automatycznie nowy, żeby zapewnić ciągłość ruchu. Jeśli taki serwis wymaga kilkadziesięciu sekund czy kilku minut, aby się zainicjalizować, to w pewnym sensie mamy zgrzyt. Nie działa to tak, jak powinno.

Złożoność jest jednym z kryteriów tego, jeśli chcemy przejść na cloud native i mamy bardzo dużą aplikację, to nie możemy tego zrobić w taki naiwny sposób, że zamkniemy tę aplikację w kontenerze czy też w podzie i będziemy traktować ją jako cloud native. W takim przypadku musimy tę aplikację podzielić na mikroserwisy, to zalecany i najlepszy sposób postępowania.

Co w sytuacji, gdy mamy małą, monolityczną aplikację?

Tomasz: W momencie, gdy mamy małą aplikację, nawet monolityczną, w której mamy bazę danych i jakiś tam frontend, backend, to wtedy zamknięcie jej w kontenerze spowoduje, że będzie podobna do pojedynczego mikroserwisu. W momencie, gdy mamy zupełnie mały projekt, to moim zdaniem nie ma sensu rozbijać go sztucznie na jeszcze mniejsze fragmenty (nanoserwisy), bo koszty związane z komunikacją, zapewnieniem zgodności między interfejsami będą zbyt wysokie w stosunku do zysków.

Jak wygląda Wasze podejście do wykorzystania cloud native w produktach telekomunikacyjnych? Ciekawi mnie jak to wygląda od środka, jak przygotowujecie się do pracy na mikroserwisach.

Aleksander: Pytasz o to, jak zabieramy się za projektowanie funkcjonalności? W moim odczuciu na początkowym etapie wygląda to tak samo jak w przypadku aplikacji monolitycznych – od rozbicia dużego problemu na mniejsze elementy. Potem każdy taki mniejszy element można przemapować na konkretne mikroserwisy. Staramy się, by dany mikroserwis rzeczywiście był mikroserwisem, który odpowiada za jedną małą funkcjonalność. Produkty telekomunikacyjne, przy których pracujemy, nie są małe. Mamy więc architektów, którzy nas wspierają w odpowiednim doborze. Każde rozwiązanie jest też dyskutowane w zespole, a czasem w szerszym gronie. Finalnie mamy ustaloną architekturę rozwiązania – jakie mikroserwisy są nam potrzebne oraz jak będą miały się ze sobą komunikować. Od tego etapu możemy już pracować nad implementacją.

Tomasz: W pewnym sensie całe to wykorzystanie architektury mikroserwisowej jest też obwarowane standardami. Akurat w telekomunikacji te standardy mają bardzo duże znaczenie, bo jako producent oprogramowania zapewniamy poprzez stosowanie standardów to, że nasza część oprogramowania będzie współpracować z oprogramowaniem innych producentów. To nie jest tak, że produkujemy całe, kompletne rozwiązanie sieci. Udostępniamy standardowe zachowanie, standardowe interfejsy, standardowe funkcjonalności sieciowe, które można łączyć z rozwiązaniami innych producentów. I też standardy dla 5G mocno koncentrują się na tym, żeby te rozwiązania były zaimplementowane w podejściu cloud native. To znaczy, żeby były bardziej funkcje sieciowe niż jakieś konkretne węzły, jak było w poprzednich generacjach.

Czy Waszym zdaniem cloud native to technologia przyszłości? Czy warto iść w tym kierunku?

Aleksander: Na pewno to technologia najbliższej teraźniejszości, wiele firm z niej korzysta. Na pewno jest na czasie.

Tomasz: Moim zdaniem cloud native jest technologią na dziś i jutro. Nie wiemy, co się pojawi za kilka lat, być może coś ją zastąpi, ale na dzisiaj na pewno jest to technologia, w którą warto się zaangażować.

Poznaliśmy już zalety cloud native, ale co jeszcze przemawia za tym, że poznać bliżej to podejście?

Tomasz: Projekty, które wymagają dużych zasobów (CPU, RAM, Network) korzystają z technologii cloud native. W gratisie dostajemy wszystko to, o czym wcześniej już było mówione: skalowalność, robustness, zarządzanie awariami, łatwość aktualizacji, zmian, wprowadzania poprawek itp.. Dostawca sprzętu dba o jego wydajność, sprawność a my koncentrujemy się na warstwie softwarowej. Dlatego ta technologia jest dobrze dopasowana do dużych produktów.

Z drugiej strony z małymi produktami też jest tak, że też trzeba je gdzieś uruchomić. Jeśli chcemy zaczynać gdzieś z małym projektem, czy produktem i wejść na rynek, to też musimy mieć jakiś sprzęt, moc obliczeniową, na której ten nasz mały projekcik będziemy stawiać. Wtedy warto zacząć od cloud native, nawet w wersji z jednym mikroserwisem, czyli nie inwestować w własny sprzęt, tylko wykupić go od dostawcy chmurowego. Da to nam niezależność, pewność, że ktoś, zdejmuje nam z pleców kwestię tego, że musimy to skonfigurować, zadbać o zabezpieczenia, o połączenie z internetem, czyli o wszystkie te rzeczy, o których musielibyśmy pomyśleć, planując klasyczny hosting aplikacji. Dlaczego zatem tworzyć coś własnego, skomplikowanego, skoro możemy używać rozwiązania, które się sprawdza?

Oferty pracy z

Jak wygląda Wasz dzień, schemat pracy przy tego typu systemach?

Tomasz: Pracujemy w metodologii scrumowej, więc standardowo dzień pracy zaczyna się od spotkania zwanego standupem, gdzie synchronizujemy się w ramach teamu. Celem takiego spotkania jest dowiedzenie się, jaki jest status zadań w zespole na konkretny dzień, co jest najważniejsze do zrobienia, czy są jakieś problemy i tematy, którymi trzeba się pilnie zająć, czy po prostu realizujemy przydzielone zadania.

Co z pozostałą częścią dnia?

Tomasz: Poza spotkaniami projektowymi czy rzeczami, które są konieczne z założonego way of working, no to jest standardowa praca developera: czyli analizowanie tego, co jest do zrobienia, analizowanie wymagań, które przychodzą do nas od architektów, od ludzi, którzy zajmują się przygotowywaniem, opracowywaniem tych wymagań, przygotowywanie szkiców i prototypów rozwiązań, oraz implementacja tych rozwiązań. Sporo czasu zajmuje nam testowanie, które u nas stanowi ponad połowę standardowej pracy developera.

Aleksander: W naszym zespole standup odbywa się w połowie dnia i w zasadzie jest to jedyny stały punkt w kalendarzu. A jeśli chodzi o pozostałe rzeczy, to mocno zależy od tego, na jakim etapie pracy nad funkcjonalnością jesteśmy, jaki jest akurat etap życia projektu, czasem jest to wdrażanie nowych funkcjonalności powiązane z testowaniem, czasem tworzenie dokumentacji lub analiza zgłoszonych problemów.

Połowa developmentu rzeczywiście zajmuje testowanie, dokumentacja, analiza błędów, problemów, które zostały zgłoszone, czy to od klienta, czy od ludzi, którzy zajmują się testowaniem na wyższym, bardziej kompleksowym, poziomie.

Jak oceniacie, czy dana osoba odnajdzie się w Waszym zespole? Jakie umiejętności powinna posiadać? Czy trzeba mieć doświadczenie komercyjne?

Tomasz: Wydaje mi się, że jeśli chodzi o nasze projekty, to kluczowymi rzeczami byłyby:

• znajomość platformy Kubernetes, przynajmniej podstawowa, tak żeby wiedzieć, co to jest, do czego służy i jak używa się tego narzędzia,
• umiejętność programowania w dowolnym języku programowania. Nie naciskamy na konkretny język, programujemy zarówno w Golangu, C++, częściowo w Javie, częściowo w Pythonie.

Wydaje mi się, że od dogłębnej znajomości konkretnego języka ważniejsza jest otwartość umysłu i chęć uczenia się. To bardzo istotne, żeby chcieć się uczyć, bo cała ta sytuacja szybko ewoluuje. Co chwilę pojawiają się nowe wymagania, mikroserwisy, narzędzia, biblioteki i cały czas trzeba coś nowego poznawać, trzeba dopasowywać się do zmian, które zachodzą na rynku.

Aleksander: Jedną rzecz chciałbym dodać, podkreślić – nie tylko w kontekście cloud native. W tym zawodzie kluczowa jest chęć i gotowość do ciągłego uczenia się. To zmienia się co chwilę, nawet ludzie, którzy zaczynali swoją karierę nie tak dawno, bo jakieś 3-4 lata temu też muszą się uczyć nowych rzeczy, bo ten rynek zmienia się bardzo szybko, pojawiają się nowe technologie i trzeba być gotowym na to, żeby się danej technologii nauczyć, zgłębić ją. My też w zespole mieliśmy taką sytuację, gdzie zostaliśmy poniekąd zaskoczeni i okazało się, że musimy się nauczyć Golanga. Mieliśmy na to kilka dni, udało się – napisaliśmy ten mikroserwis.

---

Tomasz Bosak. Inżynier systemowy w Ericsson. Zaczynał pracę jeszcze w Ericpolu w 2004 r. jako programista implementujący Inteligentne Systemy w sieciach 2G. W trakcie dalszej pracy (głównie w obszarze sieci szkieletowej – Core Network, ale również w części Radiowej 4/5G) koncentrował się głównie na zagadnieniach testowania oprogramowania oraz wprowadzaniu automatyzacji i innowacji w proces produkcji oprogramowania. W trakcie kariery pełnił role: Dewelopera, Testera, Leadera Technicznego, Scrum Mastera oraz Product Ownera. Poszukując wciąż nowych wyzwań i możliwości, obecnie pracuje nad implementacją sieci szkieletowej dla 5G w technologii cloud-native.

Aleksander Witkowski. Inżynier oprogramowania w Ericsson. Swoją przygodę z Ericssonem rozpoczął w 2012 roku – jako programista w firmie Ericpol. Początkowo pracował w obszarze sieci szkieletowych, następnie w radio oraz przy tworzeniu symulatora ruchu telekomunikacyjnego. Po półrocznej przerwie na projekt niezwiązany z branżą telekomunikacyjną, od 2020 roku ponownie w Ericssonie – w obszarze sieci szkieletowej 5G. Przez większość kariery związany z językiem C++, ostatnio także go.