Jak to działa?

Potrzebujesz pomocy dla biznesu?

Skontaktuj się z nami, aby uzyskać indywidualną wycenę FinMV dostosowaną do Twoich potrzeb.

Monolityczny czy mikroserwis?

Dyrektor techniczny Twojej firmy, planując uruchomienie platformy finansowej, będzie musiał wybrać opcję architektury projektu. Jakie opcje architektury są dla niego dostępne i którą lepiej wybrać?

Opcja 1. Architektura monolityczna (monolit)

Monolityczna architektura jest jak śnieżka. Zaczynasz projekt i masz małą śnieżkę. Jest tak mały, że może być rozwijany i rozwijany przez mały zespół. Minęło kilka lat, a teraz Twoja kula śniegowa stała się tak ogromna, że 20 programistów już ją naciska. Za kilka lat setki programistów będą rzucać Twoją śnieżkę za pomocą mnóstwa kodu, ale wprowadzanie nowych funkcji będzie bardzo powolne.

W rezultacie właściciele zaczynają zmieniać dyrektora technicznego, członków zespołu, ale jest tylko gorzej. Nowi członkowie zespołu nie znają szczegółów historycznych, dlaczego kula śnieżna jest taka, jaka jest, a nie inna. Dokumentacja produktu szybko staje się nieaktualna.

Dlaczego nie zrobić tego od razu? Po pierwsze, na samym początku działalności zawsze zasoby są ograniczone, nie ma wystarczającej liczby programistów, wiedzy i czasu. Instrukcja nalega, a programiści spieszą się, aby zrobić to w jak najszybszy sposób.

Po drugie, inżynierowie techniczni myślą: „Cóż, niech to będzie na razie monolityczna architektura, ale kiedy firma się rozwinie, wtedy wszystko przerobimy”. Niestety, w rzeczywistości przeniesienie istniejącego projektu monolitycznego do architektury mikroserwisowej będzie dziesiątki trudniejsze niż pisanie wszystkiego od zera.

Opcja 2. Architektura mikroserwisowa

Stworzymy Twoją platformę finansową natychmiast w oparciu o architekturę mikroserwisów.

Architekturę mikrousług można porównać do płyt chodnikowych na chodnikach. W miarę rozwoju projektu do chodnika dodawane są kolejne kafelki. Jeśli komponent jest nieaktualny, wystarczy wymienić ten kafelek na nowy.

Ta architektura ma wiele zalet, ale wymienię te najważniejsze:

  • poszczególni pracownicy są odpowiedzialni za działanie każdego mikroserwisu
  • kradzież kodu projektu jest zapobiegana, ponieważ programiści mają dostęp tylko do części kodu
  • kiedy pojawią się aktualizacje języka programowania, możesz naprawić kod programu każdej usługi jeden po drugim

Przykłady z życia

Pierwszy przykład. Zarząd platformy pożyczkowej P2P z dużą liczbą użytkowników zdecydowało się wejść na rynki krajów o innej walucie. Platforma miała monolityczną architekturę i obejmowała tylko jedną walutę – euro, a aby wejść na rynki Szwecji (korona szwedzka), Polski (polski złoty), Czech (czeska korona) konieczne było wprowadzenie wielowalutowości.

Wdrożenie tej funkcji zajęło całemu zespołowi miesiące, a rozwój nowych funkcji spowolnił jeszcze bardziej. W przypadku architektury mikroserwisowej wszystko byłoby znacznie prostsze i szybsze.

Drugi przykład. Początkowo kreator witryn został uruchomiony w języku ojczystym, a kierownictwo nie zamierzało rozszerzać działalności na inne rynki. Projekt miał architekturę monolityczną, a funkcjonalność szybko rosła. Schemat platformy był złożoną siecią, w której wszystko było połączone ze wszystkim. Pewnego dnia firma zdecydowała się wydać wersję platformy w innych językach. Początkowo wydawało się, że wystarczy dodać tylko pliki językowe, a teraz będziemy mieli przetłumaczony cały interfejs.

W praktyce cały projekt musiał zostać przerobiony. Na przykład nazwy firm i produktów w bazie danych powinny być teraz przechowywane nie tylko w jednym języku, ale w każdym języku. Nie można było zduplikować informacji ze względu na logikę biznesową, konieczne było przechowywanie nazw dla wszystkich języków jednocześnie. W związku z tym doprowadziło to do zmian w interfejsach szafy i zaplecza. Zmiany interfejsu wymagały zmiany zasad walidacji przychodzących danych, szablonów listów ze względu na różne zasady zakończeń w różnych językach, zmiany testów itp.

Ponieważ wszystko było ze wszystkim połączone, podjęto decyzję o przejściu na architekturę mikroserwisową wraz z wprowadzeniem nowych języków. Proces przejścia od architektury monolitycznej do architektury mikroserwisowej trwał ponad rok.

Trzeci przykład. Platforma fintech została stworzona na starej wersji PHP i Laravela. Aktualizacja do nowszych wersji, a także zmiana bazy danych z MariaDB na PostgreSQL była praktycznie niemożliwa, ponieważ cały zespół przez kilka miesięcy musiał zajmować się tylko procesem migracji.

Nowe wersje PHP i Laravela w tamtym czasie mogły przyspieszyć projekt i dalszy rozwój, ale monolityczna architektura nie pozwalała na aktualizację stosu technologicznego

.