7 GRZECHÓW ARCHITEKTURY MONOLITYCZNEJ

W inżynierii oprogramowania monolitem nazywamy aplikację, która ma strukturę jednowarstwową lub gdy interfejs użytkownika i warstwa dostępu do danych są połączone w jeden moduł programu. Taka aplikacja jest niezależna od innych komponentów, nie wymienia żadnych danych i nie potrzebuje innych systemów do działania. 

Grzech 1

Utrapienie we wdrożeniu

Szybkość jest kluczowym czynnikiem, na jaki zwracamy uwagę w kontekście działania systemów informatycznych. 

Im większa jest aplikacja, tym więcej czasu potrzeba na wdrożenie i uruchomienie jej. Ma to ogromny wpływ na produktywność programisty pod względem czasu oczekiwania na wystartowanie kontenerów. Wpływa to również na czas wdrażania oraz liczbę potencjalnych błędów, jakie wyjdą w środowisku produkcyjnym.

Grzech 2 

Trudności w skalowaniu aplikacji

Ta architektura może być skalowana tylko wertykalnie, poprzez dokładanie zasobów serwera. Takie mikroserwisy, przy rosnącym wolumenie transakcji, możemy skalować poprzez uruchomienie większej liczby instancji aplikacji. W chmurze możemy nawet dynamicznie zmieniać liczbę instancji serwisu na podstawie obciążenia. Dodatkowo w przypadku architektury monolitycznej nic nie poradzimy przy rosnącej ilości danych, nawet skalowanie zasobów ma swoje granice sprzętowe.

Grzech 3

Różnych elementów aplikacji nie można skalować niezależnie

Na różnych poziomach zastosowania, komponenty mają różnorodne wymagania. Jedne mogą wymagać dużej ilości pamięci, podczas gdy inne będą miały zapotrzebowanie na dużą moc obliczeniową. Nie mamy innej możliwości, jak dodawać zasoby do całego systemu. Dodatkowo pojedynczy punkt awarii może zakłócić całą funkcjonalność aplikacji monolitycznej.

Grzech 4

Wysoki próg wejścia w rozwój systemu

Podczas pracy nad monolitem ilość linii kodu implementacji przeraża nowych programistów. Ta architektura okazuje się trudna do zrozumienia, a także do zmiany. Proces programowania jest spowolniony, ponieważ nie ma wyznaczonych granic odpowiedzialności modułów. To sprawia, że ​​takim oprogramowaniu trudno wprowadza się wymagane zmiany i ciężko utrzymać zadowalającą jakości kodu.

Grzech 5

Trudności w ciągłym dostarczaniu (continuous delivery) systemu

Częste wdrożenia stanowią wyzwanie dla dużych aplikacji monolitycznych. Jeżeli chcesz zaktualizować komponent architektury monolitycznej, musisz ponownie wdrożyć całą aplikację. Powoduje to problemy, ponieważ przerywa wszystkie zadania bieżące, niezależnie od tego, czy zmiana wpłynęła na nie, czy też nie.

Istnieje również możliwość, że niezaktualizowany moduł nie zadziała poprawnie, jeśli nie został dostosowany do reszty systemu. W rezultacie zwiększa się zagrożenie związane z ponownym wdrożeniem, co zniechęca do regularnych aktualizacji. Jest to szczególnie problematyczne przy szybko zmieniających się wymaganiach biznesowych. W większości przypadków użytkownicy potrzebują szybkich zmian i co wymusza częste wdrażania całego środowiska.

Grzech 6

Przeszkoda w skalowaniu rozwoju

Architektura monolityczna jest jednym z najstarszych podejść projektowych. Główną jej wadą są ograniczenia w zakresie skalowania rozwoju. Jednym z wyzwań realizowanych w tej architekturze jest niezdolność do samodzielnego wdrażania nowych wymagań biznesowych dla różnych modułów, np. zespół ds. zasobów i zespół księgowy nie mogą rozwijać aplikacji osobno. Podział ten jest możliwy dla innych architektur, które umożliwiają rozdział obszarów funkcjonalnych. W przypadku monolitu wszystkie zespoły muszą koordynować swoje plany rozwojowe i wdrożeniowe, aby osiągnąć sukces. Utrapieniem tego jest zawikłana aktualizacja systemu i zmiany na produkcji.

Grzech 7

Długoterminowe zaangażowania w stos technologiczny

Architektura monolityczna sprawia, że programiści biorą “ślub” z określoną wersją stosu technologicznego. Technologię wybiera się w początkowej fazie projektu i decyzja ta jest wiążąca i kłopotliwa do zmiany. Utrudnia to programistom stopniowe wdrażanie nowych technologii, które powstają po starcie projektu. Niektóre biblioteki nie będą dobrze działać w innych wersjach, dlatego w przypadku ich przestarzałości oznacza to konieczność przepisania innych modułów aplikacji. Jest to przedsięwzięcie wysoce ryzykowne i wymaga ponownych testów całości.

Podsumowując, architektura monolityczna przy dużych systemach informatycznych sprawia, że stają się one nieelastyczna, kosztowne i trudno programistom czerpać przyjemność z pracy nad takim oprogramowaniem.