Wywiad: kiedy architektura monolityczna jest dobrym pomysłem?

Marta Skiba: temat naszej rozmowy jest dość przewrotny. Jednym z dominujących obecnie tematów jest przejście z monolitu na architekturę mikrousług. Jednak rzeczywistość nie jest przecież wyłącznie czarno-biała?

• Filip Dziedzic: [śmiech] masz rację. Dodatkowo nasze wielokrotnie powtarzane motto brzmi „to zależy” i znajduje doskonałe zastosowanie także w tej kwestii. Podejście monolityczne uznawane jest za zdecydowanie bardziej konserwatywne. Mikroserwisy, dzięki stałemu rozwojowi infrastruktury chmurowej, utożsamiane są z nowoczesnością. Z pozoru to dwa odległe bieguny i wybór może wydawać się oczywisty. Jednak w przypadku oprogramowania IT często to, co oczywiste, nie spełnia swego zadania w praktyce. A przecież do tego powinniśmy dążyć.

Marta Skiba: w takim razie nie zazdroszczę inwestorom, którzy muszą podejmować konkretne decyzje biznesowe…

• Filip Dziedzic: inwestorzy najczęściej polegają w tym względzie na doświadczeniu wykonawcy. Nawet, gdy zgłaszają się od nas z konkretnym pomysłem nie poprzestajemy na nim. Rolą dobrego wykonawcy systemu dedykowanego jest jak najlepsze poznanie specyfiki działań klienta. Należy wziąć pod uwagę nie tylko budżet projektu, ale przede wszystkim dynamizm rozwoju charakterystyczny dla całego sektora gospodarki i perspektywę biznesową klienta przyjętą na najbliższe lata. Bardzo często to architektura monolityczna sprawdzi się lepiej na start. Zarządzanie architekturą rozproszoną wymaga przecież sporego doświadczenia. Nie każda firma musi ponosić koszty z tym związane.

Marta Skiba: czyli kompleksowe podejście to podstawa? Prawdziwa sztuka polega na indywidualnym dostosowaniu architektury systemu do konkretnego klienta?

• Filip Dziedzic: dokładnie w tym tkwi istota oprogramowania dedykowanego. To sztuka indywidualnego podejścia, użyteczności i zapewnienia optymalnych doznań użytkowników. Nie można też zapominać o opłacalności całego przedsięwzięcia. Architektura monolityczna, dzięki pracy na jednym, wspólnym kodzie, zapewnia szybkie wstępne wdrożenie. Sprawdzi się bardzo dobrze w przypadku tych systemów, które nie są zbytnio rozbudowane lub w tych branżach, w których nie obserwujemy zbyt dużej dynamiki wzrostu. Mikroserwisy natomiast zapewniają wyższą autonomię i skalowalność. Jednak zarządzanie nimi już na etapie prac projektowych stanowi wyzwanie. Często spotykanym podejściem jest rozpoczęcie prac na monolicie, a jeśli pojawiają się bardziej złożone potrzeby w przyszłości, zapewnienie sprawnej migracji monolitu do mikrousług. Wszystko rozpatrywane w kontekście ROI i indywidualnych celów biznesowych klientów.

Marta Skiba: każde podejście ma więc swoje plusy i minusy. Skoncentrujmy się zatem na pokazaniu podstawowych kryteriów, jakie warto wziąć pod uwagę przy wyborze architektury nowego systemu. Gotowy?

• Filip Dziedzic: jasne! Z tym pytaniem mierzymy się przecież w przypadku każdego klienta. Trzeba podkreślić, że siłą architektury monolitycznej jest jej prostota. Łatwo monitorować jeden kod, testować wprowadzane zmiany. Często już na etapie projektowym monolit można opracować niezwykle sprawnie. Podobnie przebiega też jego wdrożenie. Oczywiście, gdy architektura systemu jest przejrzysta. W przypadku mikrousług sytuacja jest bardziej złożona. Projektujemy tu bowiem i wdrażamy system oparty na autonomicznych usługach, które połączone są ze sobą siecią wzajemnych zależności. W przypadku prostych systemów często rozproszenie całego kodu wydaje się być niepotrzebnym wydatkiem. Najważniejsze to zestawić założenia projektowanego systemu z realnymi potrzebami i możliwościami klienta. Tylko takie podejście przyniesie zamierzone efekty.

Marta Skiba: czyli architektura monolityczna jest „łatwiejsza” bo wszystko jest zawarte w jednym kodzie źródłowym?

• Filip Dziedzic: zespół projektowy działa tu na jednym kodzie, jednak określenie „łatwiejsza” tu nie pasuje. W tworzeniu oprogramowania dedykowanego nigdy nie ma łatwych ścieżek i prostych decyzji, ale są takie, które są bardziej dostosowane do wymagań. Owszem, aplikacje monolityczne są łatwe do debugowania, wyraźnie widać tu np. połączenia między poszczególnymi elementami systemu (zakładając, że rozmawiamy o poprawnie zaprojektowanym i zaimplementowanym tzw. modularnym monolicie). Wdrożenie również nie przysparza problemów, bo wszystkie dane zawarte są zwykle w jednym katalogu. Zaznaczam przy tym, że system musi być względnie prosty.

Marta Skiba: to wszystko wydaje się chyba zbyt… proste…

• Filip Dziedzic: kusisz, żeby powiedzieć tradycyjne „to zależy”. Faktem jest jednak, że architekturę monolityczną, jako tradycyjne podejście, zna większość programistów. Metodyki pracy są rozpowszechnione powszechnie i nie trzeba poświęcać dodatkowego czasu na szkolenie zespołu programistów. Chyba właśnie z tego powodu to wszystko może wydawać się proste. Jednak nie możemy patrzeć wyłącznie optymistycznie na to podejście.

Marta Skiba: czyli są też słabe punkty?

• Filip Dziedzic: ta słabość pojawia się wtedy, gdy trzeba sprawnie rozwinąć aplikację monolityczną. Każda modyfikacja powinna tu być przeprowadzana w sposób przemyślany z zachowaniem najwyższej ostrożności. Nawet z pozoru drobna zmiana może zaburzyć funkcjonowanie całego systemu. Sytuacja wygląda podobnie w przypadku skalowania: nawet jeśli zależy nam na jednym module i tak musimy skalować w tym samym czasie cały system.

Marta Skiba: mikroserwisy stanowią rozwiązanie tych problemów?

• Filip Dziedzic: wykorzystanie tego podejścia potrafi błyskawicznie rozwiązać wiele problemów przedsiębiorstw. Przede wszystkim pojedyncze usługi można wdrażać i rozwijać szybciej. Mamy tu do czynienia z lepszą skalowalnością oraz większą autonomią. Problemy pojawiają się wówczas, gdy zaczynamy uznawać mikroserwisy za złotą receptę na wszystkie trudności. Po pierwsze, jeśli zespół projektowy nie ma dużego doświadczenia, to nawet optymalnie dopasowana do przedsiębiorstwa architektura mikroserwisów nie będzie działać poprawnie. Ogromnie ważna jest też przejrzysta struktura i hierarchia mikrousług. Bez tego wprowadzanie zamian czy aktualizacji może wyrządzić sporo szkody. Mikroserwisy zadziałają tylko wtedy, gdy wszystkie zespoły doskonale zrozumieją zawiłości całego projektu.  

Marta Skiba: dużo więc zależy od zespołu programistów?

• Filip Dziedzic: jeśli zespół programistów jest mały lub budżet projektu nie pozwala na jego zwiększenie realizacja mikroserwisów nie będzie dobrym pomysłem. Specyfika tej architektury wymaga podzielenia pracowników na zespoły, które będą pracować nad rozwojem poszczególnych usług. Optymalnie byłoby, gdyby każdy taki team posiadał różnorodne umiejętności, dopasowane do tego, by prawidłowo wdrożyć i utrzymać tę konkretną usługę. Z tego powodu bardzo często firmy zaczynają od stworzenia systemu opartego na architekturze monolitycznej.

Marta Skiba: czyli wszystko kręci się wokół dopasowania optymalnej metody. Z uwzględnieniem wielu aspektów działań oczywiście

• Filip Dziedzic: właśnie dlatego w tych kwestiach nie ma oczywistych odpowiedzi. Myślę, że warto podsumować nasze rozważania w możliwie najbardziej klarowny sposób. Jeśli od początku wiemy/przypuszczamy, że nowa aplikacja powinna się dynamicznie rozwijać to mikroserwisy wydają się racjonalnym wyborem. W sytuacjach, gdy architektura systemu jest prosta a priorytetem jest szybki start, warto wybrać (modularny) monolit. Oczywiście wszystko należy zawsze rozważać indywidualnie. W Opsenio doskonale to rozumiemy. Na co dzień projektujemy i wdrażamy systemy oparte o architekturę mikrousług i doceniamy jej plusy. Równocześnie wdrażamy efektywne aplikacje monolityczne, które w pełni realizują potrzeby biznesowe przedsiębiorstw. Wybór musi być podyktowany dobrem klienta, nigdy wygodą programistów czy aktualnie panującym trendem.

Marta Skiba: dzięki za te wyjaśnienia. Ale co zrobić, gdy naprawdę nie wiemy, która opcja jest dla nas najlepsza?

• Filip Dziedzic: nic prostszego: porozmawiajmy o tym indywidualnie