Architektura oparta o mikroserwisy zyskuje na popularności. Coraz częściej spotykamy się z publikacjami opisującymi, jak została ona zaadoptowana przy tworzeniu oprogramowania, rozwiązała problemy, a nawet dostarczyła dodatkowe korzyści. Czy jest to jedyny słuszny kierunek, gdy wybieramy architekturę aplikacji?

Czym są i skąd się wzięły mikroserwisy

Żeby lepiej zrozumieć architekturę opartą o mikrousługi, należy zdefiniować, czym jest pojedyncza usługa.

Mikroserwis to niezależne oprogramowanie, które dostarcza funkcjonalność biznesową. Słowo “niezależne” jest tutaj kluczowe i oznacza, że ta usługa może być wdrażana, utrzymywana oraz rozwijana niezależnie od innych części systemu. Gotowe oprogramowanie składające się z mikroserwisów jesteśmy w stanie układać niczym klocki lego – tworząc nowe moduły lub korzystając z uprzednio napisanych komponentów, rozwiązań open source czy też płatnych usług w modelu saas.

Dostrzec można elementy charakterystyczne dla architektury zorientowanej na usługi (SOA) – aplikacja podzielona jest na usługi, których poszczególne elementy są w stanie komunikować się ze sobą. Jednakże architekturę mikrousług dodatkowo wyróżnia luźne powiązanie pomiędzy usługami (ang. loosely coupled) – oznacza to, że potrafią one funkcjonować nawet wtedy, gdy inna część usług jest niedostępna, a dla użytkownika systemu nie powinno to objawiać się niedostępnością całego systemu.

Zalety i wady

Tego typu podejście oznacza nowe możliwości w tworzeniu oprogramowania. Jedną z najbardziej kuszących jest zwiększanie liczby zespołów developerskich biorących udział w projekcie, które mogą pracować niemalże niezależnie nad dostarczeniem funkcjonalności biznesowych, co wpływa na szybkość realizacji potrzeb klienta. Usługi mogą powstawać w różnych, najodpowiedniejszych dla danego zadania technologiach. Możemy je wdrażać niezależnie bez wpływu na działanie całego systemu, co w rezultacie skraca czas dostarczenia funkcjonalności i redukuje koszty tworzenia oprogramowania. Usługi mogą być niezależnie od siebie skalowane, co pozwala lepiej wykorzystywać zasoby i zarządzać kosztami, ponieważ skalowana jest tylko ta część systemu, która tego wymaga.

Architektura oparta o mikrousługi to nie tylko szereg zalet, które można by mnożyć. Wybór tej drogi niesie ze sobą również konsekwencje, które mogą stanowić spore wyzwania przy budowaniu oprogramowania, szczególnie w przypadku, gdy nie mamy jeszcze doświadczenia w tej dziedzinie. Wzrost liczby usług wpływa bezpośrednio na czas, który należy poświęcić na budowanie, testowanie oraz wdrożenia aplikacji. Do tego dochodzi kwestia chociażby zarządzania infrastrukturą, na której nasze oprogramowanie będzie uruchomione, wdrażane i skalowane. Wykorzystanie brokerów wiadomości, transakcyjność, monitoring usług oraz określenie zakresu funkcjonalności w ramach wybranej usługi – to tylko część aspektów budowania oprogramowania w ten sposób. Dlatego też coraz częściej obok developerów pojawią się nowe role – devops czy solution architect, chociaż w przypadku pierwszej precyzyjniej mówić o kulturze, które mają za zadanie wesprzeć budowanie oprogramowania w tej architekturze.

Architektura mikroserwisowa rozwiązaniem dla każdego?

Ten artykuł miał na celu przedstawienie, czym jest architektura mikrousługowa oraz jakie ma wady i zalety. Architektura ta – często przedstawiana jako lekarstwo na wszelkie problemy – przynosi wiele korzyści, ale dokłada nowych wyzwań, z którymi należy się zmierzyć. Wybór czy też zmiana architektury powinny być świadoma, podyktowane realnymi potrzebami, np. wynikającymi z zapewnienia wysokiej dostępności oprogramowania, szybkiej realizacji potrzeb biznesowych.

Czy mikroserwisy są rozwiązaniem dla każdego? Nie zawsze. Jeżeli jesteśmy ograniczeni wielkością zespołów developerskich (np. dysponujemy jednym małym zespołem, składającym się z 3-4 osób, oraz nie ma planów, aby zwiększyć zatrudnienie w tym obszarze), może się okazać, że narzut pracy związany z produkcją oprogramowania w tej architekturze będzie nieadekwatny do korzyści wspomnianych w tekście. Podobnie sytuacja będzie wyglądać, gdy budujemy rozwiązanie, które chcemy jak najszybciej wypuścić na rynek, aby zderzyć produkt z potencjalnym klientem. Jeżeli jest to nowy pomysł, może okazać się, że liczba zmian w koncepcji działania oprogramowania będzie na tyle duża, że architektura ta będzie bardziej przeszkadzać niż przynosić korzyści. Nie rekomendowałbym również wyboru mikrousług, jeśli, nie mamy kompetencji w budowaniu aplikacji w tej architekturze.

Udostępnij
Czy ten artykuł był pomocny?
Tak1
Nie0