Читать книгу Mikroserwisy. Wzorce z przykładami w języku Java - Chris Richardson - Страница 24

Mary doszła do wniosku, że FTGO musi zostać zmigrowane do architektury mikroserwisowej.

Co ciekawe, architektura oprogramowania ma bardzo niewiele wspólnego z wymaganiami funkcjonalnymi. Można zaimplementować zestaw przypadków użycia – wymagania funkcjonalne aplikacji – w dowolnej architekturze. W rzeczywistości typowe dla udanych aplikacji, takich jak FTGO, jest to, że są dużymi kulami błota.

Architektura ma jednak znaczenie, ponieważ wpływa na tak zwane wymagania dotyczące jakości usług, zwane również wymaganiami niefunkcjonalnymi, atrybutami jakości lub – ilities². W miarę rozwoju aplikacji FTGO ucierpiały różne atrybuty jakości, w szczególności te, które wpływają na szybkość dostarczania oprogramowania: łatwość konserwacji, rozszerzalność i testowalność.

Z jednej strony zdyscyplinowany zespół może spowolnić tempo zmierzania w kierunku monolitycznego piekła. Członkowie zespołu mogą ciężko pracować, aby zachować modułowość swojej aplikacji. Potrafią pisać kompleksowe, automatyczne testy. Z drugiej strony nie mogą uniknąć problemów dużego zespołu pracującego nad pojedynczą aplikacją monolityczną. Nie mogą też rozwiązać problemu coraz bardziej przestarzałego stosu technologicznego. Najlepsze, co może zrobić zespół, to opóźnić nieuniknione. Aby uciec od monolitycznego piekła, muszą przeprowadzić migrację do nowej architektury: architektury mikroserwisowej.

Obecnie panuje konsensus, że jeśli budujemy dużą, złożoną aplikację, powinniśmy rozważyć użycie architektury mikroserwisowej. Ale czym dokładnie są mikrousługi? Niestety nazwa nie pomaga, ponieważ zbyt podkreśla rozmiar. Istnieje wiele definicji architektury mikroserwisowej. Niektórzy przyjmują tę nazwę zbyt dosłownie i twierdzą, że usługa powinna być niewielka – na przykład 100 LOC. Inni twierdzą, że opracowanie usługi powinno zająć tylko dwa tygodnie. Adrian Cockcroft, kiedyś pracujący w Netflix, definiuje architekturę mikroserwisową jako architekturę zorientowaną na usługi, złożoną z luźno powiązanych ze sobą elementów, które mają ograniczone konteksty. To nie jest zła definicja, ale trochę mętna. Zobaczmy, czy możemy to lepiej określić.