Common, Utils w mikroserwisowym świecie

Cześć
jak wiadomo są rzeczy, które robi się "wszędzie" - parsowanie JSON-a, pobieranie daty, obrabianie stringów, obliczanie czegoś na podstawie np czasu
różne takie "przyda się" tu nazwane COMMON, UTILS
coś co nie jest logiką biznesową, ale takim narzędziownikiem, gdzie są różne potrzebne funkcje

jest aplikacja mikroserwisowa
każdy serwis korzysta z czegoś takiego - jeden bardziej inny mniej, ale korzysta

i teraz moje pytanie
taki COMMON, UTILS - to ma być

• osobnym serwisem, wliczając w to jakieś chmurowe lambdy (tu minus to narzut na komunikacje)
• pakietem, nugetem (tu minus, ze modyfikacja zmienia wersję i potem podbijanie tego wszędzie)
• jako project dependencies (tu minus, usztywnienie struktury katalogów)

Myślałem nad tym i nie widzę na razie rozwiązania które by mnie urzekło
jeśli możecie się podzielić swoimi przemyśleniami, pomysłami to z góry dziękuję

Pytanie się pojawia, co Ty rozumiesz przez słowo "mikroserwis":

1. Fantazja i hype: że "mikroserwisy" to po prostu kontenery które gadają przez HTTP
2. Prawdziwe mikroserwisy, które są niezależnie deployowalne, są dopasowane do bounded context, nie testuje się ich razem, etc.

Jeśli to pierwsze, to tak na prawdę nie masz mikroserwisów, tylko rozdystrybuowany monolity ze swoimi wadami i zaletami, tylko że dodatkowo jeszcze z latency sieci, i zwiększonym poziomem skomplikowania. Jeśli masz takie podejście, to w sumie wszystko jedno gdzie wydzielisz te swoje utilsy, bo to i tak nawet obok mikroserwsiów nie stało.

Jeśli to drugie, i na prawdę chcesz mieć mikroserwisy - to one idealnie nie powinny mieć ze sobą nic wspólnego. Całym sensem MS jest to że można je deployować niezależnie od siebie, więc takie powiązanie są niepożądane. Jeśli chcesz wydzielać wspólne rzeczy z mikroserwisów, to równie dobrze mógłbyś nie mieć mikroserwisów w ogóle. Mikroserwisy to jest tak na prawdę pewien kompromis - oddajesz spójność w zamian za niezależność - kawałki Twojego kodu zaczynają siebie mniej przypominać, ale za to można nad nimi pracować niezależnie od siebie. To jest cały ich sens. Jeśli tego nie chcesz, to nie idź w MS po prostu. Jakakolwiek wspólna zależność dwóch mikroserwisów, jak np wspólna biblioteka, to jest kolejny element który dodaje tight-coupling, i sprawia że zmiana czegoś w jednym MS, w pływa na inne, a tak nie powinno być.

Więc odpowiedzią na to jest: nie wydzielać.

Większość ludzi zazwyczaj mówi o tym pierwszym.

sobbek napisał(a):

• osobnym serwisem, wliczając w to jakieś chmurowe lambdy (tu minus to narzut na komunikacje)

To na pewno nie, bo serwisy powinny być dopasowane do bounded context, a nie do jakiegoś technicznego szczegółu.

sobbek napisał(a):

• pakietem, nugetem (tu minus, ze modyfikacja zmienia wersję i potem podbijanie tego wszędzie)

Z tym podbijaniem wszędzie to też nie jest tak kolorowo, bo jeśli coś jest MS, to siłą rzeczy nie koniecznie musi się zmienić, jak Ty coś zmienisz w libce. To byłoby całkowicie spodziewane, żę dodasz wersję tej biblioteki, a różne MS w różnych momentach, jeśli w ogóle wezmą tą zmianę.

To jest cały sens mikroserwisów, żeby się rozwijały niezależnie od siebie. Jak chcesz "propagować" zmiane do wszystkich na raz, to równie dobrze mógłbyś nie mieć MS w ogóle i byłoby lepiej i szybciej zrobić to w jednym procesie.

Zdecydowanie nie ma być osobnym serwisem.
Korzystałem z takich rzeczy jako pakiet nuget i współdzielone repo. Współdzielone repo ma to do siebie że musisz zadbać o zgodność wersji funkcji i albo je jakoś wersjonować albo updatować wszędzie jak zmieniasz sygnaturę funkcji. Sprawdza się w małych projektach.
Pakiet nuget wydaję się najsensowniejszym i najwygodniejszym rozwiązaniem w rozproszonym projekcie.

Piszesz biblioteki i mikroserwisy ich używają. Serwisy konsumują biblioteki albo przez menadżer pakietów albo jako zwykły import, jak masz monorepo. Oczywiście trzeba pamiętać o tym, że

• nie powinno być żadnej business specific logiki. Dobrym wskaźnikiem, że tak nie jest może być konieczność podbijania wersji danej zależności w każdym serwisie, bo inaczej system wybuchnie
• trzeba napisać bibliotekę, backend programiści nie potrafią pisać dobrych bibliotek, bo zazwyczaj tego nie robią
• biblioteka ma mieć uzasadnienie tj. nie ma niczego podobnego na githubie/w standardowej bibliotece. To co napisałeś trochę śmierdzi, każda z tych rzeczy jest ogólno dostępna

sobbek napisał(a):

coś co nie jest logiką biznesową, ale takim narzędziownikiem, gdzie są różne potrzebne funkcje

Tak się nie robi. Wrzucenie wszystkich narzędzi do skrzynki z narzędziami słabo się kończy. Biblioteki powinny być zmodularyzowane

Riddle napisał(a):

Pytanie się pojawia, co Ty rozumiesz przez słowo "mikroserwis":

1. Fantazja i hype: że "mikroserwisy" to po prostu kontenery które gadają przez HTTP

HTTP to pełnoprawny sposób komunikacji między mikroserwisami. Trzeba tylko zrobić to na odpowiednim poziomie abstrakcji - nie hardkodować URLa innego serwisu, tylko mieć poprawne API/service discovery. Wysłanie requesta "zablokuj 1000 pln z konta X" jest ok. Wysłanie requesta "POST https://mydomain.com/user-service/block amount=1000 currency=USD userId=1234" nie jest ok. Protokół tutaj w sumie nie ma znaczenia, tight coupling można równie dobrze zrobić przez kafkę czy grpc. Example: https://microservices.io/patterns/communication-style/rpi.html

sobbek napisał(a):

i teraz moje pytanie
taki COMMON, UTILS - to ma być

• pakietem, nugetem (tu minus, ze modyfikacja zmienia wersję i potem podbijanie tego wszędzie)

To jest dobre podejście, ale bez tego wymuszonego podbijania wersji. Traktuj to jak zewnętrzną libkę. Czy zawsze bezkrytycznie podbijasz wersje zewnętrznych zależności? Nie (a przynajmniej nie powinieneś), tutaj zastosuj takie samo podejście. Podbijaj dopiero jak musisz - bo jest nowy feature, bo jest security patch, bo nowa wersja działa szybciej a zależy ci na wydajności.

hawus napisał(a):

Riddle napisał(a):

Pytanie się pojawia, co Ty rozumiesz przez słowo "mikroserwis":

1. Fantazja i hype: że "mikroserwisy" to po prostu kontenery które gadają przez HTTP

HTTP to pełnoprawny sposób komunikacji między mikroserwisami. Trzeba tylko zrobić to na odpowiednim poziomie abstrakcji - nie hardkodować URLa innego serwisu, tylko mieć poprawne API/service discovery. Wysłanie requesta "zablokuj 1000 pln z konta X" jest ok. Wysłanie requesta "POST https://mydomain.com/user-service/block userId=1234" nie jest ok. Protokół tutaj w sumie nie ma znaczenia, tight coupling można równie dobrze zrobić przez kafkę czy grpc. Example: https://microservices.io/patterns/communication-style/rpi.html

Tak, ale to jest tylko środek do celu, a nie cel.

Celem jest niezależny deployment - jeśli dwa "mikroserwisy" nie mogą być niezależnie zdeployowane, to mimo tego że gadają przez sieć po HTTP, to nie są mikroserwisami.

Tabelka:

	niezależny deployment	brak niezależnego deploymentu
komunikacja przez http	MS	not MS
komunikacja przez dowolny inny protokół	MS	not MS
są na tej samej maszynie	MS	not MS
są na różnych maszynach	MS	not MS
są w osobnych procesach	MS	not MS
są w tym samym procesie	MS	not MS
mają dockera	MS	not MS
nie mają dockera	MS	not MS
mają k8s	MS	not MS
nie mają k8s	MS	not MS
testuje się je razem	not MS	not MS
testuje się osobno	MS	not MS
zmiana w jednym wymusza zmianę w drugim	not MS	not MS

Riddle napisał(a):

2. Prawdziwe mikroserwisy, które są niezależnie deployowalne, są dopasowane do bounded context, nie testuje się ich razem, etc.

Jak się nie testuje razem? To jakiś nonsens, który zabije Ci CI/CD.

helmChart#1
-> dependency on serviceA.v1
-> dependency on serviceB.v2
-> dependency on serviceC.v3
-> integracja serviceD.v4

helmChart#2
-> dependency on serviceA.v2
-> dependency on serviceB.v3
-> dependency on serviceC.v4
-> integracja serviceE.v5

I teraz jak masz dojrzałe CI/CD i zmianę w serviceA, to oprócz testów w ramach CI/CD, ta zmian triggeruje Ci CI/CD fla app#1 i app#2. Więc jak najbardziej się to testuje.

yarel napisał(a):

Jak się nie testuje razem? To jakiś nonsens, który zabije Ci CI/CD.

Co do tego że się nie testuje:

• No nie testuje się, bo gdyby się testowało, to nie można by ich deployować niezależnie od siebie (failujący test sprawiłby że nie można zrobić deploya).

Co do tego że zabije CI:

• Nie zabije, dlatego że mikroserwisy mają być niezależnie deployowalne, czyli żaden jeden mikroserwis nie zepsuje drugiego.

Myślę że większość ludzi kiedy mówi "mikroserwis" to ma na myśli po prostu kontenery które gadają po HTTP.

Tylko i wyłącznie jako pakiet z osobnym repo, wersjonowaniem i dbaniem o to, by był prawdziwym utilsem. Myśl o tym jak o każdej zewnętrznej bibliotece której używasz. Piszesz o NuGet więc jest duże prawdopodobieństwo, że dłubiesz w dotnecie, więc myśl i traktuj swoje utilsy jak Automappera czy FluentValidation czy jakąkolwiek zewnętrzną bibliotekę. Przecież użycie jednego czy drugiego nie sprawia, że nagle znika autonomia i następuje coupling pomiędzy usługami co nie? Tak samo powinno być z twoimi utilsami.

To tyle teorii. Z doświadczenia mogę ci powiedzieć, że prędzej niż później pojawia się chęć wciśnięcia w utilsa jakiejś logiki bo nagle okazuje się, że taki sam kod lub zachowanie pojawia się w dwóch czy trzech mikroserwisach i nie możesz wtedy ulec pokusie "deduplikacji kodu".

Powodzenia.

Nie upieram się przy swoim punkcie widzenia, ale jeśli ktoś pisze, że jak coś jest testowane w połączeniu z innymi serwisami, to wyklucza to ten byt jako mikroserwis, to dla mnie to nonsens.

Weźmiemy taki przykład (dla wyrobienie sobie poglądu, czy #1,#2,#3 mogą być mikroserwisami):

• serwis#1 kalkulator - dostarcza zaawansowanych operacji matematycznych jak np. dodawanie, dzielenie , mnożenie (stack w Javie, CI/CD na AWS)
• serwis#2 kalkulator kalorii - wykorzystuje serwis#1 tak, żeby dodać kalorie ze 100g kurczaka i 200g ryżu (czy czego tam sobie user życzy), (stack Rust, CI/CD na GCP)
• serwis#3 kalkulator wynagrodzeń - wykorzystuje serwis#2 tak, żeby przeliczać zarobki brutto na netto (C#, CI/CD na Azure)

Rozwijane przez osobne zespoły, oddzielne repozytoria, różne strategie releasowania.

Releasuję serwis - przeszedł jakąś procedurę w efekcie, której opublikowałem serwis nadający się do produkcyjnego użycia (obraz dockerowy w repozytorium dockerowym, helm chart w repozytorium helmowym)
Deplojuję serwis - podnoszę instancję serwisu w jakimś środowisku (i ta instancja jest współdzielona, ale nie musi - bo to zależy od modelu deploymentu)

serwis#1 został zreleasowany w wersjach v1,v2,v3
serwis#2,#3 - zrelesowany z jakąś konkretną zależnością do serwis#1 (np. v2) - to zależy od strategii przyjętej dla releasowania tego serwisu

Team chce wypuścić nowy release Serwis#1 - jak masz dojrzałe CI/CD to dopali Ci piepeliny dla serwis#2 i serwis#3 z wykorzystaniem tej wersji kandydującej do nowego releasu (jak masz mikroserwisy, a nie masz CI/CD, to... to nie wiem, mój umysł nie dopuszcza takiego obrazu). Takie pipeline'y albo przejdą, ale się wywalą. Jak przejdą, to proces release może lecieć dalej, jak się wywalą, tzn. że problem jest w serwis#1 i/lub serwisach, które z niego korzystają. Piepeline się wywalił, trzeba sprawdzić, gdzie problem i naprawić.

Składam produkt z mikroserwisów i miałbym nie testować wpływu zmian poszczególnych serwisów na cały produkt?

@yarel No tak.

Powiem to najprościej jak mogę:

1. Mikroserwis ma być deployowalny niezależnie od innych mikroserwisów.
2. Ergo. Jeśli nie jest niezależnie deployowalny, to nie jest mikroserwisem.

W Twoim scenariuszu:

Team chce wypuścić nowy release Serwis#1 - jak masz dojrzałe CI/CD to dopali Ci piepeliny dla serwis#2 i serwis#3 z wykorzystaniem tej wersji kandydującej do nowego releasu (jak masz mikroserwisy, a nie masz CI/CD, to... to nie wiem, mój umysł nie dopuszcza takiego obrazu). Takie pipeline'y albo przejdą, ale się wywalą. Jak przejdą, to proces release może lecieć dalej, jak się wywalą, tzn. że problem jest w serwis#1 i/lub serwisach, które z niego korzystają. Piepeline się wywalił, trzeba sprawdzić, gdzie problem i naprawić.

Problem leży tutaj: Piepeline się wywalił, trzeba sprawdzić, gdzie problem i naprawić.. Właśnie dlatego że musisz sprawdzić gdzie jest problem i naprawić, to dlatego to nie jest mikroserwis. Mikroserwis powinieneś móc normalnie wdrożyć na produkcję.

Drugi raz już mówisz o tym że chcesz praktykować continuous integration i continuous delivery - super idea. Jeśli tak, to powinieneś uruchamiać test na instancji jednego mikroserwisu (bez innych), i jeśli przejdą to robisz deploy na proda, jeśli nie to poprawiasz ten jeden mikroserwis. Nigdy nie dochodzi do sytuacji w której testujesz jeden mikroserwis z innymi - bo jeśli taki test przejdzie, to nie mozesz ich zrelease'ować - a mikroserwisem coś jest tylko wtedy jak możesz to zreleaseować niezależnie od innych.

Nie wiem ile razy muszę wałkować to samo.

yarel napisał(a):

Weźmiemy taki przykład (dla wyrobienie sobie poglądu, czy #1,#2,#3 mogą być mikroserwisami):

• serwis#1 kalkulator - dostarcza zaawansowanych operacji matematycznych jak np. dodawanie, dzielenie , mnożenie (stack w Javie, CI/CD na AWS)
• serwis#2 kalkulator kalorii - wykorzystuje serwis#1 tak, żeby dodać kalorie ze 100g kurczaka i 200g ryżu (czy czego tam sobie user życzy), (stack Rust, CI/CD na GCP)
• serwis#3 kalkulator wynagrodzeń - wykorzystuje serwis#2 tak, żeby przeliczać zarobki brutto na netto (C#, CI/CD na Azure)

To jest po prostu monolit, którego moduły gadają przez HTTP. Ten projekt nie jest mikroserwisami, bo poszczególne serwisy nie są wystarczająco odseparowane od siebie.

Riddle napisał(a):

@yarel No tak.

Powiem to najprościej jak mogę:

1. Mikroserwis ma być deployowalny niezależnie od innych mikroserwisów.
2. Ergo. Jeśli nie jest niezależnie deployowalny, to nie jest mikroserwisem.

Rozróżniasz deployment od releasu?

yarel napisał(a):

W uproszczeniu: Release - produkujemy binarke, Deployment - uruchamiamy

Dobrze, no więc w kontekście mikroserwisów - nie ważne czy mówisz o budowaniu binarki, czy o jej uruchamianiu - jeśli dodajesz zmianę w serwisie#1 w Twoim przykładzie, jego testy przechodzą (tego pojedynczego serwisu), chcesz zbudować lub uruchomić binarkę, i potem testujesz go z innymi serwisami (celem zbudowania lub uruchomienia binarki, nie istotne) - i w wypadku sfailowanych testów wprowadzasz poprawkę w serwisie#1 - to to nie jest mikroserwis.

Mając mikroserwis powinieneś móc wprowadzić zmianę w nim, i jeśli jego testy przejdą, to koniec Twojej pracy, możesz release'ować/deployować, bez sprawdzania Twoich zmian z innymi mikroserwisami - to jest ich największa zaleta i ich siła. Jeśli tego nie masz, to właściwie nie masz żadnych zalet które wynikają z takiej architektury, a masz same wady (dodatkowe complexity, latency, etc.)

Jeśli czujesz potrzebę że musisz przetestować serwisy razem, to to jest sygnał że one nie są tak na prawdę odseparowane od siebie - więc tak na prawdę są rozdystrybuowanym monolitem, więc nie są mikroserwisami.

Zakończenie

Ja rozumiem, że większość ludzi jak się spotyka z terminem "mikroserwis" to nie idzie sprawdzać co znaczy to słowo, tylko się domyśla że to po prostu są kontenery które gadają po HTTP i tyle. I jak się słyszy wtedy takie "radykalne" poglądy z ograniczeniami - typu że jakiś bounded context, jakaś niezależność, nie można testować - to brzmi to dziwnie. Ale to jest podejście do problemu od złej strony, to jest zwracanie zbyt dużej uwagi na narzędzia (http, docker, k8s, etc.), a zbyt mało na faktyczną treść.

Faktycznym sensem MS jest niezależna deployowalność - to jest główny cel, i po to są te zabawki wszystkie - po to są kontenery, po to jest swarm/k8s, po to jest gadanie przez sieć, po to są kontrakty, po to są porty i adaptery, i cała masa dodatkowych rzeczy - żeby umożliwić niezależny deployment. Teraz to co się niestety dzieje w branży, to jest to że ludzie dodają wszystkie te śmieci (BO HYPE, i bo mogą wpisać do CV) - ale i tak nie udaje im się osiągnąć niezależnych deploymentów - więc po co to cała zabawa?

Jakby - zastanów się: jeśli nie masz niezależnych deploymentów (bo i tak testujesz serwisy razem, i poprawka w jednym sprawia że musisz coś zmienić w innym) - to po co Ci osobne kontenery, po co docker, k8s, po co komunikacja przez sieć - czy zwykły polimorfizm i zwykłe moduły nie byłby 10x szybsze, 10x łatwiejsze i w gruncie rzeczy 10x lepsze? Większość ludzi odrzuca ten pomysł bo boi się nazwać swój projekt "monolit" - jak to? Ja mam mój super projekt nazwać monolit? Przecież wszyscy wiedzą że monolity są złe, a mikroserwisy są dobre. No właśnie nie - przywykliśmy do przekonania że słowo "monolit" oznacza spaghetti. Idąc tym krokiem, sporo ludzi myśli że jedyny sposób na jakąkolwiek sensowną modularność to jest podzielić kod na kontenery i gadać przez HTTP. No nie koniecznie - da się zbudować bardzo fajny program w jednym procesie, który ma super moduły i nie będzie spaghetti. Brak modularności jest zły, ale modularność w ramach jednego procesu jest spoko. Tylko że są tańsze i lepsze sposoby na wytworzenie sobie modularności niż MS.

Riddle napisał(a):

yarel napisał(a):

W uproszczeniu: Release - produkujemy binarke, Deployment - uruchamiamy

Dobrze, no więc w kontekście mikroserwisów - nie ważne czy mówisz o budowaniu binarki, czy o jej uruchamianiu - jeśli dodajesz zmianę w serwisie#1 w Twoim przykładzie, jego testy przechodzą (tego pojedynczego serwisu), chcesz zbudować lub uruchomić binarkę, i potem testujesz go z innymi serwisami (celem zbudowania lub uruchomienia binarki, nie istotne) - i w wypadku sfailowanych testów wprowadzasz poprawkę w serwisie#1 - to to nie jest mikroserwis.

Czyli dla Ciebie kalkulator (serwis#1) nie jest mikroserwisem, bo gdzieś zostało przetestowane jego użycie i wykazało błąd w kalkulatorze? (np. źle zaokrąglił i tego nie wyłapałeś w CI/CD kalkulatora)?
Jak testy zostaną wyłączone, to ten klakulator staje się magicznie mikroserwisem? ;-)

Mając mikroserwis powinieneś móc wprowadzić zmianę w nim, i jeśli jego testy przejdą, to koniec Twojej pracy, możesz release'ować/deployować, bez sprawdzania Twoich zmian z innymi mikroserwisami - to jest ich największa zaleta i ich siła. Jeśli tego nie masz, to właściwie nie masz żadnych zalet które wynikają z takiej architektury, a masz same wady (dodatkowe complexity, latency, etc.)

Early warning dla zespołów korzystających z tego serwisu, mniej błędów wpuszczanych na produkcję, wykrycie problemów wydajnościowych, bezpieczeństwa itp. (np. coś czego możesz nie robić, ale da się to przetestować i zatrzymać Twój mikroserwis, zanim narobi szkód). Jeśli to nie są zalety to nie wiem.

yarel napisał(a):

Czyli dla Ciebie kalkulator (serwis#1) nie jest mikroserwisem, bo gdzieś zostało przetestowane jego użycie i wykazało błąd w kalkulatorze? (np. źle zaokrąglił i tego nie wyłapałeś w CI/CD kalkulatora)?

Pośrednio ale tak.

• Gdzieś zostało przetestowane jego użycie (to jest spoko), gdzieś został znaleziony błąd (to jest spoko), na tej podstawie padła decyzja żeby nie release'ować albo dodać poprawkę do kalkulatora (i to już jest nie spoko). Przez ten ostatni krok kalkulator nie jest mikroserwisem, bo coś innego decyduje czy może być zrelease'owany/wdrożony czy nie.

yarel napisał(a):

Jak testy zostaną wyłączone, to ten klakulator staje się magicznie mikroserwisem? ;-)

Testy mogą chodzić nadal tak jak chodzą, tak długo jak nie uniemożliwiają release'u/deploya tego innych serwisów.

Więc w skrócie tak - jeśli release'ujesz/wdrażasz/deply'ujesz kalkulator niezależnie od innych, to jest mikroserwisem. Jeśli tego nie robisz, bo np. testy sfailowały, to nie jest.

Jak poprawnie zbudować mikroserwisy

1. Zaczynasz od pomysłu na program, robisz pojedynczy proces (bez dockerów, bez k8s, bez terraforma, bez żadnego crapu), najprostszy system jaki możesz: tylko kod, testy i może kilka bibliotek. Zakładasz że nie wiesz jak projekt będzie wyglądał (bo nie wiesz).
2. Zaczynasz dodawać po kolei funkcjonalności, po kawałku. Jak zauważasz że niektóre pasują do siebie bardziej niż inne to dzielisz je na moduły - stosując np dependency inversion, plugin architecture, piszesz testy tak żeby nie przeszkadzały Ci w refatorze.
3. Piszesz więcej funkcjonalności, dzieje się tak że te moduły które stworzyłeś nie były tak dobrze jak myślałeś więc refaktorujesz je, masz testy pod wszystko, więc jest to proste. Możliwe że interfejsy z poprzednich iteracji wymagają zmiany, bo nie pasują do aktualnych requirementów - więc trzeba je poprawić.
4. Powtarzasz 3., tak długo aż moduły przestaną się zmieniać - wtedy wiesz że są mniej więcej stabilne. Można to zaobserwować np jak przychodzi nowy feature, dodajesz go "tak po prostu" i on po prostu pasuje. Wtedy wiesz że interfejsy między modułami są stabilne.
5. Jeśli potrzebujesz więcej niezależności, to możesz podzielić swój projekt na osobne paczki, tak żeby faktycznie były bardziej niezależne od siebie - teraz nie ma z tym problemu, bo interfejsy między modułami są stabilne. Jeśli masz problem z podzieleniem aplikacji na paczki, to jest sygnał że nie powinieneś robić mikroserwisów - dlatego że jak nawet z podzieleniem na paczki masz problem, to z mikroserwisami będzie tym bardziej, więc to jeszcze nie jest na tyle dojrzały projekt żeby go podzielić. Powtarzaj krok 3. tak długo aż będzie.
6. Jeśli z jakiegoś powodu nadal potrzebujesz więcej niezależności w rozwijaniu paczek, to wtedy możesz podzielić te paczki na osobne procesy - i tutaj faktycznie najczęstszym wyborem jest docker - tylko że ten krok dodaje MASĘ dodatkowych problemów, masę - musisz mieć wirtualizacje, jwt, komunikacje przez sieć, latencje, message'ing, pewnie jakieś message broken, cała masa pierdół, w sumie tylko po to żeby móc pozwolić sobie na niezależny deployment.
7. I teraz masz można powiedzieć osobne aplikacje które ze sobą gadają, które mają stabilne interfejsy, które można rozwijać od tej pory niezależnie (a więc i nie testować ich razem, tylko traktować tak jak inne integracje, takie jak np. z paypalem albo stripem).

Powstałe w ten sposób interfejsy są wynikiem wielu iteracji, i zostały przyklepane dopiero jak przestały się zmieniać, przez co są stabilne.

Jak większość ludzi robi mikroserwis

1. Zaczyna od razu z dockerami i kubernetesami (błąd)
2. Zakłada na początku projektu że wie jakie mikroserwisy będą potrzebne (błąd)
3. Zakłada ze przewidzi dobry interfejs między nimi (błąd)
4. Nie daje sobie miejsca na naukę i eksperymenty, bo od razu buduje całą rzecz (błąd)
5. Już na starcie projektu zrobienie prostych feature'ów jest znacznie wydłużone przez wbudowane bottlenecki w serwisach (błąd)
6. Już na starcie rozwój projektu lokalnie: testy, debug, utrzymanie jest utrudnione (błąd)
7. Ktoś zauważa ze pierwsza wersja interfejsów jest nie do końca dobrze dopasowana do potrzeb, więc zmienia go w jednej apce, i uznaje że musi zmieć też w innej - dzieje się tak dlatego że interfejsy nie są stabilne, bo nie mogą być stabilne, bo nikt ich nie wypasował. Tym samym uzależnia jeden serwis od drugiego (błąd)
8. Żeby jakoś sobie poradzić z tym skomplikowaniem ludzie uciekają się do pomysłów typu "contract testing, pact", czy innych takich pomysłów, tylko po to żeby obejść swoją nieumiejętność zbudowania stabilnych interfejsów, których siłą rzeczy nie byli wstanie zrobić przez punkt 2. i 3.
9. Powstaje wydłużony feedback loop.
10. Pojawiają się bugi i problemy, więc są podejmowane decyzje o testowaniu całości razem, więc cała idea "niezależności" idzie do kosza.

Powstałe w ten sposób interfejsy nie są stabilne, dlatego że są wynikiem tylko jednej iteracji, a do tego od razu zostały "przyklepane", przez co ich zmiana jest utrudniona.

Większość ludzi wierzy że początkowe utrudnienie w końcu się zwróci - ale nie zwróci się, dlatego że te elementy nie są niezależne od siebie, więc nie dostarczają Ci tych rzeczy które obiecują. Wbudowałeś sobie w ten sposób tylko kłody pod nogi bez w sumie żadnej korzyści.

yarel napisał(a):

Early warning dla zespołów korzystających z tego serwisu, mniej błędów wpuszczanych na produkcję, wykrycie problemów wydajnościowych, bezpieczeństwa itp. (np. coś czego możesz nie robić, ale da się to przetestować i zatrzymać Twój mikroserwis, zanim narobi szkód). Jeśli to nie są zalety to nie wiem.

Wszystkie te rzeczy można równie dobrze zrobić z aplikacją działającą w jednym procesie.

Riddle napisał(a):dła decyzja żeby nie release'ować albo dodać poprawkę do kalkulatora (i to już jest nie spoko). Przez ten ostatni krok kalkulator nie jest mikroserwisem, bo coś innego decyduje czy może być zrelease'owany/wdrożony czy nie.

Wydaje mi się to błędnym założeniem, bo jeśli np. klient, decyduje, że nie chce danej wersji mikroserwisu (bo np. "w basie image jest X crictial vulnerabilities"), tzn. że coś innego (poza mikroserwisem) zdecydowało o deploymencie. I co teraz? Przestało to być mikroserwisem ze względu na to gdzie podjęto decyzję?

Większość teamów robi jednak ten błąd, że zaczyna od MS, zakłada że wie jakie mikroserwisy będą (błąd), zakłada że zna interfejsy (błąd), buduje skomplikowany system już na starcie (błąd), a potem zauważa że nie działa tak jak powinien, więc dodaje testy globalne, i tym samym doprowadza do sytuacji w której te kontenery nie są mikroserwisami tylko rozdystrybuowanym monolitem z wbudowanymi kłodami pod nogami w postaci latencji, skomplikowania, etc.

Tu byłbym ostrożny, z osądami typu "większość teamów", bo ile popełnia błędy z ilu badanych i jaką te badane stanowią reprezentację całej populacji.

yarel napisał(a):

Early warning dla zespołów korzystających z tego serwisu, mniej błędów wpuszczanych na produkcję, wykrycie problemów wydajnościowych, bezpieczeństwa itp. (np. coś czego możesz nie robić, ale da się to przetestować i zatrzymać Twój mikroserwis, zanim narobi szkód). Jeśli to nie są zalety to nie wiem.

Wszystkie te rzeczy można równie dobrze zrobić z aplikacją działającą w jednym procesie.

Mam pewne wątpliwości. Jeśli nie będziesz wiedział, kto korzysta, to jak im wygenerujesz early warning na jednym procesie? Albo skąd będziesz wiedział jakie limity dostaniesz na CPU?

yarel napisał(a):

Riddle napisał(a):

dła decyzja żeby nie release'ować albo dodać poprawkę do kalkulatora (i to już jest nie spoko). Przez ten ostatni krok kalkulator nie jest mikroserwisem, bo coś innego decyduje czy może być zrelease'owany/wdrożony czy nie.

Wydaje mi się to błędnym założeniem, bo jeśli np. klient, decyduje, że nie chce danej wersji mikroserwisu (bo np. "w basie image jest X crictial vulnerabilities"), tzn. że coś innego (poza mikroserwisem) zdecydowało o deploymencie. I co teraz? Przestało to być mikroserwisem ze względu na to gdzie podjęto decyzję?

Łapiesz mnie za słówka.

Ja od początku powtarzam - mikroserwisy, każdy z osobna, ma się dać móc niezależnie od siebie deployować/wdrażać. Jeśli chcę wrzucić zmianę w serwisie#a, to nic w serwis#b, serwis#c i serwis#d nie może mi przeszkodzić w tym. Jeśli nie chcę release'ować/wdrażać serwisu #a, to nie muszę - jesli klient nie chce go release'ować/wdrażać to nie musi. Jeśli klient chce podbić inny serwis, to może. Ale jeśli zostanie podjęta próba wdrożenia, i nagle jakieś testy powiedzą "nie możesz wrzucić tej zmiany, bo to nie działa z XX", to wtedy to nie jest mikroserwis. Bo właśnie się okazało że Twój serwis jest zależny od XX (a miał nie być).

Mikroserwisy mają być niezależnie deployowalne, co to znaczy:

• nie możesz ich testować razem
• nie możesz propagować zmian w nich jednocześnie (jeśli w ogóle)
• jeden mikroserwis nie może wymusić update'a innego
• coupling powinien być ograniczony do minimum
• nie koniecznie muszą mieć te same bibioteki, te same bazy, te same wersje, te same base'y, nic nie muszą mieć wspólnego
• nie koniecznie są do siebie podobne, nie koniecznie gadają tymi samymi protokołami,

Jeśli nie pasują Ci te konsekwencje, to znaczy że nie chcesz mikroserwisów.

yarel napisał(a):

Early warning dla zespołów korzystających z tego serwisu, mniej błędów wpuszczanych na produkcję, wykrycie problemów wydajnościowych, bezpieczeństwa itp. (np. coś czego możesz nie robić, ale da się to przetestować i zatrzymać Twój mikroserwis, zanim narobi szkód). Jeśli to nie są zalety to nie wiem.

Wszystkie te rzeczy można równie dobrze zrobić z aplikacją działającą w jednym procesie.

Mam pewne wątpliwości. Jeśli nie będziesz wiedział, kto korzysta, to jak im wygenerujesz early warning na jednym procesie? Albo skąd będziesz wiedział jakie limity dostaniesz na CPU?

Jeśli nie będziesz wiedział, kto korzysta, to jak im wygenerujesz early warning na jednym procesie?. Czyli co konkretnie próbujesz zrobić? I jak posiadanie czegoś rozbitego na dwa kontenery umożliwia Ci zrobienie tego, a jak masz wszystko w jednym to już nie?

Albo skąd będziesz wiedział jakie limity dostaniesz na CPU? Co to znaczy "dostaniesz"? Chyba gubisz kontekst wypowiedzi, mówisz o tym że ktoś w firmie decyduje ile CPU dostanie Twoja apka?

Na zakończenie

@yarel Słuchaj, ja rozumiem że jest hype na mikroserwis. I rozumiem, że nawet Ci którzy robią spaghetti które nie stało obok MS, chwalą się że mają, bo hype. Wiem że Google i Netflix robią microserwisy. I docker, i k8s, i devops to jest strasznie popularna rzecz. I rozumiem, że ktoś może kilka lat pracować w projekcie z kontenerami po networku i myśleć o sobie "Ooo, I'm a microservice developer", i to jest słabe nagle się dowiedzieć że tak na prawdę to nie był mikroserwis.

No ale pytanie czy wolisz żyć w strefie fantazji, czy jednak wolisz robić dobry software który dostarcza faktycznych zalet.

Riddle napisał(a):

Jeśli nie będziesz wiedział, kto korzysta, to jak im wygenerujesz early warning na jednym procesie?. Czyli co konkretnie próbujesz zrobić? I jak posiadanie czegoś rozbitego na dwa kontenery umożliwia Ci zrobienie tego, a jak masz wszystko w jednym to już nie?

Mam wrażenie, ze odnosisz się do implementacji jakiegoś serwisu (a w zasadzie do jego działającej instancji, bo piszesz o kontenerach), a nie procesów CI/CD (nie w sensie procesu systemu operacyjnego, a raczej ciągu aktywności), o których pisałem w przykładzie. Zespół#1 pracuje nad serwis#1 na infrastrukturze A, zespół#2 pracuje nad serwis#2 na infrastrukturze B (osobne zespoły, repozytoria kodu, chmury, osobne flow CI/CD, stosy technologiczne). Zespół#1 nie wie kto będzie korzystał z tego serwisu. Mimo to chce mieć early warning dla siebie ("coś może być nie tak z tym releasem kandydującym do produkcyjnego") i umożliwić innym wcześniejszą reakcję ("wywali się wam na najnowszej wersji X") i nie dopuścić do automatycznego produkcyjnego release service#1, do czasu ogarnięcia przyczyny.

Co Ty byś chciał tu na jednym procesie implementować?

Albo skąd będziesz wiedział jakie limity dostaniesz na CPU? Co to znaczy "dostaniesz"? Chyba gubisz kontekst wypowiedzi, mówisz o tym że ktoś w firmie decyduje ile CPU dostanie Twoja apka?

Tak, ustawianie quoty/hard/soft limits, to normalna praktyka. Ustawiasz limity na CPU/pamięć, tak by jakiś serwis nie zjadł zasobów innym. Może to szok, ale przy testach wydajnościowych możesz zasoby zmieniać w dwóch kierunkach (dodawać i obcinać) w ten sposób identyfikować problemy. Nie każdy k8s działa w modelu, który pozwala na dorzucanie zasobów na zawołanie. Niektóre on-premise i tam dodanie zasobów na żądanie nie jest takie on-demand ;)

Na zakończenie

@yarel Słuchaj, ja rozumiem że jest hype na mikroserwis. I rozumiem, że nawet Ci którzy robią spaghetti które nie stało obok MS, chwalą się że mają, bo hype. Wiem że Google i Netflix robią microserwisy. I docker, i k8s, i devops to jest strasznie popularna rzecz. I rozumiem, że ktoś może kilka lat pracować w projekcie z kontenerami po networku i myśleć o sobie "Ooo, I'm a microservice developer", i to jest słabe nagle się dowiedzieć że tak na prawdę to nie był mikroserwis.

Nie dramatyzowałbym tak z tym hajpem i "prawdziwością" czegokolwiek, czy to mikroserwisy, czy religia, czy marksizm.

No ale pytanie czy wolisz żyć w strefie fantazji, czy jednak wolisz robić dobry software który dostarcza faktycznych zalet.

Obstawiam, ze "nieprawdziwy mikroserwis", ale z dodatkowymi testami będzie skutkował mniejszą ilością problemów produkcyjnych, niż ten prawdziwy, bez dodatkowych testów. Jeśli ktoś mi pisze, że mam nieprawdziwy mikroserwis, bo mam większą automatyzacją CI/CD i testuję więcej przed wypuszczeniem na produkcję, to cóż, mogę żyć w strefie fantazji i bez etykietki "prawdziwych" mikroserwisów. NIe mam z tym problemu.

Można być twórcą prawdziwych mikroserwisów, prawdziwym DevOoopsem (dodatkowe oo = większy prestiż ;) ), ale może warto nomenklaturę postawić na dalszym miejscu i skupić się na jakości finalnego produktu i być mniej DevOoopsem, a bardziej DevOpsem?

yarel napisał(a):

Obstawiam, ze "nieprawdziwy mikroserwis", ale z dodatkowymi testami będzie skutkował mniejszą ilością problemów produkcyjnych, niż ten prawdziwy, bez dodatkowych testów. Jeśli ktoś mi pisze, że mam nieprawdziwy mikroserwis, bo mam większą automatyzacją CI/CD i testuję więcej przed wypuszczeniem na produkcję, to cóż, mogę żyć w strefie fantazji i bez etykietki "prawdziwych" mikroserwisów. NIe mam z tym problemu.

Można być twórcą prawdziwych mikroserwisów, prawdziwym DevOoopsem (dodatkowe oo = większy prestiż ;) ), ale może warto nomenklaturę postawić na dalszym miejscu i skupić się na jakości finalnego produktu i być mniej DevOoopsem, a bardziej DevOpsem?

Nie wiem ile razy mam to mówić: od początku Ci powtarzam że to co Ty masz to nie są mikroserwisy - (bo skoro testujesz "serwisy" razem, to nie są mikroserwisami). Więc z łaski swojej nie wprowadzaj ludzi w błąd.

Cieszę się że w końcu się zgadzamy.

yarel napisał(a):

Obstawiam, ze "nieprawdziwy mikroserwis", ale z dodatkowymi testami będzie skutkował mniejszą ilością problemów produkcyjnych, niż ten prawdziwy, bez dodatkowych testów. Jeśli ktoś mi pisze, że mam nieprawdziwy mikroserwis, bo mam większą automatyzacją CI/CD i testuję więcej przed wypuszczeniem na produkcję, to cóż, mogę żyć w strefie fantazji i bez etykietki "prawdziwych" mikroserwisów. NIe mam z tym problemu.

Obstawiam, ze "nieprawdziwy mikroserwis", ale z dodatkowymi testami będzie skutkował mniejszą ilością problemów produkcyjnych, niż ten prawdziwy, - czyli pozbywając się wyśmiewczych elementów, nazwijmy to po imieniu: "Obstawiam że rozdystrybuowany monolit będzie skutkował mniejszą ilością problemów produkcyjnych, niż mikroserwis".

I tak. Dokładnie tak jest.

A jeszcze mniej problemów dostarczyłaby jedna aplikacja w jednym procesie.

Riddle napisał(a):

yarel napisał(a):

Obstawiam, ze "nieprawdziwy mikroserwis", ale z dodatkowymi testami będzie skutkował mniejszą ilością problemów produkcyjnych, niż ten prawdziwy, bez dodatkowych testów. Jeśli ktoś mi pisze, że mam nieprawdziwy mikroserwis, bo mam większą automatyzacją CI/CD i testuję więcej przed wypuszczeniem na produkcję, to cóż, mogę żyć w strefie fantazji i bez etykietki "prawdziwych" mikroserwisów. NIe mam z tym problemu.

Można być twórcą prawdziwych mikroserwisów, prawdziwym DevOoopsem (dodatkowe oo = większy prestiż ;) ), ale może warto nomenklaturę postawić na dalszym miejscu i skupić się na jakości finalnego produktu i być mniej DevOoopsem, a bardziej DevOpsem?

Nie wiem ile razy mam to mówić: od początku Ci powtarzam że to co Ty masz to nie są mikroserwisy - (bo skoro testujesz "serwisy" razem, to nie są mikroserwisami). Więc z łaski swojej nie wprowadzaj ludzi w błąd.

Cieszę się że w końcu się zgadzamy.

I w tym cały problem, przyjmujesz coś za pewnik (że się zgadzamy), bo tak Ci się wydaje. Mogę się mylić, Ty się możesz mylić, możemy się mylić obydwaj, trudno żebyśmy razem mieli rację. Napisałem dlaczego uważam, ze nazywanie czegoś "nieprawdziwym" mikroserwisem, bo jest szerzej testowane, jest nonsensem. Ty się upierasz, ze to monolit rozproszony/nieprawdziwy mikroserwis, tylko na podstawie tego, że są robione dodatkowe testy. Ani kodu, ani wglądu w testy, ani w strategię releasowania poszczególnych serwisów, ani CI/CD, a przesz do przodu jak koń z klapkami na oczach.

Idąc takim tokiem rozumowania, jeśli serwis jest przez coś wywoływany, to prawdopodobnie nie jest prawdziwym mikroserwisem, no bo przecież trzeba by to wywołanie przetestować, a wiadomo, że jak testujemy, to już nie jest to mikroserwis.

yarel napisał(a):

I w tym cały problem, przyjmujesz coś za pewnik (że się zgadzamy), bo tak Ci się wydaje. Mogę się mylić, Ty się możesz mylić, możemy się mylić obydwaj, trudno żebyśmy razem mieli rację. Napisałem dlaczego uważam, ze nazywanie czegoś "nieprawdziwym" mikroserwisem, bo jest szerzej testowane, jest nonsensem. Ty się upierasz, ze to monolit rozproszony/nieprawdziwy mikroserwis, tylko na podstawie tego, że są robione dodatkowe testy. Ani kodu, ani wglądu w testy, ani w strategię releasowania poszczególnych serwisów, ani CI/CD, a przesz do przodu jak koń z klapkami na oczach.

Nie muszę zaglądać Ci w gardło, żeby wiedzieć, że jeśli jesteś człowiekiem - to nie masz skrzeli. A jeśli masz skrzela, to nie jesteś człowiekiem (tylko najpewniej rybą).

Podobnie mogę stwierdzić - jeśli masz mikroserwisy, to nie możesz testować ich razem - a jak testujesz, to to nie są mikroserwisy.

Jak już ustaliliśmy - Ty masz w projekcie kilka oddzielnych elementów, które testujesz razem. Więc projekt który masz to jest rozdystrybuowany monolit, a nie mikroserwisy.

yarel napisał(a):

Idąc takim tokiem rozumowania, jeśli serwis jest przez coś wywoływany, to prawdopodobnie nie jest prawdziwym mikroserwisem, no bo przecież trzeba by to wywołanie przetestować, a wiadomo, że jak testujemy, to już nie jest to mikroserwis.

Mikroserwisy mogą się wołać nawzajem. Nawet muszą, inaczej byłyby oddzielnymi aplikacjami. Natomiast jeśli testujesz te wywołania, i w wypadku failu takiego wywołania ich nie deploy'ujesz, to niestety to nie są mikroserwisy. Bo skoro przez failujący test nie wdrażasz/release'ujesz/deploy'ujesz apki - to siłą rzecz test z innym serwisem Ci w tym przeszkodził, ERGO nie jest niezależnie deployowalny. Ile razy można to wałkować.

Wydaje mi się że umyka Ci idea "niezależnego deployowania/wdrażania". I dlatego wydaje Ci się że microserwisami są po prostu dwie apki które gadają po HTTP.

jeśli serwis jest przez coś wywoływany, [...], no bo przecież trzeba by to wywołanie przetestować - co do tego. W gruncie rzeczy tak - interakcji między mikroserwisami się nie testuje. Polega się na stabilnych interfejsach, oraz portach i adapterach, jak również wersjonowaniu, żeby zapewnić komunikację. Jak wytworzyć takie stabilne interfejsy, opisałem tutaj: #1956027 Ale powtarzam - między mikroserwisami. Jak masz rozdystrybuowany monolit, to rób co chcesz. (Ja osobiście jednak uważam że pojedyczna aplikacja w pojedynczym procesie, ewentualnie z kilkoma instancjami, jest dużo lepsza niż taki rozdytrybuowany monolit, ale co kto woli).

że jak testujemy, to już nie jest to mikroserwis. - możesz testować każdy mikroserwis z osobna, jest to dobre. Nie można tylko testować ich razem - bo jeśli testujesz ich razem to są zależne od siebie, ergo wypłwają na swój release/deploy, ergo nie są niezależnie deployowalne, ergo nie są mikroserwisami.

Tak naprawdę nikt nie ma mikroserwisów bo wystarczy, że masz testera manualnego lub napisany test E2E i to już nie jest mikroserwis

anonimowy napisał(a):

Tak naprawdę nikt nie ma mikroserwisów bo wystarczy, że masz testera manualnego lub napisany test E2E i to już nie jest mikroserwis

Jeśli ten tester manualny lub test e2e jest częścią release'u, to tak - serwisy nie są niezależnie deployowalne, a więc nie są mikroserwisami.

Bo tak widziałeś na jakimś filmiku na YT i w to uwierzyłeś?

anonimowy napisał(a):

Bo tak widziałeś na jakimś filmiku na YT i w to uwierzyłeś?

Bo mikroserwisy mają być niezależnie deployowalne, a testowanie ich razem sprawia że nie są.

@Riddle dzięki za dyskusję.

Polecam: https://pages.awscloud.com/rs/112-TZM-766/images/A-Roadmap-to-Continuous-Delivery-Pipeline-Maturity-dev-whitepaper.pdf

Tam możesz zobaczyć na jakim poziomie jesteś ze swoimi nietestowanymi integracyjnie mikroserwisami w kontekście dojrzałości automatyzacji dostarczania na produkcję, i to z perspektywy personalnej ("gdzie jestem, a gdzie mogę być"), jak i firmowej ("gdzie jest firma, czy mam szansę się w niej rozwinąć").

yarel napisał(a):

@Riddle dzięki za dyskusję.

Polecam: https://pages.awscloud.com/rs/112-TZM-766/images/A-Roadmap-to-Continuous-Delivery-Pipeline-Maturity-dev-whitepaper.pdf

Tam możesz zobaczyć na jakim poziomie jesteś ze swoimi nietestowanymi integracyjnie mikroserwisami w kontekście dojrzałości automatyzacji dostarczania na produkcję, i to z perspektywy personalnej ("gdzie jestem, a gdzie mogę być"), jak i firmowej ("gdzie jest firma, czy mam szansę się w niej rozwinąć").

Ale ja jestem bardzo dużym fanem Continuous Integration i Continuous Delivery, takżę pod tym względem się podpisuje obiema rękami. Sam się staram w taki sposób pracować. To jest jedna z lepszych rzeczy w programowaniu, i dobrze jest ją mieć wszędzie.

Tylko że mikroserwisy ciężko w taki sposób dostarczać, niestety. Dlatego również nie jestem fanem Mikroserwisów.

Pozwól że podsumuję:

• Jestem fanem CI/CD, zarówno continuous integration, delivery (a żeby mieć con. delivery, trzeba mieć con. deployment).
• Z mikroserwisami ciężko jest mieć CI/CD, niestety.
• Dlatego ja się zgadzam że dużo lepszym stylem pracy, zwłaszcza na początku jest pojedyncza aplikacja z CI/CD. To jest miód malina.

Myślę że ponieważ w tym wątku próbowałem bronić definicji mikroserwisów - to odniosłeś wrażenie że ja uważam że to jest lepsze? Moim zdaniem nie jest, moim zdaniem nie powinno się mieć mikroserwisów w 95% projektów, bo pod wieloma względami jest to dużo trudniejsze. Pojedyncza apka wytwarzania z CI/CD jest 10x lepszym pomysłem. Ale mimo to, wiem co znaczy słowo "mikroserwis" i wiem żę większość ludzi tutaj kiedy mówi "mikroserwis" tak na prawdę nie ma mikroserwisów - mają rozdystrybuowany monolit. I starałem się wykazać - co musieliby mieć w swoich aplikacjach,żeby mogli je nazwać "mikroserwisem". Ale czy ja zalecam żeby ktoś miał mikroserwisy? Nie.

kelog napisał(a):

Czyli - dla jasności - jeśli testy e2e nie są częścią releasu (czyli mamy np. team QA który klika albo pali Selenium na już wdrożonej produkcji) to jest ok?

Tak i nie.

Teoretycznie, gdyby testy i QA działały tylko na produkcji, i ich feedback w żaden sposób nie wpływałby na rozwój mikroserwisu (np. nie blokuje release'ów, i nie wymusza kolejnych) - to tak. Wtedy można powiedzieć że to jest mikroserwis.

Ale czy faktycznie chcesz mieć mikroserwis? Faktycznie potrzebujesz niezależnego deploymentu? Faktycznie potrzebujesz całej tej nabudówki? Czy zwykła pojedyncza apka nie byłaby znacznie prostsza do utrzymania, dostarczenia, debugowania? Czy korzystanie z CI/CD i TDD w ramach pojedynczego projektu nie byłoby dużo znacznie lepszym pomysłem? Moim zdaniem byłoby.

PS: Tylko że taki sposób pracy, z mojego doświadczenia wynika że jest niestabilny - tzn. on się przeradza zazwyczaj w jedną z dwóch odnóg. Albo w pewnym momencie takie testy są porzucane, skoro i tak z ich feedbacku się nie korzysta; albo zaczynają być brane pod uwagę w release'ach i wtedy znowu tracimy mikroserwisy, i znowu mamy rozdystrybuowany monolit.

Odnoszę silne wrażenie, żę większość ludzi dlatego chce mieć mikroserwisy bo to jest po prostu modne słowo, jest hype, i chce móc sobie to wpisać do CV - nie dlatego że faktycznie wiedzą co to jest, i nie dlatego że przynosi im jakąś korzyść.

1. Testy systemu nie służą tylko do testowania aplikacji. Ale do testowania też założeń, wymagań i konfiguracji biznesowej.
   Co z tego, że jakiś mikroserwis został zaimplementowany zgodnie z wymaganiami i działa świetnie skoro rozjechał sie system jako całość bo wymagania były błędne lub którys PO sie popierdolił przy spisywaniu wymagań.

2. tak czy siak musisz przetestować tematy infrastrukturalne, sieciowe i orkiestracji. W systemach krytycznych dochodzą chaos monkay czasami przed releasem tzn, że to nie są mikroserwisy skoro jest testowanie self healingu systemu ?

3. testy uruchamiane na produkcji to nie jest nic niewzykłego i są częścią continuous delivery

Ja np mam testy czy infrastruktura do alarmów działą na produkcji i te testy są uruchamiane co godzinę :p.

Schadoow napisał(a):

1. Testy systemu nie służą tylko do testowania aplikacji. Ale do testowania też założeń, wymagań i konfiguracji biznesowej.
   Co z tego, że jakiś mikroserwis został zaimplementowany zgodnie z wymaganiami i działa świetnie skoro rozjechał sie system jako całość bo wymagania były błędne lub którys PO sie popierdolił przy spisywaniu wymagań.

2. tak czy siak musisz przetestować tematy infrastrukturalne, sieciowe i orkiestracji. W systemach krytycznych dochodzą chaos monkay czasami przed releasem tzn, że to nie są mikroserwisy skoro jest testowanie self healingu systemu ?

3. testy uruchamiane na produkcji to nie jest nic niewzykłego i są częścią continuous delivery

Powiem to samo co wcześniej:

Oczywiście że możesz testować cały system, możesz sprawdzać czy działa, możesz mieć chaos monkey i inne takie rzeczy. Ale te elementy nie powinny wpływać w żaden sposób na release mikroserwisów. Jeśli nie wpływają - to super, masz MS. Jeśli wpływają, to niestety nie masz.