Mikroserwisy – standaryzacja #3

Created with Sketch.

Mikroserwisy – standaryzacja #3

Duże firmy to duże systemy, duże systemy to wiele mikro usług i osób/zespołów je tworzących i utrzymujących. Jak pisałem w poprzednich postach każdy serwis jest w pełni autonomiczny technologicznie. Pozwala to na właściwy wybór zestawu narzędzi do rozwiązania danego problemu w najbardziej optymalny sposób. Właściwy dobór języka czy framework’u do problemu to bardzo często kluczowa rzecz dla jego szybkiego i wydajnego rozwiązania. Negatywnym skutkiem zbyt wysokiej dowolności w wyborze technologii może okazać się zbyt duże zróżnicowanie w technologicznym firmowym portfolio. Jak dołożymy do tego ludzką ciekawość i chęć nauki otrzymujemy przekonanie graniczące z pewnością że lada chwila będziemy mieli n wyspecjalizowanych zespołów w m+1 technologiach, czytaj koszmar utrzymania. Co zatem zrobić aby jakoś nad tym wszystkim zapanować ? Odpowiedź jest ukryta w jednym wyrazie – standaryzacja.

Czym jest standaryzacja ?

Standaryzacja to proces polegający na stworzeniu pewnych reguł i narzędzi w celu ujednolicenia innych procesów dzięki czemu stają się one re-używalne, przenoszanlne i tak samo rozumiane przez dowolny zespół w IT.

Nie chciałbym być źle  zrozumiany bo nie chodzi tu o betonowanie się na konkretne, jedyne słuszne rozwiązanie. Chodzi mi o to aby uniknąć sytuacji, w której każdy zespół opracowuje i tworzy np własny system monitoringu czy utrzymuje własne skrypty wdrożeniowe itd. W dużych organizacjach często zespół zajmuje się określonym bounded contextem co wprost implikuje, że zajmują się rozwojem i utrzymaniem konkretnej usługi lub grupy usług. Zakres projektów jakimi zajmuje się zespół nie jest zazwyczaj wyryty w kamieniu a juz napewno nie skład osobowy zespołu. Z różnych powodów programistów przesuwa się w inne obszary, projekty i jeżeli nie wyznaczymy wcześniej wspomnianych standardów czas wdrożenia takiego pracownika będzie niemal równy z czasem zatrudnienia nowej osoby z zewnątrz. 

Dla przykładu w organizacji gdzie nie zostały wprowadzone żadne standardy może okazać się, że każdy zespół wdraża swoją aplikacje w inny sposób począwszy od kopiowania wara na server, przez „tajemne” skrypty w bash aż do pełnego CI/CD na postawionym na „boku” jenkins. Jak się domyślasz taki rozstrzał metod wdrażania generuje duży narzut na utrzymanie przez każdy zespół swojego rozwiązania. Innym negatywnym skutkiem jest koszt wdrażania nowego pracownika do zespołu. Nie chodzi mi tylko o osoby nowo zrekrutowane bo tu oczywistym jest, że jakiś koszt wdrożenia nowego członka zespołu trzeba ponieść. Chodzi mi o osoby które przechodzą wewnątrz firmy pomiędzy projektami. Wówczas koszt wdrożenia w pesymistycznej wersji może być równy kosztowi nowo zatrudnionego pracownika, a to zabija wiele możliwości np zmianę projektu dla „odświeżenia” głowy czy dynamiczne wsparcie zagrożonego projektu programistami z mniej priorytetowego obszaru.

Co standaryzować ?

Moim zdaniem standaryzacja powinna w różnym stopniu objąć cały cykl życia oprogramowania począwszy od pisania kodu a kończąc na monitorowaniu aplikacji.

Pozwolę sobie zacząć od aspektów wzbudzających mniej emocji czyli większości rzeczy zdala od samego pisania kodu:

  • przechowywanie kodu – jedno miejsce np bitbucket / github gdzie można w łatwy sposób znaleźć interesujące nas repozytorium, najlepiej nazwane ze spójna konwencja ustaloną w firmie
  • przechowywanie zbudowanych aplikacji – jedno miejsce np artifactory pozwala na łatwe sprawdzenie i pobranie właściwej wersji aplikacji czy biblioteki podczas budowania czy wdrażania aplikacji
  • wdrożenie – re-używalne plany np Jenkins / bamboo lub skrypty bash oszczędzają czas i pozwalają dowolnej osobie wdrożyć naszą aplikację bez konieczności zdobywania specjalistycznej wiedzy. Zyskujemy tez wyższą jakość wdrożeń dzięki temu, że nie zależnie czy to kolektywny rozwój czy dedykowany zespół, cały proces wdrożeń jest rozwijany i ulepszany, a nie „tworzony od nowa” przez każdy zespół od nowa. Unikamy dzięki temu wielu błędów i naturalnie oszczędzamy czas
  • monitoring – tu należy pochylić się nad dwoma tematami publikowaniem i prezentacją metryk. Publikowanie to przede wszystkim określenie wspólnego, minimalnego zbioru metryk wraz z jednostkami dla określonych typów aplikacji, np dla mikroserwisów z które maja wpływ na naszego klienta bezpośrednio to może być czas odpowiedzi (p999) liczba requestów na sekundę oraz liczba błędów. Pisząc o prezentacji mam na myśli jedno miejsce gdzie bede mógł zobaczyć z wizualizowane metryki dla wszystkich serwisów (np Grafana). Dzięki temu możemy określić np impakt spowolnienia naszej aplikacji na inne elementy systemu i za wczasu stosownie zareagować.
  • logi – łatwy i szybki dostęp do logów (w połączeniu z ptk wyżej) aplikacyjnych to podstawa szybkiej diagnostyki problemu, zwłaszcza na środowisku produkcyjnym gdzie każda minuta awarii to realnie utracone pieniądze. Jedno miejsce gdzie mamy dostęp do logów wydaje się być mocno zasadne. Niemniej bez właściwej treści i struktury ich przeszukiwanie może być arcy trudne.

Zdecydowanie bardziej gorąca staje się dyskusja o standaryzacji w przypadku wyboru technologii.

Co oznacza standaryzacja wyboru technologii ?

Moim zdaniem to powinien być to w miarę luźny zbiór reguł, które w pewnym stopniu ogranicza i wspiera wybór technologii do danego problemu. Pisząc technologii mam na myśli zarówno język programowania jak i np framework. Takie ograniczenie potencjalnie w firmie mogło by wyglądać tak:

  • do tworzenia mikro usług korzystamy z języków na JVM (rekomendowane: java 8+, kotlin, scala, groovy),
  • przy wyborze framework’u preferowane rozwiązania oparte o Spring
  • bazy danych: relacyjne Oracle, MySql, nie relacyjne mongo, redis
  • do opisu infrastruktury Puppet

Benefity z w miare luźno zdefiniowanych standardów

Tak określone ograniczenia pozawalają nam zachować bardzo dużą swobodę, np ograniczenie na język programowania na JVM pozwala pisać w dowolnym pardygmacie jednocześnie pozostawiając możliwość elastycznego zarządzania zespołami i rozwojem produktów.

Z drugiej storny dzięki ograniczeniu do JVM i Spring, małym nakładem pracy możemy stworzyć zbiór bibliotek / firmowy bootstrap zawierający np konfiguracje metryk, klienta http , loggera czy innych elementów. Konfiguracja tych elementów bywa nietrywialna a jednocześnie jest niezbędna i powtarza się w większości projektów. Możemy je napisać raz i re-używać np przez dodanie zależności. Zarządzanie nimi staje się proste a rozwój i utrzymanie zostaje oddelegowane do wyspecjalizowanego zespołu, a my możemy zająć się implementacją wymagań biznesowych.

Innym plusem takiego podejścia jest możliwość wsparcia w developmencie innego zespołu czy „turystyka zespołowa”. W przypadku gdy zespół będący opiekunem mikro usługi nie ma przestrzeni na wykonie dla nas ważnego zadania, zdecydowanie łatwiej i efektywniej „gościnnie” napisać komuś feature requesta w jego usłudze zwłaszcza gdy napisana została w znanym nam stack’u technologicznym.

Kolejnym benefitem z uspójnienia technologii jest łatwa możliwość ściągnięcia do mniej doświadczonego zespołu „na chwilę” seniora, który zrobi review czy pomoże rozwiązać problem wydajnościowy.

Warto pamietać, że …

żadne rozwiązanie nie jest pozbawione wad. Tak jest i tym razem. W przypadku wprowadzania standardów łatwo jest przesadzi i zbić innowacyjność technologiczną. Dlatego warto stworzyć w firmie miejsce w stylu RND lub przestrzeń dla programistów gdzie będzie można zweryfikować czy np dana technologia powinna trafić do naszego firmowego portfolio.