Mikroserwisy w akcji. Отсутствует
zamiast całego systemu;
■ umożliwiając ciągłe dostarczanie małych, niezależnych zmian.
Izolowanie i minimalizowanie zależności podczas kompilacji – czy to między zespołami, czy w istniejącym kodzie – pozwala programistom na szybsze działanie. Rozwój może się odbywać równolegle, przy mniejszej długoterminowej zależności od wcześniejszych decyzji podejmowanych dla monolitycznej aplikacji. Zaszłości technologiczne w naturalny sposób ograniczają się do granic usług.
Mikroserwisy są pojedynczo łatwiejsze do zbudowania i bardziej zrozumiałe niż aplikacje monolityczne. Jest to korzystne dla produktywności w rozwijającej się firmie. Zapewnia także przekonujący i elastyczny paradygmat do radzenia sobie z coraz większą skalą lub łatwym wprowadzaniem nowych technologii.
Małe usługi są również doskonałym sposobem na wprowadzanie częstych zmian. Wdrożenia w dużych aplikacjach mogą być ryzykowne i obejmować cykle regresji i weryfikacji. Wdrażając mniejsze fragmenty funkcjonalności, łatwiej można izolować zmiany w działającym systemie, zmniejszając potencjalne ryzyko wynikające z wdrożenia.
W tym momencie dochodzimy do dwóch wniosków:
■ rozwój małych, autonomicznych usług może zmniejszyć tarcie w rozwoju długo istniejących, złożonych systemów;
■ dostarczając spójne i niezależne elementy funkcjonalności, można zbudować system, który jest elastyczny i odporny na zmiany, co pomaga uzyskać zrównoważony wpływ na biznes przy zmniejszonym ryzyku.
To nie znaczy, że każdy powinien budować mikroserwisy. Byłoby cudownie, gdyby istniała obiektywna odpowiedź na pytanie „Czy potrzebuję mikroserwisów?”, ale niestety można tylko odpowiedzieć „To zależy” – od naszego zespołu, od naszej firmy i od charakteru budowanego systemu. Jeśli zakres naszego systemu jest trywialny, to jest mało prawdopodobne, że uzyskamy korzyści, które przewyższą dodatkową złożoność wynikającą z budowania i obsługi tego typu aplikacji. Ale jeśli napotkamy którekolwiek z wyzwań, o których wspominaliśmy wcześniej w tej części, to mikroserwisy są przekonującym rozwiązaniem.
Słyszeliśmy kiedyś historię o nieudanej implementacji mikroserwisów. Istniejący proces zaczął się rozrastać, CTO zdecydował zatem, że jedynym rozwiązaniem jest przebudowanie aplikacji na postać mikroserwisów. Jeśli nie przejmujesz się tym stwierdzeniem, to lepiej zacznij!
Zespół inżynierów rozpoczął przebudowę aplikacji. Zajęło im to pięć miesięcy, podczas których nie wydali żadnych nowych funkcjonalności ani żadnego mikroserwisu do produkcji. Zespół zaczął uruchamianie nowej aplikacji mikroserwisowej w najbardziej krytycznym miesiącu dla biznesu, powodując absolutny chaos i konieczność wycofania się do pierwotnego monolitu.
Ten rodzaj migracji przysparza mikroserwisom złej sławy. Niewiele firm może sobie pozwolić na luksus zamrożenia funkcjonalności na kilka miesięcy, a także na uruchomienie nowej architektury. Mimo że zestaw przypadków jest niewielki, najbardziej udane migracje do mikroserwisów, które obserwowaliśmy, były fragmentaryczne, równoważąc wizję architektoniczną z potrzebami biznesowymi, priorytetami i ograniczeniami zasobowymi. Chociaż potrwa to dłużej i będzie wymagać więcej wysiłku inżynierskiego, miejmy nadzieję, że nigdy się nie zdarzy, że nasz zespół będzie wspominany w opowieściach ku przestrodze!
1.2. Co w mikroserwisach jest wyzwaniem?
Zagłębmy się nieco w temat i zbadajmy koszty oraz złożoność projektowania i uruchamiania mikroserwisów. Mikroserwisy nie są jedyną architekturą, która obiecała nirwanę dzięki dekompozycji i rozproszeniu, ale ostatnie próby, takie jak SOA4, są powszechnie uważane za nieskuteczne. Żadna technika nie jest magicznym narzędziem. Na przykład, jak już wspomnieliśmy, mikroserwisy drastycznie zwiększają liczbę odrębnych elementów w systemie. Rozdzielając funkcjonalności i odpowiedzialność za dane na wiele autonomicznych usług, jest również rozdzielana odpowiedzialność za stabilność i właściwedziałanie aplikacji.
Podczas projektowania i uruchamiania aplikacji mikroserwisowych napotkamy wiele wyzwań:
■ określanie zakresu i identyfikowanie mikroserwisów wymaga znacznej wiedzy na temat domeny ich zastosowania;
■ właściwe granice i kontrakty między usługami są trudne do zidentyfikowania i, po ich ustaleniu, ich zmiany mogą być czasochłonne;
■ mikroserwisy są systemami rozproszonymi i dlatego wymagają wielu założeń dotyczących stanu, spójności i niezawodności sieci;
■ przez rozproszenie komponentów systemu w sieci i zwiększenie heterogeniczności technicznej mikroserwisy wprowadzają nowe typy awarii;
■ trudniej jest zrozumieć i zweryfikować, co powinno się zdarzyć podczas normalnej pracy.
1.2.1. Wyzwania związane z projektowaniem
W jaki sposób te wyzwania wpływają na fazę projektowania i uruchamiania mikroserwisów? Wcześniej wprowadziliśmy pięć podstawowych zasad tworzenia mikroserwisów. Pierwszą z nich była autonomia. Aby nasze usługi były autonomiczne, musimy je tak zaprojektować, aby razem były luźno powiązane i każda zawierała wysoce spójne elementy funkcjonalności. Jest to proces ewolucyjny. Zakres naszych usług może się zmieniać w miarę upływu czasu, a my będziemy często się decydować na wyodrębnienie nowej funkcjonalności z usług, a nawet wycofanie już istniejących.
Dokonywanie tych wyborów jest wyzwaniem, szczególnie istotnym na początku opracowywania aplikacji! Głównym źródłem luźnych powiązań są granice między usługami; zły wybór doprowadzi do usług, które są trudne do zmiany i, ogólnie, mniej plastyczne i elastyczne do zastosowania.
OKREŚLANIE ZAKRESU MIKROSERWISÓW WYMAGA WIEDZY NA TEMAT DOMENY ICH ZASTOSOWANIA
Każdy mikroserwis jest odpowiedzialny za pojedynczą zdolność. Identyfikacja tych zdolności wymaga znajomości domeny biznesowej aplikacji. W początkowej fazie życia aplikacji nasza wiedza o domenie może być w najlepszym razie niekompletna lub, w najgorszym, niepoprawna.
Nieodpowiednie zrozumienie domeny problemu może skutkować złymi wyborami projektowymi. W aplikacji mikroserwisowej zwiększona sztywność granicy usługi w porównaniu z modułem w aplikacji monolitycznej oznacza, że koszt złych decyzji dotyczących zakresu może być wyższy:
■ być może trzeba będzie refaktoryzować wiele różnych baz kodów;
■ konieczna może być migracja danych z bazy danych jednej usługi do drugiej;
■ możliwe, że nie zostaną zidentyfikowane niejawne zależności między usługami, co może prowadzić do błędów lub niezgodności podczas wdrażania.
Czynności te zilustrowano na rysunku 1.5.
Jednak podejmowanie decyzji projektowych, przy niewystarczającej wiedzy o danej dziedzinie, nie jest rzadkością w przypadku mikroserwisów! Różne są skutki tych decyzji.
UWAGA W rozdziałach 2 i 4 za pomocą przykładowej aplikacji omówimy dobre praktyki dotyczące identyfikowania i określania zakresów usług.
ZARZĄDZANIE KONTRAKTAMI MIĘDZY USŁUGAMI
Każdy mikroserwis powinien być niezależny od sposobu implementacji innych usług. Pozwala to na techniczną heterogeniczność i autonomię. Aby to działało, każdy mikroserwis powinien wystawiać kontrakt – analogicznie do interfejsu w projektowaniu obiektowym – określający komunikaty, które spodziewa się otrzymywać i na które będzie udzielać
SOA jest mętnym terminem. Mimo że wiele zasad SOA jest podobnych do tych dotyczących mikroserwisów, definicja tego pierwszego jest nierozerwalnie związana z dużymi narzędziami dla przedsiębiorstw, takimi jak ESB.