Jak uniknąć vendor lock-in wykorzystując mikroserwisy

Uzależnienie od jednej technologii, infrastruktury lub wykonawcy może spowalniać lub wręcz uniemożliwiać rozwój biznesu. Pytanie “jak go uniknąć?” spędza sen z powiek, zwłaszcza tym CTO i CEO, którzy muszą radzić sobie z rosnącą liczbą użytkowników systemu IT. Jak zatem angażować do rozwoju systemu wiele zespołów jednocześnie, nie uzależniając się przy tym zbyt mocno od jednego wykonawcy?

Patrząc na rozwój platform chmurowych i rozwiązania w obszarze infrastruktury oferowanej w modelu usługowym – dostępne od Amazon, Microsoft czy Google – bariera wejścia zmalała. Jednocześnie jednak ryzyko vendor lock-in wzrosło. Skorzystanie z gotowych do użycia rozwiązań w chmurze, którymi kuszą Ci dostawcy wymaga sporej świadomości, aby uniknąć ryzyka uzależnienia od wybranej platformy. W obszarze technologii jest podobnie. Wybór określonej technologii – np. Node.js – powoduje, że – niezależnie od wykonawcy, którego wybierzemy do realizacji systemu – zawsze będziemy uzależnieni pod kątem kosztów i dostępności od developerów znających właśnie Node.js.

“Kiedy na rynku pojawia się duży gracz budujący system w określonej technologii, nie tylko koszt rozwoju naszego systemu może znacząco wzrosnąć. Istnieje realne ryzyko, że coraz trudniej będzie pozyskać lub zatrzymać utalentowanych architektów i developerów, którzy mają mocne kompetencje techniczne. Już dzisiaj rekrutacja na stanowisko seniora może zajmować nawet do trzech miesięcy”- mówi Katarzyna Pachocka-Nowok, Chief Operating Officer w RST Software Masters. Mając to na względzie, warto zadać pytanie: czy rozległy, przeznaczony dla dużej liczby użytkowników, szyty na miarę system IT na pewno musi być rozwijany w jednej technologii, przez jednego wykonawcę?

Czy nie byłoby bezpieczniej biznesowo budować w taki sposób, aby możliwe było pewne uniezależnienie – polegające na możliwości wytwarzania części systemu przez jednego wykonawcę, a drugiej przez inną firmę tworzącą oprogramowanie? Odpowiedź można znaleźć wykorzystując model architektoniczny oparty o mikroserwisy. Oczywiście, rozbicie dużego, monolitycznego systemu budowanego przez lata na pojedyncze, niezależne usługi wymaga czasu. Przed wdrożeniem takiej zmiany warto więc się zastanowić i określić zakres prac, decydując, które obszary systemu mają zostać przeniesione do architektury mikroserwisowej.

Na razie skoncentrujmy się jednak na tym, co możemy uzyskać biznesowo, decydując się na takie posunięcie. Warto wziąć pod uwagę dwa, poniższe powody.

Możliwość zatrudnienia wielu wykonawców jednocześnie

Dzięki wykorzystaniu architektury mikroserwisowej, poszczególne usługi lub obszary mogą być równolegle budowane przez różne zespoły lub firmy programistyczne, z których np. jeden posiada świetne kompetencje w implementacji mechanizmów wyszukiwania, a drugi specjalizuje się w integracji z IoT. Długofalowo jest to bezpieczniejsze dla zamawiającego system. Biznesowo staje się on mniej zależny od jednego podmiotu i redukuje ryzyko niepowodzenia projektu ze względu na jakiekolwiek kłopoty po stronie dostawcy oprogramowania. W takim układzie portfolio zamówień związanych z rozwojem systemu dzielone jest między generalnego wykonawcę a inne firmy wykonawcze, które wspierają rozwój określonych obszarów systemu.

Możliwość użycia wielu technologii w jednym systemie

W przeciwieństwie do systemu monolitycznego, ten rozwijany w architekturze mikroserwisowej może korzystać z dobrodziejstw różnorodności użytych technologii. Na przykład, usługę logowania czy rejestracji konta użytkownika można zrealizować w jednym języku, a funkcjonalność wyszukiwarki zbudować z wykorzystaniem innego języka. Daje to łatwość punktowego, precyzyjnego wykorzystania dobrze dopasowanych technologii do realizacji określonych obszarów, modułów, a nawet funkcji systemu. Ta otwartość na jednoczesne zastosowanie wielu technologii to kolejny atut dla firmy zamawiającej budowę systemu. Może zlecić wykonanie pojedynczej funkcjonalności jednej z firm, które specjalizują się w implementacji tego typu rozwiązań, a resztę systemu realizować “po staremu” z głównym wykonawcą.

Jak widać, wykorzystanie architektury mikrousługowej niesie istotne korzyści dla biznesu. Jej użycie polecane jest zwłaszcza wtedy, gdy nie budujemy na szybko, ale mamy już stabilną, rosnącą bazę powracających użytkowników. Pomimo to architektura mikroserwisowa nie jest na razie zbyt popularna w Polsce. Wciąż dominują systemy monolityczne, kosztowne w utrzymaniu, aktualizacji i rozwoju. Jestem jednak przekonany, że – skoro korzystają z tego podejścia globalni liderzy cyfrowej transformacji, tacy jak chociażby eBay – warto ją bliżej poznać.

Jacek Popko
Chief of Consulting RST Software Masters, założyciel Usability LAB, marki konsultingowej świadczącej usługi doradcze i projektowe dla finansów i bankowości, przedsięwzięć start-up oraz e-commerce. Należy do The Interaction Design Foundation oraz ACM: SIG-CHI. Udziela się jako wykładowca i prelegent. Współpracował z Alior Bank, Carrefour, Cisco, Empik, LUX MED, Orange, PGE, PKO, Santander Consumer Bank. Pasjonat UX.

Jeżeli interesują Was mikroserwisy, polecam ebook Łukasza Wróbla, doświadczonego architekta systemów IT. Łukasz brał udział w przebudowie monolitu systemu Trans, giełdy logistycznej numer dwa w Europie, na architekturę mikrousługową.