4 grudnia 2015 by Tadeusz Balcer

S. Newman: „Budowanie mikrousług. Wykorzystaj potencjał architektury usług!”. Recenzja książki.

Koncepcja tworzenia systemów informatycznych, bazujących na mikrousługach (z ang. microservices) zaczyna być wykorzystywana przez coraz szersze grono firm. Można wśród nich wymienić Google, eBay, Amazon, Twitter czy SoundCloud. Sam Newman, pracownik firmy ThoughtWorks, w której spotkać można m.in. samego Martin’a Fowler’a, przybliża nam tę koncepcję w swojej książce. 

Pozycja ta rozpoczyna się od próby zdefiniowania, czym tak na prawdę są mikrousługi. Pada tu wiele określeń, które je charakteryzują: „(…) niewielkie, współpracujące ze sobą, autonomiczne usługi”, „(…) kod, który można przepisać w dwa tygodnie”, czy stwierdzenie, że zespół pracujący nad jedną mikrousługą, powinien liczyć tyle osób, żeby wszyscy mogli najeść się dwoma pizzami. Autor generalnie próbuje dość obrazowo opisać w jakich ramach powinna mieścić się usługa, aby była mikrousługą, pisząc swoje przemyślenia oraz przytaczając wypowiedzi różnych osób. Podkreśla tym samym konieczność wyczucia, czy dany program jest zgodny z założeniem tej architektury, aniżeli patrzenia przez pryzmat konkretnych wartości (takich jak dokładna liczba linii kodu).

Dalsza część książki podejmuje temat roli architekta systemów informatycznych w trakcie wytwarzania oprogramowania. Bardzo spodobała mi się część dotycząca porównywania programisty do innych zawodów:

"Branża komputerowa jest młoda. To jest coś, o czym zdajemy się zapominać, a jednak programy działajace na maszynach, które uznajemy za komputery, piszemy dopiero od około 70 lat. Dlatego stale poszukujemy porównań do innych zawodów, próbując wyjaśnić to, co robimy (...) z tego względu społeczeństwu trudno jest nas zrozumieć - trudno jest również zrozumieć nam, do jakiej kategorii należymy.

Musimy więc czerpać doświadczenia z innych profesji. Nazywamy się "inżynierami" oprogramowania lub "architektami". Jednak nimi nie jesteśmy. Nieprawdaż? Architekci i inżynierowie podlegają rygorom, o których mogliśmy tylko pomarzyć, a ich rola w społeczeństwie jest dobrze rozumiana. (...) Gdyby budowa mostu przypominała programowanie, to w trakcie budowy moglibyśmy dowiedzieć się, że odległy brzeg jest teraz o 50m dalej, niż był, i że podłoże w tym miejscu to właściwie błoto, a nie granit, a zamiast mostu dla pieszych w istocie budujemy most drogowy. Oprogramowanie nie jest ograniczone przez takie same fizyczne reguły, których muszą przestrzegać prawdziwi architekci lub inżynierowie, a to, co tworzymy, jest zaprojektowanie w taki sposób, by można było to w łatwy sposób przystosować do zmieniających się wymagań użytkownika."

Po takim wstępie pozostała, można powiedzieć właściwa, część książki, zajmuje się już samymi mikrousługami, z podziałem na różne aspekty ich działania i wytwarzania. Tak więc mamy rozdział dotyczący ich integracji, wdrażania, testowania, monitorowania oraz zapewnianiu ich bezpieczeństwa. Krótko mówiąc, cały proces wytwarzania oprogramowania, od projektu po utrzymanie, ze swego rodzaju best practices dla każdego z etapów. Zanim jednak autor zaproponuje najbardziej optymalne rozwiązania danego problemu, często przedstawia rozwiązania pośrednie, razem z opisem ich wad i zalet. Przykładowo, w rozdziale dotyczącym Integracji mikroserwisów, przedstawione są różne techniki komunikacji. Pojawia się RPC, REST oraz brokerzy komunikatów (z ang. message brokers). Następnie autor rozważa synchroniczną i asynchroniczną współpracę między usługami. Potem, chwytając się współpracy asynchronicznej, rozważa model oparty na zdarzeniach, usługi jako maszyny stanów czy rozszerzeń reaktywnych (z ang. reactive extensions). W ten sposób możemy poznać zdanie autora na temat różnych problemów, napotykanych przy projektowaniu mikrousług. Dzięki temu w przyszłości, samemu stając przed koniecznością podjęcia decyzji związanej z budową mikrousług, możemy skorzystać z doświadczeń autora. Dodatkowo książka zawiera informacje na temat przeróżnych narzędzi, od automatycznego tworzenia dokumentacji, przez systemu do wirtualizacji zasobów w chmurze, po oprogramowanie wspierające ciągłe dostarczanie oprogramowania (z ang. continous integration).

W książce pojawia się również rozdział dotyczący prawa Conwaya, które brzmi:

"Każda organizacja, która projektuje system (tutaj zdefiniowany szerzej jako system informatyczny), nieuchronnie stworzy projekt, którego struktura będzie kopią struktury komunikacji w organizacji"

Bardzo ciekawie obrazuje konieczność dostsosowania struktury całego działu IT w organizacji do sposobu, w jakim chcemy wytwarzać oprogramowanie. Autor mówi też o tzw. „Odwróconym prawie Conway’a”, wnioskując, że wybierając daną architekturę systemu, nasza organizacja jakby samoistnie zacznie dostosowywać podział zespołów wedle tej architektury.

Podsumowanie

„Budowanie mikrousług” Sama Newmana to niewątpliwie ciekawa pozycja dla wszystkich osób podejmujących decyzję dotyczącą architektury oprogramowania. Moim zdaniem docenią ją również osoby zaznajomione z koncepcją „mikrousług”, ponieważ w mojej ocenie największą wartością publikacji są opisane rady i doświadczenia autora. Bardzo podobało mi się wymienianie konkretnych narzędzi i serwisów wspomagających wytwarzania oprogramowania. Przez to jednak prawdopodobnie za parę lat pozycja ta będzie nieco mniej aktualna.

„Budowanie mikrousług” nie jest jednak dla każdego. W moim odczuciu, programiści bardziej skoncentrowaniu na implementowaniu przedstawionych założeń architektonicznych lub oczekujący konkretnych rozwiązań, mogą się na niej zawieść, ponieważ nie zawiera ona w sobie żadnej linijki kodu. Nie poleciłbym jej również osobom niezwiązanym z programowaniem, ponieważ poruszana tematyka mogłaby okazać się dość trudna bądź wręcz niezrozumiała.

W mojej ocenie książka bardzo dobrze rozszerza horyzontu każdego, kto podczas swojej pracy musi podejmować decyzje dotyczące architektury oprogramowania. Poprzez omówienie różnych rozwiązań, możemy zarówno zapoznać się z najlepszymi praktykami, jak również znać zalety i wady innych rozwiązań. Na plus zasługuje również opisy różnych narzędzi służących do Ciągłego Dostarczania Oprogramowania (z ang. Continous Deployment) jak i automatycznego tworzenia dokumentacji czy wirtualizacji zasobów.

W książce zabrakło mi jedynie szerzej opisanych wad tego rozwiązania, mimo że nie zostały pominięte, czytelnik ma wrażenie że rozwiązanie to jest idealne prawie w każdej sytuacji. Ponadto niektóre rozdziały są nieco nazbyt rozwlekłe, jednak nie ujmuje to zbytnio książce jako całości.

Moja ocena to 8/10