Przemyślenia architekta IT

Menu
  • Strona główna
  • O mnie
  • Co czytam
  • Czego się uczę
Menu

Drivery architektoniczne. Czym są i co może się wydarzyć, gdy odkryjemy je zbyt późno. Historia prawdziwa.

Posted on 14 listopada 201930 września 2020 by Tomasz Sokół

„Życie to sztuka wyboru”. Nie wiem dokładnie, kto jest autorem tego powiedzenia, ale jest w tym cholernie dużo racji. Wytwarzanie oprogramowania to też sztuka wyboru. To sztuka znajdowania kompromisów. W klasycznym powiedzeniu „Dobrze, szybko, tanio – wybierz dowolne dwa atrybuty” jest naprawdę dużo racji.

Aby podjąć decyzję, często wypisujemy sobie argumenty za i przeciw. Jest to dobra metoda, gdy mamy tylko dwie opcje wyboru. W przypadku decyzji o kształcie wytwarzanego systemu opcji, jak również samych decyzji, jest wiele.

Drivery architektoniczne

W naszym świecie z pomocą przychodzą nam drivery architektoniczne. Wspomina o nich Simon Brown w swojej książce „Software architecture for developers”, możemy usłyszeć o nich na konferencjach czy szkoleniach takich jak DNA – Droga Nowoczesnego Architekta.

Drivery architektoniczne to zestaw czynników, które musimy wziąć pod uwagę projektując i implementując system.

Zgodnie z literaturą i materiałami, jakie miałem okazję studiować, istnieje następujący podział driverów na pięć klas:

  1. wymagania funkcjonalne
  2. atrybuty jakościowe
  3. ograniczenia projektowe
  4. konwencje
  5. cele projektowe

Niestety poza tym, że wyszczególnione zostały klasy driverów na próżno szukać gotowych list driverów każdej kategorii. Drivery niestety bywają specyficzne dla problemu z jakim się mierzymy.

Case study

Chciałbym Wam w tym artykule przedstawić, na prawdziwym produkcyjnym przykładzie, proces myślowy, który doprowadził do zidentyfikowania najważniejszych driverów architektonicznych. Pokażę też, co się stało, kiedy część driverów została odkryta zbyt późno.

Opis systemu

Na potrzeby tego artykuły przyjmijmy, że jest to portal informacyjny o wydarzeniach sportowych. W rzeczywistości była to inna branża, jednak chciałem zachować tu poufność. System ten:

  1. Pełnił funkcję portalu informacyjnego wystawionego w Internecie
  2. Umożliwiał posiadaczom biletów oraz wszystkim innym odwiedzającym sprawdzenie podstawowych informacji o wydarzeniu sportowym
  3. Wspierał trzy rodzaje użytkowników: gość, gość z numerem biletu oraz posiadacz konta
  4. W zależności od rodzaju użytkownika serwował informacje na innym poziomie szczegółowości
  5. W przypadku zalogowanych użytkowników posiadał moduł notyfikacji
  6. W celu pobrania informacji o wydarzeniach komunikował się z kilkoma innymi systemami (innymi w zależności od rodzaju użytkownika)
  7. Musiał być SEO friendly
  8. Pełnił również rolę serwera autoryzacyjnego dla innych systemów dla tego samego klienta

Proces identyfikacji Driverów architektonicznych

Wymagania funkcjonalne

Zbieranie wymagań funkcjonalnych jest czymś oczywistym na wczesnym etapie projektu. Istnieją różne techniki jak chociażby Event storming. W mojej organizacji akurat wymagania zbierane są przez osobny działa analizy. Specyfikacja wymagań została przekazana zespołowi w postaci gotowego dokumentu. Sytuacja zastana, zero dyskusji.

Analizując wymagania funkcjonalne wyróżnione zostały następujące drivery:

  1. Krytyczność, mierzona dostępnością, różnych funkcji systemu nie jest jednakowa dla każdej funkcji
  2. Obciążenie różnych funkcji systemu nie będzie jednakowe
  3. Możliwość skalowania per moduł, a nie per cały system
  4. System musi być podzielony na wiele niezależnych jednostek wdrożeniowych

Zapadła decyzja, że najlepiej sprawdzi się architektura mikroserwisowa. W skład systemu miały wejść:

  1. Aplikacja frontend’owa. Ponieważ system miał być SEO friendly odpadała Single page. Zdecydowano, że wystarczy standardowy wzorzec MVC
  2. Trzy niezależne aplikacje backendowe wystawiające frontendowi API REST
  3. Serwer autoryzacyjny oAuth

Dostęp do serwisów backend’owych miał być zrealizowany za pośrednictwem service discovery.

Na początek dwie instancje frontend’u (load balancing z Apache + mod_jk i sticky session).

Atrybuty jakościowe

Ciekawiej zrobiło się gdy przyszło do identyfikacji driverów grupy drugiej „atrybuty jakościowe„. Niestety stwierdzenia „system ma być wysoko dostępny”, „system ma być bezawaryjny” brzmią bardzo fajnie w ustach managerów ale są kompletnie bezużyteczne, gdy próbujemy sporządzić SLA (Service Level Agreement). Niezbędne były metryki jakościowe. Wypracowane zostało następujące rozwiązanie. Zidentyfikowane zostały najczęstsze i najbardziej kluczowe scenariusze użycia. Każdy z nich składał się z 1 do n kroków. Kosztowność wykonania każdego z kroków była różna. Zaplanowane zostały testy wydajnościowe, które wyliczały średnią z czasu wykonania każdego kroku scenariusza. Przyjęto, że akceptowalne są wartości mniejsze niż 2 sek na średnią każdego kroku. Był to nasz atrybut jakościowy. Oczywiście kolejnymi atrybutami jakościowymi były: brak wyjątków czasu wykonania powodujących fail scenariuszy testowych oraz poprawność biznesowa wykonywanych scenariuszy.

Ograniczenia projektowe

W przypadku ograniczeń projektowych były one podzielone na dwie grupy:

  1. Ograniczenia w naszej firmie
  2. Ograniczenia narzucone przez klienta

Nasza firma specjalizuje się w Java. Naturalnie wybrano ten język programowania. Postanowiono użyć Springa, gdyż developerzy najlepiej go znali i potencjalnie najłatwiej znaleźć na rynku ludzi z doświadczeniem w tym framework’u. Wybór PostgreSQL na silnik bazodanowy również wynikał z faktu, że nasz dział DBA posiadał największe kompetencje w pracy z tą bazą.

Także stos technologiczny miał wyglądać (w dużym skrócie) następująco:

  1. SpringBoot
  2. Thymeleaf
  3. Feign
  4. Ribbon
  5. Eureka
  6. PostgreSQL

Mikroserwisy uruchamiane z jarów. Typowy stos oparty o Springa. Co tu mogło pójść nie tak, pomyślicie :D.

Ze swojej strony klient zastrzegł, że infrastruktura produkcyjna będzie zarządzana przez ich administratorów. Oznaczało to dla zespołu wykonawczego tyle, że należy przywiązać szczególną uwagę do dokumentacji wdrożeniowej oraz przygotować rekomendacje potrzebnych komponentów najbardziej szczegółowo, jak to możliwe.

Konwencje i Cele projektowe

Drivery z tych grup pominę na potrzeby tego artykułu, gdyż odegrały one najmniejszą rolę.

Co się dzieje, gdy odkrywasz nowy driver, gdy system jest już gotowy

Zespół zabrał się ochoczo do pracy. W pewnym momencie uznano, że należy poprosić klienta o te ich maszynki.

Jakie było zaskoczenie, gdy okazało się, że klient ma w swoich szeregach architekta, który mentalnie został głęboko w latach dziewięćdziesiątych poprzedniego stulecia.

Pojawiły się nowe drivery!!!

Okazało się, że aplikacje nie mogą być odpalane z jara ale muszą być zdeployowane na Tomcat’ach.

Żaden problem. Dajcie po prostu osobne wirtualki z osobnym Tomcat’em na każdy komponent aplikacji. Żeby zapewnić HA potrzeba po dwie instancje każdego komponentu.

Okazało się niestety, że maks co można otrzymać to cztery wirtualki, a na każdej jeden Tomcat. Dwa węzły frontend’u i dwa węzły backend’u, żeby zapewnić HA.

Zaczęły się schody. Trzeba było upchnąć 3 aplikacje backend’owe na jednego Tomcata. Oznaczało to, że należy je udostępnić w różnych kontekstach innych niż ROOT. Eureka niestety tego nie wspiera. W zasadzie, to jeśli infrastrukturę mamy i tak zalaną betonem i nie ma mowy o łatwym dodawaniu kolejnych węzłów, to czy potrzeba tak naprawdę service discovery?

Dostarczanie paczki wdrożeniowej

Gwoździem do trumny okazał się fakt, że klient chce dostawać jedną paczkę wdrożeniową z nadaną wspólną wersją. Continous delivery? Nie, nie panowie. No to ma być taki zip opatrzony wersją, którego będziecie wrzucać na ten oto serwer FTP, a tutaj jest szablon dokumentu, który musicie wypełnić za każdym razem, gdy wychodzi nowa wersja.

Tak oto umiera architektura mikroserwisowa. A przecież doradzali: monolith first!!!

Jeśli podobają Ci się treści na moim blogu zostaw swój email. Będę Cię informował o nowych artykułach. Zero spamu same konkrety.

* pola wymagane

Chcesz dostawać powiadomienia o nowych artykułach? Zostaw swój email.

Ostatnie wpisy

  • Wzorzec Post/Redirect/Get plus twierdzenie CAP jako recepta na problem
  • 7 kroków do przejęcia systemu od innego dostawcy
  • Młody programisto! 7 porad od starszego kolegi
  • Jak dorosłem do tego, żeby nie używać ORM’a
  • Drivery architektoniczne. Czym są i co może się wydarzyć, gdy odkryjemy je zbyt późno. Historia prawdziwa.

Kategorie

  • Architektura
  • Procesy
  • Zespół
Polityka prywatności
©2022 Przemyślenia architekta IT | WordPress Theme by SuperbThemes
Serwis wykorzystuje pliki cookies. Korzystając ze strony wyrażasz zgodę na wykorzystywanie plików cookies.Tak. Zgadzam się Reject Dowiedz się
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.

Necessary Always Enabled

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Non-necessary

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.