Już od dawna chciałem napisać artykuł na temat architektury mikroserwisów, ale dwie rzeczy mnie powstrzymywały – 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 Nie wiem, trzeba studiować i studiować. Z drugiej strony myślę, że jest już nad czym dyskutować w szerokim gronie. Zatem alternatywne opinie mile widziane.
Prawo Conwaya i związek pomiędzy biznesem, organizacją i systemem informacyjnym
Jeszcze raz pozwolę sobie zacytować:
„Każda organizacja, która projektuje system (w szerokim tego słowa znaczeniu), otrzyma projekt, którego struktura odzwierciedla strukturę zespołów w tej organizacji”.
— Melvyn Conway, 1967
Moim zdaniem to prawo raczej odnosi się do możliwości zorganizowania biznesu, a nie bezpośrednio do systemu informatycznego. Wyjaśnię to na przykładzie. Załóżmy, że mamy w miarę stabilną szansę biznesową z cyklem życia na tyle długim, że organizowanie przedsiębiorstwa ma sens (nie jest to literówka, ale bardzo podoba mi się to określenie, które ukradłem).Oczywiście system wsparcia tego biznesu będzie organizacyjnie i procesowo odpowiadać temu biznesowi.
Orientacja biznesowa systemów informatycznych
Wyjaśnię to na przykładzie. Załóżmy, że istnieje możliwość biznesowa zorganizowania firmy sprzedającej pizzę. W wersji V1 (nazwijmy to preinformacją) firma pełniła funkcję pizzerii, kasy fiskalnej i firmy kurierskiej. Wersja ta była długowieczna w warunkach małej zmienności środowiska. Następnie zastąpiła go wersja 2 - bardziej zaawansowana i potrafiąca w swej istocie wykorzystać system informatyczny dla biznesu o monolitycznej architekturze. I tutaj moim zdaniem jest po prostu straszna niesprawiedliwość w stosunku do monolitów - rzekomo monolityczna architektura nie odpowiada domenowemu modelowi biznesowemu. Tak, gdyby tak było, system w ogóle nie mógłby działać – sprzecznie z tym samym prawem Conwaya i zdrowym rozsądkiem. Nie, architektura monolityczna jest w pełni spójna z modelem biznesowym na tym etapie rozwoju biznesu – mam oczywiście na myśli etap, kiedy system jest już stworzony i oddany do użytku. To absolutnie cudowny fakt, że niezależnie od podejścia architektonicznego, zarówno architektura zorientowana na usługi w wersji 3, jak i wersja N architektury mikroserwisowej będą działać równie dobrze. Jaki jest haczyk?
Wszystko płynie, wszystko się zmienia, a może mikrousługi są sposobem na walkę ze złożonością?
Zanim przejdziemy dalej, przyjrzyjmy się pewnym nieporozumieniom na temat architektury mikrousług.
Zwolennicy stosowania podejścia mikrousługowego często argumentują, że podzielenie monolitu na mikrousługi upraszcza podejście programistyczne poprzez zmniejszenie bazy kodu poszczególnych usług. Moim zdaniem to stwierdzenie jest kompletną bzdurą. Poważnie, oczywista interakcja w ramach monolitu i jednorodnego kodu wydaje się skomplikowana? Gdyby tak rzeczywiście było, początkowo wszystkie projekty byłyby budowane jako mikroserwisy, praktyka jednak pokazuje, że migracja z monolitu do mikroserwisów jest znacznie częstsza. Złożoność nie znika; po prostu przenosi się z poszczególnych modułów do interfejsów (czy to szyn danych, RPC, API i innych protokołów) i systemów orkiestracji. A to jest trudne!
Wątpliwa jest również zaleta stosowania stosu heterogenicznego. Nie będę twierdził, że jest to również możliwe, ale w rzeczywistości zdarza się to rzadko (Patrząc w przyszłość – to powinno się zdarzyć – ale raczej jako konsekwencja niż korzyść).
Cykl życia produktu i cykl życia usługi
Spójrz jeszcze raz na powyższy diagram. Nieprzypadkowo zauważyłem skrócenie cyklu życia odrębnej wersji biznesu – w nowoczesnych warunkach to właśnie przyspieszenie przejścia biznesu pomiędzy wersjami decyduje o jego sukcesie. O sukcesie produktu decyduje szybkość testowania w nim hipotez biznesowych. I tu, moim zdaniem, leży kluczowa zaleta architektury mikroserwisowej. Ale chodźmy po kolei.
Przejdźmy do kolejnego etapu ewolucji systemów informatycznych – do architektury SOA zorientowanej na usługi. Tak więc w pewnym momencie podkreśliliśmy nasz produkt usługi długowieczne - długowieczne w tym sensie, że przy przechodzeniu pomiędzy wersjami produktu istnieje ryzyko, że cykl życia usługi będzie dłuższy niż cykl życia kolejnej wersji produktu. Logiczne byłoby w ogóle ich nie zmieniać – my Liczy się szybkość przejścia na kolejną wersję. Ale niestety jesteśmy zmuszeni do ciągłych zmian w usługach - i tutaj wszystko nam pasuje, praktyki DevOps, konteneryzacja i tak dalej - wszystko, co przychodzi na myśl. Ale to wciąż nie są mikroserwisy!
Mikrousługi sposobem na walkę ze złożonością... zarządzanie konfiguracją
I tu możemy wreszcie przejść do definiowania roli mikroserwisów – jest to podejście ułatwiające zarządzanie konfiguracją produktu. Bardziej szczegółowo, funkcja każdej mikrousługi opisuje dokładnie funkcję biznesową wewnątrz produktu zgodnie z modelem domeny - a to są rzeczy, które żyją nie w wersji krótkotrwałej, ale w długoterminowej możliwości biznesowej. A przejście do kolejnej wersji produktu następuje dosłownie niezauważone – zmieniasz/dodajesz jeden mikroserwis, a może nawet schemat ich interakcji i nagle trafiasz w przyszłość, zostawiając w tyle płaczącą konkurencję, która w dalszym ciągu skacze pomiędzy wersjami produktu ich monolity. Teraz wyobraź sobie, że istnieje dość duża liczba mikrousług z predefiniowanymi interfejsami i możliwościami biznesowymi. A Ty przychodzisz i budujesz strukturę swojego produktu z gotowych mikroserwisów - po prostu rysując np. diagram. Gratulacje – masz platformę – i teraz możesz przyciągać biznes dla siebie. Marzenia Marzenia.
odkrycia
- Architektura systemu powinna być zdeterminowana cyklem życia jego komponentów. Jeśli komponent istnieje w wersji produktu, nie ma sensu zwiększać złożoności systemu poprzez zastosowanie podejścia mikrousługowego.
- Architektura mikrousług powinna opierać się na modelu domeny – bo szansa biznesowa jest domeną najdłużej istniejącą
- Praktyki dostarczania (praktyki DevOps) i orkiestracja są jednymi z najważniejszych w architekturze mikrousług - z tego powodu, że wzrost tempa zmian komponentów stawia zwiększone wymagania dotyczące szybkości i jakości dostarczania
Źródło: www.habr.com