Chciałem napisać artykuł na temat architektury mikrousług od dłuższego czasu, jednak za każdym razem powstrzymywały mnie dwa momenty — im bardziej zagłębiałem się w temat, tym bardziej wydawało mi się, że to, co wiem, jest oczywiste, a to, czego nie wiem, nadal wymaga zgłębiania. Z drugiej strony uważam, że jest już o czym rozmawiać w szerszym gronie. Tak więc, alternatywne opinie są mile widziane.
Prawo Conwaya oraz związek między biznesem, organizacją a systemem informacyjnym
Pozwólcie, że po raz kolejny zacytuję:
„Każda organizacja, która projektuje jakikolwiek system (w szerokim sensie), otrzyma projekt, którego struktura kopiuje strukturę zespołów w tej organizacji”
— Melvyn Conway, 1967
Moim zdaniem, to prawo bardziej odnosi się do celowości organizacji biznesowej niż bezpośrednio do systemu informacyjnego. Wyjaśnię to na przykładzie. Załóżmy, że mamy do czynienia z wystarczająco stabilną możliwością biznesową z takim cyklem życia, który uzasadnia organizację przedsięwzięcia (to nie jest literówka, ale bardzo podoba mi się ten termin, który 'pożyczyłem'). Oczywiście, że system wspierający ten biznes będzie organizacyjnie i procesowo odpowiadać temu biznesowi.
Orientacja biznesowa systemów informacyjnych
Wyjaśnię to na przykładzie. Załóżmy, że mamy możliwość zorganizowania biznesu związane z sprzedażą pizz. W wersji V1 (nazwijmy ją przedinformatyczną) firma stanowiła pizzerię, punkt odbioru i usługę dostawy. Ta wersja była długowieczna w warunkach niskiej zmienności otoczenia. Następnie nadeszła wersja 2 — bardziej zaawansowana, potrafiąca wykorzystać system informacyjny w swojej podstawie dla biznesu o architekturze monolitycznej. I tutaj, moim zdaniem, pojawia się straszna niesprawiedliwość wobec monolitów — jakoby architektura monolityczna nie odpowiadała modelowi domeny biznesowejGdyby tak było, system w ogóle nie mógłby działać - w sprzeczności z tym samym prawem Conwaya i zdrowym rozsądkiem. Nie, architektura monolityczna w pełni odpowiada modelowi biznesowemu na tym etapie rozwoju firmy — mam na myśli etap, gdy system jest już stworzony i wdrożony. Ciekawym faktem jest to, że niezależnie od podejścia architektonicznego, zarówno architektura zorientowana na usługi wersji 3, jak i architektura mikroserwisowa wersji N będą działać równie dobrze. Gdzie jest haczyk?
Wszystko płynie, wszystko się zmienia, czy mikroserwisy to sposób na walkę z złożonością?
Zanim przejdziemy dalej, rozważmy niektóre nieporozumienia dotyczące architektury mikroserwisowej.
Zwolennicy wykorzystania podejścia mikroserwisowego często mówią, że podział monolitu na mikroserwisy upraszcza podejście do programowania poprzez zmniejszenie bazy kodu poszczególnych usług. Moim zdaniem to stwierdzenie to kompletna bzdura. Naprawdę, czy oczywista interakcja w ramach monolitu i jednolitego kodu wydaje się skomplikowana? Gdyby tak rzeczywiście było, wszystkie projekty byłyby od razu budowane jako mikroserwisy, podczas gdy praktyka pokazuje, że migracja z monolitu do mikroserwisów jest znacznie bardziej powszechna. Złożoność nigdzie nie znika, po prostu przenosi się z poszczególnych modułów do interfejsów (czy to szyn danych, RPC, API i innych protokołów) oraz systemów orkiestrujących. I to jest trudne!
Zaletą korzystania z heterogenicznego staku również jest wątpliwa. Nie zamierzam dyskutować, że jest to możliwe, ale w rzeczywistości rzadko spotykane (Z przodu — musi to mieć miejsce — ale raczej jako konsekwencja, a nie zaleta).
Cykl życia produktu i cykl życia usługi
Spójrz jeszcze raz na diagram powyżej. Nieprzypadkowo zaznaczyłem skracający się cykl życia poszczególnych wersji biznesu — w dzisiejszych warunkach to właśnie przyspieszenie przejścia biznesu między wersjami decyduje o jego sukcesie. Sukces produktu określa szybkość weryfikacji hipotez biznesowych w nim. I tutaj, moim zdaniem, tkwi kluczowa zaleta architektury mikroserwisowej. Ale przejdźmy do sedna.
Przejdźmy do kolejnego etapu ewolucji systemów informacyjnych — do architektury zorientowanej na usługi SOA. W pewnym momencie wydzieliliśmy w naszym produkcie długowieczne usługi — długowieczne w tym sensie, że podczas przejścia między wersjami produktu istnieją szanse, że cykl życia usługi będzie dłuższy niż cykl życia danej wersji produktu. Logiczne byłoby ich w ogóle nie zmieniać — dla nas ważna jest szybkość przechodzenia do następnej wersji. Niestety, musimy wprowadzać ciągłe zmiany w usługach — i tutaj przydają się wszystkie praktyki DevOps, konteneryzacja i wszystko, co przyjdzie nam do głowy. Ale to wciąż nie są mikroserwisy!
Mikroserwisy jako środek do walki ze złożonością… zarządzaniem konfiguracją
I tutaj możemy w końcu przejść do decydującej roli mikroserwisów — to podejście upraszczające zarządzanie konfiguracją produktu. Mówiąc dokładniej, funkcja każdego mikroserwisu opisuje właśnie funkcję biznesową w produkcie zgodnie z modelem domenowym — a to są już rzeczy, które żyją nie w krótkowiecznej wersji, ale w długowiecznej możliwości biznesowej. Przejście do następnej wersji produktu odbywa się dosłownie niezauważalnie — zmieniasz/dodajesz jeden mikroserwis, a może po prostu schemat ich interakcji i nagle znajdujesz się już w przyszłości, zostawiając za sobą płaczących konkurentów, którzy wciąż skaczą między wersjami swoich monolitów. Teraz wyobraź sobie, że masz wystarczająco dużą liczbę mikroserwisów z wcześniej określonymi interfejsami i możliwościami biznesowymi. Przyjdziesz i zbudujesz strukturę swojego produktu z gotowych mikroserwisów — po prostu rysując diagram, na przykład. Gratulacje — masz teraz platformę — i teraz możesz stworzyć sobie biznes na wskroś. Marzenia, marzenia.
Wnioski
- Architektura systemu powinna być określona przez cykl życia składników, które się w niej znajdują. Jeśli komponent żyje w ramach wersji produktu — nie ma sensu zwiększać złożoności systemu, stosując podejście mikroserwisowe.
- Mikroserwisowa architektura powinna opierać się na modelu domenowym — z powodu tego, że możliwość biznesowa jest najbardziej długowiecznym obszarem
- Praktyki dostarczania (praktyki DevOps) i orkiestracji mają dla architektury mikroserwisowej jedno z najważniejszych znaczeń - ponieważ wzrost szybkości zmiany komponentów stawia wyższe wymagania co do prędkości i jakości dostarczania.
Źródło: habr.com
