Hej!

W ciągu ostatnich kilku miesięcy zajmowałem się głównie pracą. Ogólnie byłem fizycznie i psychicznie wyczerpany. Wypalenie? Może. W każdym razie do pracy ogólnie i generalnie miałem i mam ochotę 🙂

W ciągu tych kilku ostatnich miesięcy dużo devopsowałem ( z naciskiem na dev). Sporo się nauczyłem i na pewno dużą część tego opiszę tutaj. Jednakże dzisiaj skupię się na jednym elemencie. Później opisze technikę tworzenia tego oprogramowania w szczegółach, teraz tylko komplikacje wynikłe z microserviceów (malutkich serwisów? bo mi się tu słownik pluje…).

Malutkie serwisy są super! Zapewne słyszycie to na każdym kroku. Choć to już lekko przebrzmiałą historia (sięgająca raczej 2016) mówi się, że używanie ich sprawia wiele frajdy i zadowolenia. Etc. Itd. I ja to potwierdzam. Nie jest to może najlepszy kawałek software jaki stworzyłem kiedykolwiek, ale cholera, bawiłem się świetnie.

Microservice powodują, że zmniejszają się zależności pomiędzy modułami. Wystawiane jest tylko API z jednego modułu do drugiego. Każdy właściciel kodu takiego microservice ma (może mieć) pełną wiedzę domenową (o DDD kiedy indziej). I ja to potwierdzam, z pewnymi wyjątkami. Wymaga to niezłego pilnowania się by te interfejsy ( u mnie to zawołania RESTowe) były spójne. Jak dochodzi drugi programista jest dodatkowo ciężej.

Microserwisy możesz pisać w dowolnym języku, a każdy z nich może mieć swoją bazę danych (raz NoSQL, raz SQL, a raz np. plik JSON). I ja to potwierdzam z pewnym zastrzeżeniem. Z jednej strony owszem. Każdy serwis może używać innej technologii, ale potem to trzeba wdrożyć, najlepiej automatycznie. To w pewnym momencie przestaje się opłacać. Dodatkowo, należy pamiętać, że ktoś to po Tobie musi utrzymać!!! (nikt nie jest nieśmiertelny, a każdy z nas wie, że kod może przeglądać psychopatyczny morderca). Co do baz danych jest lepiej. Faktycznie mimo, że rozwiązanie jest małe użyłem bazy CouchDB oraz właśnie prostego pliku JSON, dzięki czemu uniknąłem żmudnego produkowania UI (co i tak mnie w końcu czeka :)).

Microservice łatwo się testuje. To potwierdzam w 100%.

No to plusy mamy za sobą. O minusach pewnie też wiele słyszeliście i nie będę ich tu teraz przytaczał. Za to wprost napiszę co mi się nie podobało.

Komunikacja:

Fajna sprawa ten REST. I ta komunikacja, i to, że każdy moduł jest troszkę inny. Ale w małym projekcie to jednak za dużo (mój projekt jest mały – 1 osobowy – czasem 2). W małym projekcie ta komunikacja przytłacza i powoduje problemy. Zwłaszcza z…

Wykrywanie błędów:

Nie jest łatwo. Niby wszystko się loguje. Nawet do fajnych plików które potem się rolują. Ale nie jest łatwo. Debbuging i tak dawno odpuściłem na rzecz testów różnych. Ach, generalnie używając BDD często program odpalam dopiero na środowisku testowym. Ale jak coś się sypnie, a testy tego nie pokrywają…

Logowanie:

Każdy moduł loguje do innego pliku. Tych logów jest mnóstwo. Jak tu przejrzeć po dacie kilkaset Mb. Tzn da się. Są Splunki i inne. Ale nadal – to nie jest łatwe. Dużo trudniejsze niż debugging w Big Ball of Mud…

Ulotność:

“Kurcze nie przejmuj się, to tylko kilka linijek w całym serwisie, jak coś to to potem wywalimy i przepiszemy porządnie”. Słyszeliście coś takiego kiedyś. Od pół roku mam w planach przepisać jeden z modułów, ale jakoś nie miałem czasu. Trzeba od razu pisać porządnie.

 

Podsumowując -> Micro-serwisy ( o! Tak się nie pluje słownik) nie są proste, łatwe i przyjemne ( przyjemne są, chodziło o trój-słów ) . Coupling zamieniłem na zbytnie rozluźnienie. Wydaje mi się też, że moje serwisy są zbyt małe. Dodatkowo wokół provisioningu tego na maszyny, instalacji… Jest dużo więcej roboty. Ale ta satysfakcja… No jest. Przy czym jeśli chcielibyście użyć tego w małym projekcie – ODRADZAM. Jeśli w średnim czy dużym, to gra może być warta świeczki, bo zabawa była przednia!

 

I tymi słowy do następnego.

One Reply to “O mikro-serwisach słów kilka na podstawie doświadczeń z małym projektem.”

  1. Problem z logowaniem można próbować rozwiązać poprzez takie elementy jak Sentry, albo np. Kibana. Dobrym trickiem jest dodanie do każdego requestu pomiędzy microserwisami jakiegoś unikalnego ID który będzie potem ‘znaczył’ ciąg wywołań. Da nam to łatwy sposób na trackowanie jak przebiegała obsługa danego rządania w naszej appce.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *