Cześć, dzień dobry. Witam was w podcastzie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruje do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 27. Mikroserwisy kontra monolit.

Jaką architekturę wybrać dla rozwiązania dedykowanego? Poradnik dla osób nietechnicznych. Wyobraź sobie, że otrzymujesz kilka ofert od różnych software house'ów na zbudowanie oprogramowania w 100% dedykowanego. Oferty te będą zawierały kilka aspektów technicznych.

Opis technologii powinny także zawierać opis architektury, jaka zostanie wykorzystana dla twojego projektu. Może tam się pojawić kilka przypadków typu właśnie mikroserwisy, typu monolity, typu modularne monolity, a czasem też jeszcze inne opcje. No i teraz pytanie, jaką architekturę wybrać i jak podjąć taką decyzję finalnie ważną biznesowo jako osoba finalnie nietechniczna? O tym opowiem w dzisiejszym odcinku bardzo szybko, bardzo krótko i zwięźle, tak żeby takie kluci przedstawić.

Zatem nie przedłużając, serdecznie zachęcam do przesłuchania części merytorycznej. Cześć, dzień dobry. Witam serdecznie w 27 odcinku mojego podcastu, gdzie poruszamy temat architektury oprogramowania.

Teraz obiecałem, że będzie krótko i zwięźle, więc postaram się wyrobić do 15 minut trwania tego odcinka. No i od razu przechodzę też do konkretu. Na początek architektura oprogramowania.

Wyjaśnimy sobie szybciutko to pojęcie, czym jest owa architektura. Jest to sposób, w jaki budujemy system. Czyli można to porównać niejako do budowy domu w pewien sposób.

Mamy różne domy w różny sposób budowane, ale to co je łączy to to, że dla każdego domu wybieramy jakieś fundamenty, sposób organizacji przestrzeni, podział na pomieszczenia, dostępność dla mieszkańców, jakieś indywidualne udogodnienia, które ktoś chce zrobić takie stricte pod siebie. I podobnie jest właśnie w oprogramowaniu, czyli sposób w jaki zaprojektujemy nasz system. On ma później ogromne znaczenie dla dalszego rozwoju, dla kosztów utrzymania, ale też dla łatwości wprowadzenia zmian, dla aspektów bezpieczeństwa, czy dla aspektów skalowania tego systemu.

To co jest istotne na wstępie, jak już wiemy czym jest architektura oprogramowania, to to, że każda oferta od Software House'u powinna zawierać informacje o tym, w jakiej architekturze system będzie budowany i dlaczego akurat w takiej. I teraz to jest bardzo ważny aspekt i dlatego wspominam o nim już na samym początku. Sprawdźcie proszę w swojej ofercie, czy w swoich ofertach, czy na pewno taki zapis się pojawił, jeżeli się nie pojawił, warto o to dopytać, bo to może być też istotna rzecz, która wpływa na przykład później na różnice w cenach, że jedna oferta jest taka, a druga jest droższa, czy też tańsza.

Tutaj wziąłem na warsztat trzy sposoby tworzenia tej architektury oprogramowania. Monolit, modularny monolit i mikroserwisy. No i teraz właśnie, zacznijmy sobie od tego monolitu.

To jest tak naprawdę najprostsze rozwiązanie, które można spotkać. Monolit to taki jeden spójny system, w którym wszystkie funkcjonalności i elementy działają w ramach jednej aplikacji. Czyli możemy sobie wyobrazić jeden duży dom, w którym wszystkie pomieszczenia są połączone i działają jako taka jedna całość.

I też jeżeli chcemy coś dodać lub zmienić jakieś funkcjonalności w tym monolicie, musimy po prostu często też dotknąć jakichś innych części systemu, co może wymagać bardziej kompleksowych zmian. Teoretycznie w ramach monolitu da się też oczywiście podzielić tą konstrukcję, żebyśmy mieli osobne piętry, osobne pomieszczenia, ale koniec końców to będzie wszystko ze sobą bardzo połączone i zgrane jako taka właśnie jedna całość, więc robienie zmian na pierwszym piętrze może czasem powodować potrzebę zmiany też na piętrze drugim, idąc za analogią domu. Teraz króciutko wady i zalety monolitu, żeby tutaj to też wybrzmiało.

Na pewno zaleto monolitu jest to, że jest to pewnego rodzaju prostota, no bo jest on prosty do budowy i wdrożenia, taki szczególnie na początku, kiedy chcemy właśnie zmniejszyć koszty początkowe, co też jest taką dodatkową zaletą, to ta prostota w tym pomaga i samo zarządzanie, utrzymanie tego systemu z pewnością będzie tańsze, szczególnie na początku, bo mamy jednak jeden system, jedną aplikację, w której wszystko jest zawarte, więc nie musimy się martwić koordynacją zmian pomiędzy różnymi elementami, tak jak to będzie w przypadku innych rodzajów architektury. Wado monolitu jest to, że z uwagi na to, że wszystko jest razem, to w miarę rozbudowy systemu wprowadzanie zmian staje się coraz bardziej skomplikowane, czyli jest on właśnie mniej elastyczny na rozwój. No i po drugie, on jest trudniejszy w skalowaniu, czyli kiedy wiemy, że nasz system będzie rósł raczej dynamicznie, no to ten monolit niekoniecznie będzie najlepszą opcją w kontekście skalowalności.

I teraz, kiedy warto wybrać monolit? Uważam, że wtedy, kiedy oprogramowanie jest stosunkowo proste i lub tak naprawdę, kiedy zależy Ci na szybkim jego wdrożeniu, szczególnie na początek, kiedy ktoś już przychodzi z wizją, że chciałby oprogramowanie dedykowane, bo z różnych względów wychodzi mu tak po prostu najkorzystniej już na etapie rozwoju biznesu tej osoby, to wówczas monolit na start, jako architektura, z reguły będzie wystarczający, ale tutaj najważniejsze, to co należałoby zapamiętać, to to, że jest to rozwiązanie najprostsze. Drugie rozwiązanie to mikroserwisy, czyli architektura mikroserwisowa. I teraz czym są te mikroserwisy? Mikroserwisy to takie podejście, gdzie dzieli się jedną dużą aplikację na mniejsze, niezależne aplikacje, inaczej zwane właśnie tymi mikroserwisami.

Każdy taki mikroserwis odpowiada za konkretną funkcjonalność, czy jakiś zbiór funkcjonalności, czyli na przykład jeden mikroserwis obsługuje użytkowników, inny może obsługiwać zamówienia, jeszcze inne płatności, czyli da się z tego zrobić takie mikroprodukty. I teraz każdy z tych mikroproduktów, mikrousług może być tworzony, rozwijany i skalowany przede wszystkim zupełnie oddzielnie. Traktujemy to jako zupełnie różne aplikacje, gdzie z perspektywy użytkownika, i to jest bardzo ważne dla osób nietechnicznych, bo często mikroserwis przez to, że to są różne aplikacje, to wydaje się, że użytkownicy będą musieli gdzieś być przekierowywani między tymi aplikacjami i tutaj nie.

Tutaj chodzi właśnie o to, że to z perspektywy organizacyjnej właśnie kodu, infrastruktury, to są różne aplikacje, ale z perspektywy użytkownika, patrząc z perspektywy samego interfejsu użytkownika, to może wyglądać jak jedna aplikacja. Więc tutaj to jest tak. Można to trochę odebrać, czy zrozumieć na poziomie zamiast jednego dużego domu wielorodzinnego, kilka mniejszych domów, gdzie w każdym jest dana rodzina, czy w jednym domu mieszkają znajomi, w innym mieszka rodzina, w jeszcze innym mieszka ktoś zupełnie inny, czyli każdy z przedstawicieli danego pokolenia inaczej będzie się zachowywał.

To możemy rozumieć jako te odrębne zachowania, jako odrębne funkcjonalności w tym wypadku, no i teraz każdy taki mniejszy dom będzie odpowiednikiem tego pojedynczego mikroserwisu. I teraz zaletą mikroserwisu jest ta skalowalność, o której wspominałem, czyli właśnie to, że możemy skalować tylko te elementy, które tego faktycznie potrzebują, czyli wiemy, że więcej ruchu pojawia się, czyli więcej użytkowników korzysta np. z jakiejś jednej konkretnej funkcjonalności, to ją można wydzielić jako mikroserwis.

Łatwiej wprowadzać zmiany, bo każdy ten serwis działa niezależnie, więc wprowadzamy zmiany już w konkretnym serwisie, w konkretnej funkcjonalności i to nie powinno mieć wpływu na pozostałe mikroserwisy. Pojawia się tutaj też taki aspekt elastyczności technologicznej, czyli każdy mikroserwis może być napisany w zupełnie innej technologii, więc to pozwala dostosować technologię jeszcze pod kątem specyfiki danej rzeczy, czyli jeżeli np. zdarza się, że potrzeba np.

parsować jakieś strony, można wykorzystać mikroserwis w Pythonie, ale np. czyli w takim języku programowania, który fajnie wspiera właśnie sam proces skrapowania, a z drugiej strony np. mikroserwis odpowiadający za jakieś funkcjonalności dla użytkowników może napisać np.

w PHP albo w Node.js, czyli w technologiach bardziej ku temu dostosowanych z mojej perspektywy. Jakie są wady mikroserwisów? Na pewno wadą mikroserwisów jest to, że są trudniejsze do wdrożenia na start, czyli tutaj automatycznie też będą wyższe koszty początkowe, no i jest pewna większa złożoność tych mikroserwisów, no bo mimo wszystko one wymagają koordynacji i takiego silnego zaplecza tzw. devopsowego, czyli pod kątem infrastruktury.

Teraz kiedy warto wybrać mikroserwisy? One będą idealnym wyborem, jeżeli będziesz planować budować system bardzo rozbudowany, o dużej skali, który ma też obsługiwać wysokie obciążenia i wysoką dostępność, no i też jeżeli te aspekty bezpieczeństwa są dla Ciebie istotne, bo tutaj też fajnie między mikroserwisami można wydzielić odpowiedzialności i to, do jakich danych dany mikroserwis ma dostęp. Coś, co stosuje się jako taką wersję ala złoty środek, to jest modularny monolit, taka trzecia architektura, o której chciałem Wam dzisiaj opowiedzieć. Teraz tą trzecią architekturę, jak można ją zdefiniować? To jest taki monolit, czyli dom, który ma jedno wielkie pomieszczenie podzielone na moduły, czyli takie części, które działają w jednym systemie, ale mają jasno określone granice i są w pewnym stopniu niezależne.

Idąc za tym przykładem tego, że mamy w mikroserwisach trzy mniejsze domy i w każdym z tych domów mieszka albo grupa znajomych, albo rodzina, albo ktoś jeszcze z innego pokolenia, to idąc tym porównaniem, jakiekolwiek ono nie jest, myślę, że najlepiej to zobrazuje, w modularnym monolicie mamy z jednej strony monolit, czyli duży dom, ale jednocześnie, który ma określony podział na moduły, które możemy rozumieć jako piętra i gdzie na danym piętrze mieszka właśnie dana na przykład rodzina, grupa znajomych, grupa studentów, czy ktokolwiek inny, czyli te różne grupy ludzi, które tutaj w tym przykładzie odzwierciedlają te różne funkcjonalności. Czyli modularny monolit to jest dom z piętrami, gdzie na każdym piętrze mamy ludzi, których łączy coś innego. Teraz zalety modularnego monolitu są takie, że mamy tutaj po pierwsze dość łatwą możliwość wdrożenia tego modularnego monolitu, bo to jest mimo wszystko architektura bliższa monolitowi niż mikroserwisom, ale z drugiej strony mamy też elastyczność rozwoju, bo jeżeli mamy podział na moduły to łatwiej jest wprowadzać zmianę.

Jeżeli mamy potrzebę zeskalować jakiś konkretny moduł tego modularnego monolitu, to możemy go też łatwo zeskalować i potencjalnie nawet wydzielić jako mikroserwis, czy przekształcić w taki mikroserwis ten jeden konkretny moduł, czyli to jedno piętro domu wyciągnąć i z niego sobie zrobić nowy domek obok. Jednocześnie mamy też mniejszą złożoność niż w mikroserwisach i to też fajnie sprzyja zarówno na etapie startu projektu, jak i później też w dalszym rozwoju i jego utrzymaniu. Jakie są wady modularnego monolitu? Na pewno potencjalna utrata pełnej takiej niezależności, czyli mimo wszystko te wszystkie moduły w modularnym monolicie są uzależnione od jednej infrastruktury, ale uważam, że to jest nieduża wada, bo łatwo przejść z modularnego monolitu, wyciągnąć te pojedyncze moduły czy moduł i przenieść je do mikroserwisu.

No i na pewno modularny monolit będzie tym efektywniejszym, im lepiej będzie przemyślany na starcie, więc na pewno pewną wadą czy przestrogą przed tym podejściem jest to, że trzeba to szczególnie dobrze przemyśleć na starcie. I myślę, że to jest dobry model do wyboru, kiedy wiesz, że będziesz potrzebować docelowo skalowania i być może mikroserwisów, ale jednocześnie na start nie chcesz wydawać jeszcze pieniędzy na inwestycje już w mikroserwisy, ale jednocześnie przygotować się do tego na przyszłość, aby to rozwiązanie właśnie było do wykorzystania i na teraz i w przyszłości. Podsumowując ten odcinek, jeżeli chodzi o architekturę, myślę, że tak.

Monolit wybierz wtedy, kiedy potrzebujesz szybkiego wdrożenia, niższych kosztów początkowych i po prostu prostego zarządzenia, lub kiedy twoja aplikacja po prostu nie jest i raczej nie będzie czymś super rozbudowanym. Mikroserwisy wybierz tam, gdzie już wiesz z góry, że to będzie dużo funkcjonalności i rozbudowany system, który wymaga elastyczności, wysokiej skalowalności i niezależnych zespołów, to znaczy, żeby niezależnie można było zarządzać tymi aplikacjami. A modularny monolit wybierz tam, gdzie potrzebujesz kompromisu pomiędzy tym, że musisz wystartować szybko lub w ograniczonym budżecie, ale jednocześnie, że w przyszłości chcesz mieć tą skalowalność.

Uff. Temat techniczny, wytłumaczony biznesowo. Mam nadzieję, że na tyle zrozumiale na przykładzie domu i tych różnych pięter mniejszych domków, że pozwala Ci to dobrze zrozumieć.

Ale jeżeli chciałbyś bądź chciałabyś ten temat zagłębić ze mną bardziej, śmiało zachęcam do kontaktu. Wstępna konsultacja jest bezpłatna i ja bardzo chętnie doradzę już na tej wstępnej konsultacji, w jaką stronę, przynajmniej wstępnie, na Twoim miejscu bym się skierował. Dzięki serdeczne za wysłuchanie dzisiejszego odcinka.

W następnym odcinku opowiem o tym, jakiej klasy system warto wdrożyć dla danej firmy i w jakim momencie jej życia. Także jeśli słyszałeś bądź słyszałaś różne skróty typu CRM, PIM, WMS, SMS czy jeszcze jakiekolwiek inne to ja te właśnie krótkie skróty chętnie wytłumaczę dokładniej. Na przede wszystkim też ich formę użycia i kiedy warto, a kiedy może jeszcze warto się wstrzymać.

Raz jeszcze Ci dziękuję za wysłuchanie dzisiejszego odcinka i do usłyszenia za tydzień we wtorek. Cześć!