Dlaczego duże technologiczne firmy rezygnują z aplikacji monolitycznych? Wyzwania, które stoją przed developerami

Jakie wyzwania stawia przed firmami utrzymanie aplikacji monolitycznych i dlaczego stają się one coraz bardziej problematyczne? Jakie alternatywne podejścia są obecnie preferowane przez duże technologiczne firmy i dlaczego? O tym między innymi rozmawiamy ze Stanislavem Kyrylchukiem, programistą frontend w ASSA ABLOY.

Podczas naszej pierwszej rozmowy wspomniałeś, że duże technologiczne firmy rezygnują obecnie z modelu aplikacji monolitycznych. Dlaczego tak się dzieje?

Istnieje kilka powodów, dla których duże firmy technologiczne często przechodzą z aplikacji monolitycznych na oddzielne aplikacje frontend i backend komunikujące się za pośrednictwem interfejsów API. Ja bym wymienił:

1. Skalowalność (ang. Scalability): podział systemu na mniejsze, niezależne części pozwala na lepszą skalowalność. Czyli każdą część można niezależnie poszerzać i ulepszać w zależności od potrzeb, co z kolei jest wyzwaniem w architekturach monolitycznych frontend.
2. Elastyczność i zwinność: oddzielenie frontendu od backendu umożliwia zespołom niezależną pracę. Zmiany lub aktualizacje jednej części systemu niekoniecznie wymagają zmiany całej aplikacji, dzięki czemu proces programowania jest bardziej elastyczny. 
3. Różnorodność technologii: różne zespoły mogą preferować różne technologie do programowania frontend i backend. Oddzielenie pozwala na użycie różnych zasobów oraz lepszy ich dobór z uwzględnieniem mocnych i słabych stron technologii.
4. Optymalizacja wydajności: oddzielając frontend i backend, wysiłki optymalizacyjne można skoncentrować na określonych obszarach i częściach aplikacji, poprawiając jej ogólną wydajność.

Na dodatek, dzięki podziałowi na backend i frontend i użyciu API do komunikacji, mamy logikę budowania zapytań/odpowiedzi. Z kolei mając tę logikę, można łatwiej sięgać po integrację z zasobami trzecimi, czyli łączyć się z API usług systemów stron trzecich (przykładowo: chatboty, CRM systemy, mailingi). Pozwala to integrować inne systemy, zwiększając funkcjonalność aplikacji bez zmiany jej podstawowej struktury.

Jakie wyzwania stawia przed firmami utrzymanie aplikacji monolitycznych i dlaczego stają się one coraz bardziej problematyczne?

Firmy często zaczynają pracę nad swoim produktem od utworzenia aplikacji monolitycznej. To jest łatwiejsze rozwiązanie, bo zazwyczaj potrzebny jest jeden framework, w którym będzie wszystko się dziać. Ale po latach pracy, powiedzmy za 10 lat, taka aplikacja monolityczna będzie tak mocno rozbudowana, będzie miała tyle różnych części i podsystemów, że do tego często są potrzebne dedykowane zespoły, żeby utrzymywać jakąś konkretną część tej dużej aplikacji. Na dodatek tak duże aplikacje tracą na wydajności, szczególnie jeśli od początku nie założono przemyślanej i skalowalnej architektury.

Ponadto takie aplikacje monolityczne są zależne od wsparcia tej technologii przez jej twórców. Powiedzmy, firma 15 lat temu oparła swój projekt o jakiś framework, który obecnie już albo nie jest wspierany czy regularnie dopracowywany (m.in. chodzi tutaj o luki w zabezpieczeniach), lub twórcy tego frameworka wypuścili nową globalną wersję, która nie wspiera niektórych funkcjonalności ze starej, i co wtedy? Wymagałoby to przerobienia całej aplikacji.

Z kolei jeśli taka aplikacja byłaby od początku podzielona na części frontend i backend, to najwyżej tylko jedna część wymagałaby przejścia na nową globalną wersję czy inną technologię.

Jakie alternatywne podejścia są obecnie preferowane przez duże technologiczne firmy i dlaczego?

Częstym alternatywnym rozwiązaniem są mikroserwisy, czyli architektura, której aplikacja składa się z małych, niezależnie wdrażanych usług czy procesów. Każda usługa zazwyczaj koncentruje się na określonej funkcji biznesowej i może być opracowywana, wdrażana i skalowana niezależnie od innych.

Drugą alternatywą może być Headless CMS. W takim podejściu backend skupia się na dostarczaniu treści dla frontendu przez API. Jest to dosyć podobne podejście do mikroserwisów, lecz dostarcza się content dla kilku aplikacji na różnych platformach.

Na koniec też warto wspomnieć o możliwości stworzenia własnych customowych CMS-ów i aplikacji. Gdy firma poświęca czas, żeby zbudować od zera własny CMS system, bez żadnych frameworków, wtedy architektura może się różnić od tych typowych wymienionych wcześniej.

Czy problemem jest również trudność znalezienia specjalistów, którzy mogą ogarnąć zarówno frontend, jak i backend w kontekście aplikacji monolitycznych?

Moim zdaniem nie jest wielką trudnością znaleźć fullstack developera, który potrafi zrobić projekt od początku do końca. Trudniej jest znaleźć fullstack developera, który by miał tak samo szeroki zakres technologii, co na przykład frontend developer, który na tym po prostu się specjalizuje. Jest to szczególnie ważne przy rozpoczęciu prac nad nowym projektem, kiedy szeroki zakres dostępnych technologii pomaga wybrać optymalne rozwiązanie, jak i w kwestii performance’u czy wygody budowania aplikacji, dopasowanej konkretnie na potrzeby projektu. 

Czy istnieją konkretne umiejętności, które developerzy powinni posiadać, aby skutecznie radzić sobie z bardziej złożonymi i zdecentralizowanymi projektami?

To jest zależne od stacku technologii, ale istnieją pewne umiejętności, które dobrze się sprawdzą w bardziej złożonych i zdecentralizowanych projektach. Przede wszystkim jest to dobre rozumienie REST API. Znajomość jego architektury, korzystanie, a najlepiej doświadczenie w budowaniu REST API jest sporym argumentem przy poszukiwaniu pracy w niemal każdym zdecentralizowanym projekcie.

Kolejną rzeczą będzie znajomość i doświadczenie pracy w chmurze. Rozwiązania cloudowe coraz bardziej zyskają na popularności, powstaje więc coraz więcej ofert pośrednio lub bezpośrednio związanych z tą technologią. Jedynym „problemem” jest to, że często firmy wymagają nie tylko znajomości, ale też certyfikatu z technologii chmurowych, a certyfikacja nie jest darmowa i wymaga poświęcenia sporej ilości czasu, żeby do tego się przygotować.

Dodatkowo umiejętność korzystania z Dockera stanowi istotny element w kontekście bardziej złożonych projektów. Docker to narzędzie do konteneryzacji, co oznacza, że pozwala izolować aplikacje i ich zależności w jednostkach zwanych kontenerami. Dzięki temu można łatwo przenosić aplikacje między różnymi środowiskami, co ułatwia zarządzanie infrastrukturą i zapewnia spójność działania aplikacji w różnych warunkach. Wiedza z zakresu Dockera jest szczególnie cenna w projektach zdecentralizowanych, gdzie skomplikowana infrastruktura i elastyczność w zarządzaniu zasobami są kluczowe.

Jakie są aktualne oczekiwania firm wobec developerów i jakie umiejętności są najbardziej poszukiwane na rynku pracy? 

Od kilku lat śledzę rynek pracy IT i powiem szczerze: moim zdaniem często te wymagania są za wysokie albo źle skonstruowane. W ofertach pojawiają się długie listy wymagań, wśród których znajdują się technologie, które spokojnie można zastąpić znajomością innych. A na końcu często i tak okazuje się, że w pracy używamy tylko części narzędzi z tej listy.

Ciekawa też jest sytuacja co do wymaganego stopnia umiejętności. Nie raz widziałem wymagania na Junior Developera znacznie większe, niż na Middle Developera, czy nawet na Seniora.  

Chciałbym jeszcze wspomnieć o jednej rzeczy, o której coraz częściej się mówi. Obecnie developer musi spędzać godziny po pracy na rozwój i śledzenie zmian w technologiach, zwłaszcza jeśli chcesz być dobrym specjalistą w swojej dziedzinie. Dobrze, jeśli godziny na samorozwój są wliczone w godziny pracy, ale nie wszędzie się to udaje. Często więc praca programisty robi się stylem życia, w którym siedzisz ponad 10 godzin dziennie przed monitorem, żeby być na bieżąco przynajmniej w swojej dziedzinie, nie mówiąc już o innych obszarach.

Dlatego więc firmy i rekruterzy szukają takich programistów, którzy stawiają na rozwój i siedzą w tym programowaniu nie tylko 8 godzin przez 5 dni w tygodniu, ale też nieco “żyją” tym. Bo jeśli utkniemy w jednym miejscu, to po pewnym czasie umiejętności zdobyte wcześniej mogą się okazać już nieaktualne. Tak jest m.in. w programowaniu web i mobilnych aplikacji. Przykładowo, to, co robił frontend developer 5 lat temu i co robi teraz, to są różne rzeczy.

Odpowiednio więc zmieniły się wymagania. Współczesny frontend developer musi faktycznie umieć programować, czyli znać się na pętlach, komunikacji z bazą danych, architekturze API, tablicach, zmiennych, zarządzaniu stanu aplikacji, konteneryzacji projektu, powinien też się znać na architekturze i konfiguracji środowiska, i jeszcze mnóstwo innych rzeczy, a nie tylko HTML, CSS i jeszcze coś tam może z JavaScripta i/lub jQuery. 

Jaki jest optymalny zakres i stopień wiedzy, którym obecnie powinien charakteryzować się programista, aby być atrakcyjnym kandydatem dla firm?

Warto od razu powiedzieć, że rynek bardzo szybko się zmienia, szybko też się zmieniają technologie i trendy, szybko więc zmieniają się wymagania, szczególnie te dotyczące frontendu, na którym się skupiam w swojej pracy przez ostatnie lata. Często jest tak, że aktywny zawodowo programista, który przepracował kilka lat w jednym miejscu, chce znaleźć nową pracę, ale okazuje się, że brakuje mu pewnych kompetencji czy technologii, bo na rynek weszły nowe technologie, frameworki, lub też nowsze wersje tych dotychczasowych. Musi więc spędzić pewną ilość czasu, żeby się podszkolić, mimo że cały czas pracował jako developer. 

Jeśli chodzi o optymalny zakres umiejętności i wiedzy w obecnych warunkach, to praca z API, umiejętność samodzielnego rozwiązywania problemów, znajomości frameworków i najnowszych zmian i praktyk, które są stosowane w tej dziedzinie, są podstawowymi wymaganiami. Kwestie wydajności też bardzo często są poruszane nawet na rozmowach rekrutacyjnych. Mile widziana jest znajomość technologii chmurowej, a także praca z aplikacjami mobilnymi. Smartfony teraz są liderami wśród urządzeń, i często firmy, które zaczynają z web, dążą ku rozszerzeniu na mobilne platformy. 

Czy w obecnych warunkach rynkowych warto szkolić się w kierunku fullstacka, czy też może lepiej wybrać frontend/backend i rozwijać się w jednym kierunku?

Z mojej perspektywy uważam, że lepszym wyborem jest pójście w specjalizację frontend lub backend, choć fullstack też nie jest złym wyborem. W trakcie pracy i tak często okazuje się, że pewne zagadnienia mieszają się i wymagana jest wiedza zarówno z zakresu frontendu, jak i backendu.

---

Stanislav Kyrylchuk. Pasjonat budowania aplikacji z ponad 5-letnim doświadczeniem jako programista frontend. W branży IT rozpoczynał jako samouk. Dzięki różnorodnym projektom, zarówno w środowisku freelance, jak i w dużych firmach, zyskał unikalną perspektywę w branży IT, którą z zapałem dzieli się z innymi.

Zdjęcie główne pochodzi z Envato Elements.