11 września bieżącego roku w Sopocie odbyła się konferencja “Geecon Microservices”. Jest to pierwsza konferencja w Polsce poświęcona w całości zagadnieniom związanym z architekturą zorientowaną na mikroserwisy. Ostatnimi czasy jest to gorący temat w świecie IT, dlatego miałem duże oczekiwania względem tego wydarzenia. Poniżej przedstawiam opis kilku, z mojego punktu widzenia najciekawszych prelekcji.

 

 Fred George
It’s Not Just MicroServices: Areas of focus for MicroService Success

Pierwsza sesja, podczas której, Fred George wprowadził słuchaczy w temat. Prelekcja nie dotyczyła jednak tylko samych mikroserwisów ale również najnowszych trendów w ogóle, m.in. no-SQL, lean, agile itp.

Co zmieniają? Jaki jest ich cel?

Aby odpowiedzieć na te pytania zaprezentowany został zbiór wykresów, na których widać było jak zmieniał się sposób pracy zespołów deweloperskich na przestrzeni lat. Głównym trendem okazało się skrócenie czasu dostarczania funkcjonalności – od kilkuletnich projektów waterfall’owych, poprzez kilkutygodniowe sprinty scrum’owe, aż do kilku dni, czy wręcz godzin potrzebnych na napisanie pojedynczego mikroserwisu.

Co to zmienia w procesie deweloperskim? Przede wszystkim rolę osób odpowiedzialnych za utrzymanie środowisk – w świecie mikroserwisów taka rola zaczyna być coraz mniej potrzebna ze względu na automatyzacje procesów zarządzania środowiskami i ich monitorowania. Zmieniają się też role samych deweloperów. Tworząc mikroserwisy, możemy płynnie zmieniać technologie – każdy serwis, jako osobne środowisko, może być napisany w innym języku. Fred George zaproponował nowy sposób rozróżniania kompetencji deweloperów. Wg niego pozycje takie jak senior czy expert (czyli osoby bardzo dobrze znające konkretną technologię) zaczynają być mniej potrzebne niż pozycja, którą nazywa „system deweloper”. System deweloper to programista znający bardzo dobrze system pod kątem domenowym, a także znający kilka języków, w których tworzone są serwisy – być może nie na poziomie eksperckim, ale na poziomie umożliwiającym bezproblemowe napisanie prostej funkcjonalności.

Czy proces wytwarzania oprogramowania pójdzie tą drogą? Czas pokaże.

 

Adrian Trenaman
Scaling microservices at Gilt

Adrian Trenaman spóźnił się na swoją prelekcję, dlatego została ona przesunięta. Dlaczego o tym piszę? Fakt ten okazał się całkiem istotny dla przebiegu prezentacji.

Spóźnienie wynikło z błędu w aplikacji, który uniemożliwił jej użytkowanie. System, w którym wystąpił błąd, oparty jest o mikroserwisy – właśnie dlatego cały wykład ukierunkowano na odpowiedź na pytanie: czy winna jest architektura i czy w systemie monolitycznym można by taki błąd wyeliminować lub lepiej zdiagnozować?

Podczas prezentacji Adrian Trenaman opowiedział o tym jak firma, w której pracuje, przeszła drogę od tradycyjnej architektury do podejścia mikroserwisowego. Polecam slajdy dostępne tutaj: http://www.slideshare.net/trenaman/geecon-microservices-2015-scaling-micro-services-at-gilt.

W kontekście wystąpienia ważna była specyfika systemu, nad którym pracuje firma autora. Otóż jest to system sprzedający luksusowe towary z dużymi zniżkami. Co najistotniejsze, cała sprzedaż rozpoczyna się codziennie o północy i trwa bardzo krótko.

Jak skalować taki system?

Adrian Trenaman sugeruje, a jakże, mikroserwisy. Zwraca uwagę na parę najistotniejszych, jego zdaniem, kwestii. Każdy serwis musi być monitorowany. Każdy musi także (koniecznie!) posiadać osobny data store – to zresztą postulat pojawiający się jeszcze podczas konferencji wielokrotnie.

Na koniec autor przedstawia kilka wyzwań, którym deweloperzy musieli stawić czoła podczas transformacji systemu od monolitu do mikroserwisów.

Najciekawszy wg mnie był problem „właściciela” serwisu. Kto jest odpowiedzialny za jego utrzymanie? Może zespół, który stworzył serwis? Wydaje się to sensowne. Niestety, rotacja pracowników w świecie IT jest dość spora, dlatego po jakimś czasie może się okazać, że w zespole nie został żaden programista, który tworzył rozwiązanie. Autor sugeruje podzielenie serwisów na zielone, żółte i czerwone. Zielone to takie, o których zespół, który je utrzymuje, może powiedzieć, że czuje się pewnie i doskonale zna ten serwis. Żółte to takie, w których zespół czuje się na tyle pewnie, że jest w stanie napisać szybką poprawkę lub zmianę. Czerwone to takie, o których zespół wie bardzo mało, lub za mało aby je utrzymywać. Autor proponuje takie prowadzenie rejestru serwisów z podziałem na kolory, by czerwone były przepisywane na bieżąco – dzięki temu będą łatwe w utrzymaniu.

Na koniec prelekcji wniosek – czy przytoczony na początku błąd wynikał z projektu architektury? Zdecydowanie nie. Podejście mikroserwisowe, dzięki dobremu monitoringowi, pomogło w szybkim wskazaniu miejsca, w którym problem wystąpił. Mikroserwis, który odpowiadał za wystąpienia problemu został w kilka godzin (!) przepisany i zdeployowany na środowisko produkcyjne.

 

Bert Jan Schrijver
Swimming upstream in the container revolution: Containerless Continuous Delivery

Bert Jan Schrijver skupił się w swoim wystąpieniu na automatyzacji procesu wytwarzania oprogramowaniu w systemach zbudowanych na mikroserwisach. Zasady przedstawione przez autora są jednak na tyle uniwersalne, że według mnie powinny znaleźć także zastosowanie w systemach monolitycznych. Dużą wartością prezentacji było przedstawienie wyżej wymienionych reguł na przykładzie rzeczywistego systemu tworzonego przez firmę autora.

Poniżej najciekawsze, moim zdaniem, punkty.

Master branch jest zawsze gotowy do release’a – podejście dosyć popularne: funkcjonalność tworzymy i testujemy na dedykowanym branchu. Jednak jeśli założymy dodatkowo, że w każdej chwili możemy wypuścić master brancha na produkcję, znacząco zwiększa to uwagę i dokładność programistów, a to zawsze poprawia jakość.

Każdy commit jest dokładnie testowany – banał, prawda? Bert Schrijver rozwinął jednak to zagadnienie: testy jednostkowe i integracyjne, nie tylko kodu javowego, ale także java scriptowego. Do tego testy mutacyjne oraz testy end-to-end.

„Deployments are roll-forward only” – tylko do przodu, chciało by się rzecz. W opisywanym projekcie podczas wdrożeń nie tworzy się backupów – mając architekturę opartą o mikroserwisy, można szybko i sprawnie poprawiać błędy, które ujawniają się dopiero na produkcji. Po co wycofywać 5 dobrych funkcjonalności skoro tylko w jednej jest bug?

Automatyzacja zarządzania infrastrukturą – nigdy nie logujemy się na serwer (aplikacji, bazy danych, itp.). Jeżeli chcemy to zrobić, to znaczy, że coś jest nie tak. Cała konfiguracja serwerów powinna być zautomatyzowana, np. z użyciem chefa. Chcesz zmienić coś na serwerze? Zmień „receptę”, nie loguj się na serwer.
Monitoring systemów – zasada powtarzana jak mantra przez całą konferencję. Nie ma dobrej aplikacji opartej na mikroserwisach bez automatycznego monitoringu. Nikt nie jest w stanie codziennie sprawdzać logów ze 500 środowisk. Niech robią to za nas automaty.

 

Jarosław Pałka
3 (or more) fallacies of microservices in a monolithic world

Krytyczny głos na konferencji wychwalającej mikroserwisy. Moim zdaniem bardzo potrzebny.

Poza walorami humorystyczno-rozrywkowymi (Jarosław Pałka jest prelegentem dość specyficznym), pojawiły się także konkrety. Zarzuty to m.in: szybkość działania mikroserwisów – niepotrzebny (w niektórych przypadkach) narzut na komunikacje. Koszt utrzymania wielu środowisk. Konieczność przekonania osób decyzyjnych do takiego rozwiązania – po co zmieniać coś co „działa”?

Pojawiły się także argumenty mniej merytoryczne. Jarosław Pałka sugeruje na przykład, że rozbijanie funkcjonalności na bardzo małe zmniejsza, owszem, poziom złożoności problemów, ale co za tym idzie – powoduje, że programiści zaczynają się nudzić. A znudzony programista to taki, który w najbliższym czasie będzie szukał nowej pracy. Teoria grubymi nićmi szyta.

Ciekawe było przywołanie paradygmatów i podejść z lat 70tych i 80tych, które były bliźniaczo podobne do mikroserwisów a jednak umarły śmiercią naturalną.

Taki sam los wg autora czeka architekturę opartą o mikroserwisy.

Pozostaje nam śledzić nowe trendy i przekonać się, kto miał rację.

 

Czy konferencja spełniła moje oczekiwania? Tak, szczególnie pouczające były przedstawione use case’y – zwracające uwagę nie tylko na aspekty techniczne, ale także na aspekt “ludzki” w procesie transformacji od monolitu do mikroserwisów. Czy można było zrobić coś lepiej? Na pewno tak. Wg mnie zabrakło części zorientowanej na praktykę. Warsztaty z konkretnych technologii mających swoje zastosowanie w prezentowanym podejściu (np. Docker) byłyby świetnym dopełnieniem wydarzenia.

Dodaj komentarz