Monolityczne pakiety aplikacji dominowały w środowiskach IT przez ostatnie 20 lat. Dlaczego więc wyszły z mody?
W 2008 roku, zanim Netflix rozpoczął słynną „przeprowadzkę” na opartą na chmurze architekturę mikroserwisów, jeden brakujący średnik w kodzie spowodował wyłączenie całej witryny na kilka godzin. Posiadanie całego systemu, który jest potencjalnie pojedynczym punktem awarii, sprawia, że procesy zarządzania i cykle rozwoju są bardzo długie. Stoi to w bezpośredniej sprzeczności z wymogiem stawianym przed firmami, który wiąże się z szybkim reagowaniem na zmieniający się rynek i napędza ewolucję firmowego IT od modelu przedsiębiorstwa tradycyjnego do cyfrowego. Obecnie setki mikroserwisów zapewniają Netflixowi dostępność, skalę i szybkość, których potrzebują do obsługi rosnącej liczby użytkowników i urządzeń, a także pozwalają na nowy poziom odporności na awarie, co pokazuje rozwój podejścia z wyłącznikami do zapobiegania awariom kaskadowym i izolowanie źródła awarii. Więcej o mikroserwisach oraz językach programowania, które warto wykorzystać w ich tworzeniu, eksperci opowiedzą podczas Engineering T@lk, już 10 marca.
Bardziej szczegółowe podejście do architektury zapewnia elastyczność i skalowalność, jakiej wymaga nowoczesny – cyfrowy – biznes. Dziś must have stały się elastyczne platformy, na których można programować, testować oraz hostować systemy, co jest kluczem do realizacji metodyki DevOps. Niezależnie od tego, czy wdrażane systemy nazwiemy konkretnie mikroserwisami, rozbicie monolitu na mniejsze kawałki pozwala na konteneryzację, a w konsekwencji usprawnia wdrożenie i umożliwia sprawne przejście do chmury.
- Najważniejszymi problemami, które rozwiązują mikroserwisy, są: dostarczanie i skalowanie. Są one bardzo ważne zarówno z technicznego, jak i organizacyjnego punktu widzenia. Sprawiają, że cały proces rozwoju oprogramowania staje się bardzo efektywny i pozwalają na wykładniczy wzrost dużych projektów – mówi Artiom Matusenco, Back-end Team Lead w oddziale Capgemini Engineering.
Zwinne mikroserwisy a stałe monolity
Tradycyjnie architekturę programistyczną budowano w podejściu monolitycznym. Centralnym elementem tej metody jest to, że wszystkie części aplikacji są ze sobą bezpośrednio połączone. Naturalną implikacją jest, że każda zmiana w systemie, aplikacji lub interfejsie oznacza, że należy zmienić całość.
- Według IDC, już w tym roku aż 90% wszystkich aplikacji będzie zawierać architektury mikroserwisów, które poprawią możliwości projektowania, aktualizowania i wykorzystywania kodu. Ale czy to zawsze słuszne podejście? Źle zaprojektowana strategia wdrażania mikroserwisów, może prowadzić do ich rozrostu, a bez scentralizowanej kontroli i dyscypliny liczba mikroserwisów będzie rosła wykładniczo i w konsekwencji utworzy środowisko IT, które jest złożone, trudne w zarządzaniu i zamiast usprawnić systemy, ponownie je ograniczy. Dodatkowym ryzykiem jest – paradoksalnie – łatwość korzystania z usług w chmurze, co prowadzić może do wzrostu kosztów potrzebnych do działania serwisów i usług. Architektury mikroserwisów powinny być projektowane w oparciu o domeny biznesowe i ograniczone konteksty, w których każdy mikroserwis służy określonemu celowi wielokrotnego użytku i ma dobrze zdefiniowany zakres. Następnie organizacja musi upewnić się, że ma katalog wszystkich dostępnych mikroserwisów, aby mieć pewność, że nie są one duplikowane lub używane w niewłaściwy sposób – komentuje Artiom Matusenco, Back-end Team Lead w oddziale Capgemini Engineering.
Niezależne mikroserwisy umożliwiają zwinny i niezawodny rozwój
Zastosowanie mikroserwisów w architekturze chmury usuwa niepożądaną sztywność monolitów. Aplikacja zbudowana jako mikroserwis to zbiór luźno powiązanych ze sobą części, z których każda odpowiada za jedną funkcję. Mikroserwisy wchodzą w interakcję na żądanie, ale nie polegają na sobie. Oznacza to, że jeden element aplikacji można zmienić bez konieczności przebudowy wszystkiego. W rezultacie mikroserwisy mogą być rozwijane, utrzymywane i wdrażane niezależnie, co jest ich największą zaletą.
Wyzwanie związane z mikroserwisami polega na spełnieniu wymagań dotyczących wydajności. Ponieważ części aplikacji działają oddzielnie od siebie, komunikacja między nimi jest bardziej złożona i może powodować problemy z wydajnością, które objawiają się opóźnieniami sieci i nieoptymalnymi czasami przetwarzania. Tych problemów można w większości uniknąć dzięki automatyzacji, zwinnym metodykom i narzędziom DevOps.
- Niemal każdy projekt potrzebuje tzw. zestawu startowego, pewnego wzoru ułatwiającego rozpoczęcie prac. Projektowanie nowych rozwiązań wymagałoby czasu na tworzenie, dokumentację i wsparcie oraz wdrożenie programistów podejmujących pracę w danej organizacji, dla których takie wewnętrzne rozwiązanie nigdy nie będzie standardem. W realizacji mikroserwisów często wykorzystujemy third party frameworki takie jak NestJS. To narzuca pewne zasady, strukturę katalogów, koncepcje nazewnictwa plików, sposób tworzenia aplikacji, czy dzielenia ich na fragmenty. Takie rozwiązania stają się powszechne w IT i znacznie ułatwiają pracę. Oczywiście nie ma frameworków uniwersalnych i „do wszystkiego”. Dlatego każdy projekt wymaga głębokiej analizy i wykorzystania odpowiednio dobranych narzędzi. Będę miał okazję opowiedzieć o tym więcej podczas mojego webinaru na Engineering T@lk, który odbędzie się 10 marca – dodaje Artiom Matusenco.
Dywersyfikacja IT jest kluczem
Odejście od starszych rozwiązań IT dla przedsiębiorstw prowadzi do dywersyfikacji technologii, dzieląc procesy biznesowe na struktury, w których bardzo specyficzne, dopasowane do biznesu funkcje są rozdzielone i mogą być hostowane przez różnych dostawców i technologie. Wzrost liczby kanałów, za pośrednictwem których konsument wchodzi w interakcję z daną firmą, zmienia model IT z podejścia opartego na żądaniach na taki, w którym kluczowy czynnik napędzany jest zdarzeniami. Dynamiczny rozwój gospodarczy i technologiczny wpływa na zmianę oczekiwań konsumentów – wymóg natychmiastowej odpowiedzi jest już normą, w związku z czym dział IT musi reagować w czasie rzeczywistym i szybko się skalować, aby sprostać rosnącemu zapotrzebowaniu i nowopowstałym potrzebom. Wszystko to wymaga znacznie bardziej szczegółowego podejścia do dostarczania rozwiązań IT.
- Ważne jest, aby każdorazowo, budując kolejny serwis, aplikować ten sam kod programowania. Ten problem rozwiązuje własny framework/starter kit lub gotowe już rozwiązanie, takie jak NestJS. Umożliwia to programistom wdrażanie wszystkich głównych wzorców integracji w przedsiębiorstwie. Połączenie z technologiami kontenerowymi umożliwia szybkie opracowywanie oddzielonych od siebie mikroserwisów i lepiej obsługuje model DevOps z rozbudowanymi narzędziami do ciągłej integracji. Niewątpliwą zaletą jest możliwość rozwijania mikroserwisów przy użyciu wybranego języka lub nawet mieszanki języków. To wprowadza pewną elastyczność pod kątem różnic w umiejętnościach zespołów, bo implementacja niekoniecznie musi być taka sama. Jednakże, każdorazowo, budując kolejny serwis, optymalnym rozwiązaniem jest wykorzystanie gotowych frameworków lub starter kit’ów, co pozwala na oszczędność czasu i większą efektywność – mówi Artiom Matusenco.
Wpływ mikroserwisów na biznes
Ogólnie rzecz biorąc, zwiększona elastyczność programowania zapewnia większą szybkość i skalowalność. Architektura oparta na mikroserwisach pozwala firmom na szybsze wdrażanie kompletnych aplikacji w bardziej kontrolowanej kolejności. Niewątpliwą zaletą mikroserwisów jest także zwiększona niezawodność. W architekturze monolitycznej awaria jednej części spowoduje awarię całego systemu. W przypadku mikroserwisów awaria jednej części aplikacji nie wyłącza wszystkiego innego, a problemy są ogólnie łatwiejsze do zidentyfikowania i naprawienia.
Niezależnie od tego, czy architektura mikroserwisów stanie się preferowanym stylem programowania w przyszłości, jest to potężny pomysł, który oferuje poważne korzyści przy projektowaniu i wdrażaniu aplikacji korporacyjnych. Zespół Capgemini Engineering buduje obecnie systemy wykorzystujących architekturę mikroserwisów, a podejście to stosują i faworyzują inne duże organizacje, takie jak choćby Netflix czy Amazon. I choć dotychczasowe doświadczenia w porównaniu z aplikacjami monolitycznymi są pozytywne, to oczywistym jest, że architektura powinna mieć czas na to, aby dojrzeć, a ludzie – zdobyć niezbędne umiejętności, zanim podążą za trendem. Tylko wtedy wdrożenia będą bezpieczne i efektywne.
Już 10.03 Capgemini Engineering zaprasza do udziału w webinarze Engineering T@lk w czasie, którego ekspert Artiom Matusenco, Software Engineer w Capgemini Engineering podzieli się własnym doświadczeniem w budowaniu mikroserwisów opartych na frameworku NestJS. W czasie blisko godzinnego wykładu opowie on o wymaganiach technicznych dla NestJS, które są niezbędne przy tworzeniu mikroserwisów oraz w jaki sposób framework może przyjść z pomocą.
