@Riddle To według twojej definicji żadna firma która ma system większy od notatnika nie ma mikroserwisów.
0
0
@Riddle przecież Netflix testuje więcej rzeczy niż jesteś w stanie sobie wyobrazić i zdecydowanie testują zależności pomiędzy mikroserwisami (wedlug ciebie to już nie mikroserwis) więc dlaczego ich wymieniasz?
0
Microsoft też ma armie testerów manualnych xD
0
Nie rozumiem ile razy mogę powtarzać tą samą rzecz. Możesz testować do woli co chcesz - tak długo jak to nie wpływa na release'y mikroserwisów.
Podsumuję jeszcze raz:
- Jeśli możesz dwa serwisy wdrażać niezależnie od siebie - to masz MS.
- Jeśli nie możesz wdrażać ich niezależnie od siebie (bo jeden może wpłynąć na drugi) - to nie masz.
Ergo: jeśli masz mikroserwisy, dajmy 3. Wrzucasz je na środowisko, testujesz je razem z innymi, i test failuje, i podejmujesz decyzję "okej, to jednak nie wdrażam", to znaczy że inny mikroserwis właśnie wpłynął na Twój, ergo nie jest niezależnie deployowalny, ergo nie jest mikroserwisem, koniec dowodu.
anonimowy napisał(a):
@Riddle przecież Netflix testuje więcej rzeczy niż jesteś w stanie sobie wyobrazić i zdecydowanie testują zależności pomiędzy mikroserwisami (wedlug ciebie to już nie mikroserwis) więc dlaczego ich wymieniasz?
-
przecież Netflix testuje więcej rzeczy niż jesteś w stanie sobie wyobrazić. True. -
zdecydowanie testują zależności pomiędzy mikroserwisami. Aale to testują interfejsy, a nie mikroserwisy. Więc pojedyczny mikroserwis może nie przejść testuj - i to da się ustalić testując go samemu (jeszcze przed releasem). Nie jest to robione w grupie mikroserwisów, gdzie mogą wpłynąć na siebie.
1
@Riddle Ale to nie chodzi o faile w rozumieniu kodu. Tylko faile w rozumieniu procesu biznesowego. Których nie wykryjesz na poziomie implementacji bo muszą zostać przetestowane przez ekspertów dziedzinowych. Tu chodzi o błędy w "zamówieniach". Czym większa firma tym problem głuchego telefonu jest większy.
0
Schadoow napisał(a):
@Riddle Ale to nie chodzi o faile w rozumieniu kodu. Tylko faile w rozumieniu procesu biznesowego. Których nie wykryjesz na poziomie implementacji bo muszą zostać przetestowane przez ekspertów dziedzinowych. Tu chodzi o błędy w "zamówieniach". Czym większa firma tym problem głuchego telefonu jest większy.
No ale to nie test wpłynął na release, tylko ten ekspert dziedzinowy podjął decyzję że trzeba dodać poprawkę. Więc to jest okej.
Możesz mieć feedback loopy w których jakaś osoba podejmuje decyzję o nowych feature'ach - to jest zdrowe i w duchu MS. Bo ten feature też można dodać w jednym z MS, deploy'ując go niezależnie od innych mikroserwisów.
2
anonimowy napisał(a):
@Riddle przecież Netflix testuje więcej rzeczy niż jesteś w stanie sobie wyobrazić i zdecydowanie testują zależności pomiędzy mikroserwisami (wedlug ciebie to już nie mikroserwis) więc dlaczego ich wymieniasz?
Nie mówiąc o tym, że Netflix ma dedykowany zespół platformowy, który dostarcza standardowe szablony aplikacji, biblioteki, building blocki infrastruktury, konfigurację CI/CD, obrazy Dockera, manifesty K8S dla zespołów produktowych i zajmuje się utrzymaniem całej infrastruktury/platformy na której zespoły produktowe uruchamiają swoje mirkoserwisy dokładnie tak jak opisał to @some_ONE ale dla Riddle to tworzenie silosów, które jest złem. A prawda jest taka, że im większa firma i więcej rozproszonych zespołów tworzących mikroserwisy w autonomii, tym bardziej taki zespół jest potrzebny by trzymać standardy.
0
Dobrze, już myślę że się kręcimy w kółko więc jak kończę temat z mojej strony. To co chciałem napisać, w skrócie, to to że:
- Główną cechą mikroserwisów jest to, że można je wdrażać niezależnie od siebie. Jeśli tego nie masz, to to nie jest mikroserwis.
Wielu ludzi lubi myśleć że "po prostu" jak masz kontenery które gadają po HTTP, to to są mikroserwisy, ale niestety nie są.
Dziękuję, pozdrawiam.
0
Ja też zakończę w takim razie:
To, że ktoś zdroworozsądkowo stwierdzi, że nie wdraża mikroserwisu bo coś wybuchło i aplikacja w całości nie działała by poprawnie nie oznacza, że to nie jest mikroserwis
0
anonimowy napisał(a):
Ja też zakończę w takim razie:
To, że ktoś zdroworozsądkowo stwierdzi, że nie wdraża mikroserwisu bo coś wybuchło i aplikacja w całości nie działała by poprawnie nie oznacza, że to nie jest mikroserwis
To że wdrożyłeś mikroserwis i coś wybuchło, znaczy że to nigdy nie był mikroserwisem, skoro było w stanie wybuchnąć aplikację.
0
To znaczy, że Twoim zdaniem mikroserwis to jest po prostu serwis. Mikroserwisy mają to do siebie, że działają między sobą. Np. na allegro jak mikroserwis płatności wybuchnie to też rozwala aplikację bo nie działa kluczowy element (to, że nadal wyszukanie działa nie zmienia faktu, że lepiej żeby płatności działały i nazywam to wybuchem). Tak samo mikroserwis płatności wpływa na inne bo z niego korzystają np. mikroserwis zamówień korzysta z mikroserwisu płatności. Jeśli testuję, że mikroserwis zamówień źle korzysta z mikroserwisu płatności przez pomyłkę i postanawiam tego nie wdrażać bo appka nie działałaby poprawnie to znaczy, że to już nie jest mikroserwis.
Podsumowując mikroserwisy nie istnieją bo są nimi tylko monolity a jednocześnie monolit nie jest mikroserwisem
0
anonimowy napisał(a):
Mikroserwisy mają to do siebie, że działają między sobą.
No tak, oczywiście.
anonimowy napisał(a):
Np. na allegro jak mikroserwis płatności wybuchnie to też rozwala aplikację bo nie działa kluczowy element (to, że nadal wyszukanie działa nie zmienia faktu, że lepiej żeby płatności działały i nazywam to wybuchem). Tak samo mikroserwis płatności wpływa na inne bo z niego korzystają np. mikroserwis zamówień korzysta z mikroserwisu płatności.
Jeśli masz allegro, który składa się z mikroserwisów, powiedzmy: szukajka, zamówienia, i płatność - i programista mikroserwisu płatności stwierdzi "aa, usunę sobie możliwość płacenia", i robi deploy - to on może to zrobić. I jeśli chcemy to wykryć, to powinny to wykryć testy tylko i wyłącznie mikroserwisu płatności i nic więcej. Jeśli testy mikroserwisu płatności przechodzą, to znaczy że jest gotowy do deploya, i koniec. Jest wdrożone, i po zawodach - żaden inny mikroserwis, i nic dookoła nie może powiedzieć "hola, hola, serwis płatności nie robi płatności". Dlatego że to podczas release'u MSa płatności trzeba ustalić czy taka zmiana się nadaje do release'u czy nie.
Jeśli chcesz się upewnić na 1000% że płatności działają (i mieć mikroserwisy), to musisz to sprawdzić testami tylko serwisu do płatności - i to musi wystarczyć.
Jeśli chcesz mieć pewność, że serwis zamówień "rozmawia dobrze" z serwisem płatności, to nie możesz ich przetestować razem (bo wtedy nie byłyby mikroserwisami). Musisz to przetestować, w taki sposób że testy zamówienia sprawdzają czy zamówienie wychodzi dobrze przez interfejs serwisu zamówień, oraz w testach płatności, czy płatności dobrze wchodzą przez interfejs płatności. Wymaga to bardzo dobrze zaprojektowanych interfejsów, co jest kolejnym powodem czemu od takiej architektury nie powinno się zaczynać. Tak się to powinno przetestować.
Jeśli masz mikroserwisy, takie jak opisałem - że zamówienia i płatności, i testujesz tylko je z osobna, i polegasz na stabilnych interfejsach do działania; i wtedy napiszesz sobie chociaż jeden test który sprawdza je razem, i na tej podstawie możesz cofnąć/wymusić zmianę w jednym z nich, to w tym momencie one stają się zależne od siebie, i ergo nie są mikroserwsami.
Wielu ludzi może dojść do wniosku że to albo jest bardzo nieodpowiedzialne, albo bardzo trudne do utrzymania, albo bardzo niewydajne - i tak jest w istocie. Mikroserwisy dokładnie takie są, dlatego mają sens tylko w bardzo dużych projektach, w których możemy wymienić spójność w zamian za niezależność.
Dlatego większość projektów tak na prawdę nie ma mikroserwisów, bo nie robi tych rzeczy które opisałem. Większość ludzi ma rozdystrybuowany monolity, tylko lubi go sobie nazwać "mikroserwis" bo to modne słowo i hype.
Jeśli masz kilka kontenerów które gadają po HTTP: i masz potrzebę przetestować je razem, bo testowanie ich osobno nie daje gwarancji że wszystko działa - to siłą rzeczy to nie mają prawa to być mikroserwisy. Żeby coś można było nazwać mikroserwisem, to musi się dać móc ustalić jego release'owalność w odosobnieniu - tak żeby był niezależny od innych.
anonimowy napisał(a):
Jeśli testuję, że mikroserwis zamówień źle korzysta z mikroserwisu płatności przez pomyłkę i postanawiam tego nie wdrażać bo appka nie działałaby poprawnie to znaczy, że to już nie jest mikroserwis.
Rozumiem że "źle korzysta", znaczy że gadają niepoprawnymi interfejsami? Bo mikroserwisy tworzy się w oparciu o stabilne interfejsy - więc dwa mikroserwisy muszą się zgodzić na ten interfejs. Jeśli jeden mikroserwis odstaje od interfejsu, to jego testy powinny to wykryć i nie powinien być wdrożony - ale to testy tego mikroserwisu mają to wykryć (samodzielnie), a nie testy w porozumieniu z innymi.
- Jeśli testy pojedynczego mikroserwisu są w stanie wykryć niezgodność z interfejsem - to może być mikroserwis
- Jesli testy pojedyczego mikroserwisu przechodzą, ale i tak mikroserwisy "źle ze sobą gadają" - to znaczy że mikroserwisy na siebie wpylnęły, ergo są zależne od siebie, ergo nie są mikroserwisami.(najpewniej dlatego że nie ma ustalonego odpowiedniego interfejsu między nimi, albo nie jest sprawdzany na poziomie pojedynczych MS).
To w takim razie jak sobie zrobić ten "stabilny interfejs"? Opisałem to tutaj: #1956027
4
Jesteś w stanie rozwijać mikroserwis niezależnie. To, że masz dodatkowy test jako dodatkowy bezpiecznik i pewność, że wszystko hula nie znaczy, że to nie jest mikroserwis. To Ty to sobie wymyśliłeś. Skasowanie testów nie powoduje, że coś nagle staje się mikroserwisem a wcześniej nie było. To jest absurd
0
anonimowy napisał(a):
Jesteś w stanie rozwijać mikroserwis niezależnie. To, że masz dodatkowy test jako dodatkowy bezpiecznik i pewność, że wszystko hula nie znaczy, że to nie jest mikroserwis. To Ty to sobie wymyśliłeś.
Popatrz na to od odwrotnej strony, wyobraź sobie sytuację w której nie masz testów między mikroserwisami żadnych. Możesz je release'ować całkowicie niezależnie.
I teraz piszesz test na oba z nich. Samo to jeszcze ich nie dyskwalifikuje. Ale potem dochodzi sytuacje, w której chcesz dodać zmianę w jednym z mikroserwisów. Dodajesz ją, jego testy przechodzą, chcesz wrzucić te zmiany; i ten jeden test odpalony na obu failuje. Co robisz? Cofasz zmianę? Bo jeśli tak, to właśnie uzależniłeś mikroserwisy od siebie. Ergo, od tej chwili nie są już niezależnie deployowalne. Ergo nie są mikroserwisami już.
Wszystko się sprowadza do pytania: Jak dbasz o to by całość aplikacji działała?
- Testujesz ją całą? ergo masz rozdystrybuowany monolit
- Testujesz każdy serwis z osobna i polegasz na stabilnych interfejsach? ergo masz mikroserwisy.
anonimowy napisał(a):
Skasowanie testów nie powoduje, że coś nagle staje się mikroserwisem a wcześniej nie było. To jest absurd
To co na prawdę sprawia że coś "nagle staje się mikroserwisem", to wtedy kiedy usunie się wszystkie zależności deploya między nimi, czyli również testy między nimi. Powinny zostać tylko interfejsy, oraz testy poszczególnych mikroserwisów.
0
Riddle napisał(a):
ten jeden test odpalony na obu failuje. Co robisz? Cofasz zmianę? Bo jeśli tak, to właśnie uzależniłeś mikroserwisy od siebie
To ty popatrz na to z innej strony:
1 Masz takie testy
2. Jeden test failuje
3. Nie cofasz zmian bo jeśli cofniesz to to nie będą mikroserwisy.
4. Twoja firma traci milion złotych przez ten błąd
A ja:
- Mam takie testy
- Jeden test failuje
- Stwierdzam, że cofnę te zmiany i naprawię błąd w mikroserwisie bo wykrył mi to test spoza tego mikroserwisu
- Moja firma nie traci miliona złotych a ja nadal mam mikroserwisy mimo, że podjąłem decyzję, że nie robię release bo jest jakiś błąd, którego nie wykryły mi testy z tego mikroserwisu a zewnętrzne testy
0
anonimowy napisał(a):
To ty popatrz na to z innej strony:
1 Masz takie testy
2. Jeden test failuje
3. Nie cofasz zmian bo jeśli cofniesz to to nie będą mikroserwisy.
4. Twoja firma traci milion złotych przez ten błąd
Jak masz mikroserwisy to są inne zabezpieczenia przed tym jak zapewnić poprawne działanie aplikacji. Rozumiem że w Twojej głowie "brak testu między serwisami" == "brak zabezpieczeń przed bugami", a tak nie jest.
Da się zapewnić na 100% do bardzo wysokiego stopnia pewności to że mikroserwisy działają poprawnie nie testując ich razem. To jest ich cały sens, na tym polega cała ich "siła".
anonimowy napisał(a):
A ja:
- Mam takie testy
- Jeden test failuje
- Stwierdzam, że cofnę te zmiany i naprawię błąd w mikroserwisie bo wykrył mi to test spoza tego mikroserwisu
- Moja firma nie traci miliona złotych a ja nadal mam mikroserwisy mimo, że podjąłem decyzję, że nie robię release bo jest jakiś błąd, którego nie wykryły mi testy z tego mikroserwisu a zewnętrzne testy
No okej, możesz tak mieć. Ale to co opisałeś to nie są mikroserwisy. To jest rozdystrybuowany monolit.
0
Riddle napisał(a):
anonimowy napisał(a):
To ty popatrz na to z innej strony:
1 Masz takie testy
2. Jeden test failuje
3. Nie cofasz zmian bo jeśli cofniesz to to nie będą mikroserwisy.
4. Twoja firma traci milion złotych przez ten błądJak masz mikroserwisy to są inne zabezpieczenia przed tym jak zapewnić poprawne działanie aplikacji. Rozumiem że w Twojej głowie "brak testu między serwisami" == "brak zabezpieczeń przed bugami", a tak nie jest.
Da się zapewnić na 100% to że mikroserwisy działają poprawnie nie testując ich razem. To jest ich cały sens, na tym polega cała ich "siła".
Nie da się na 100% zapewnić skoro nawet procesory mają błędy. Systemy bankowe mają błędy. W zasadzie każdy typ aplikacji miał jakieś krytyczne błędy.
Były przypadki, że ludzie ginęli i tracili fortuny a przyjdzie taki łepek i powie, że da się na 100% zapewnić brak błędów ha tfu na Ciebie bo jak możesz pisać takie rzeczy podczas gdy może to czytać osoba, która straciła bliską osobę na skutek błędu oprogramowania
1
@Riddle Co oznacza dla ciebie poleganie na stabilnych interfejsach ?
Jak dostajesz dokumentacje podpisaną krwią to interfejs jest stabilny ? Czy druga strona musi stać i być działająca ?
1
Dlaczego testowanie całości rozbitej na mikroserwisy jest uznawane za monolit? Skoro całokształt jest tworzony z poszczególnych mikroserwisów to oczywistym jest, że istnieją zależności - W końcu jest to produkt. Nie wyklucz to również oddzielnego deployowania i "niezależności", bo i tak każdy z tych serwisów wykonuje konkretne zadanie.
#1 zapisuje dane na bloba
#2 zczytuje dane z bloba i wrzuca na kafke
#3 zassysa kafke i robi coś innego
Wszystkie są same w sobie niezależne, ale razem tworzą proces. Dla mnie to trochę pokrętna logika, żeby nie testować całości, bo "wtedy to nie mikroserwisy". Mam wrażenie, że nie próbujemy tutaj wymyślać jakieś nowe terminy i zwyczajnie komplikować proste założenia.
Pomijam już fakt, że istnieją zależności zewnętrzne, kompletnie nie związane z samym "mikroserwisem". Chociażby timeouty w powyższym procesie.
0
Ale ja wam nie mówię że macie nie testować waszych apek razem, jak chcecie to testujcie e2e nawet całe.
Ale jeśli macie takie testy, to to co macie to po prostu nie jest mikroserwis i tyle. Więc nie wprowadzajcie ludzi w błąd tym określeniem.
0
Wpisz "microservice" w google, pierwszy link: https://microservices.io/, weź poczytaj, zwłaszcza sekcję "Independently deployable".
0
W pełni się zgadzam, mało który projekt jest mikroserwisem a blokowanie deploymentu dyskwalifikuje to jako mikroserwis, bo co z tego że mam inne języki, inne bazy skoro i tak muszę relesowac całość, to samo mogę zrobić w monolicie, różne niezależne moduły, które mają własne bazy danych, na różnych silnikach nad którymi pracują niezależne zespoly,.. Także większość projektów to mikroserwisowe monolity, nie potrzebie skomplikowane nakładem pracy przy wdrożeniu i komunikacji
If you need to test your service with other services in order to verify that it’s production ready then it is not independently deployable. Moreover, you might want to consider putting those services in a single repository. It ensures that the output of your single deployment pipeline is actually production ready. It will also eliminate the complexity of developing across multiple repositories.
5
@Blackcat Powodzenia w monolicie gdzie pracuje >50-100FTE
Poza tym nikt nie mowi o releasowaniu całości. Tylko przetestowaniu całości przed wypuszczeniem zmiany. Drobna różnica.
Nawet netflix ma stage environments. Ba nawet mają swoje biblioteki do robienia testów e2e przed releasem.
Zresztą co będę tutaj wymyślał. Tak wygląda proces netflixa:
Punkt 4 zaprzecza @Riddle definicji microserwisów a więc ergo według tej definicji nawet netflix nie ma MS.
0
markone_dev napisał(a):
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".
Na takie coś pomaga podział na zespoły i code review. Ludzie od bibliotek nie mogą być ludźmi od biznesu.
yarel napisał(a):
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)
To pierwsze to jest build, nie release. Release i deploy to to samo w omawianym kontekście.
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
Tylko po co robić taką zależność? Po co odpalać jakieś dodatkowe deploymenty zależności?
To trochę brzmi jakbym zamiast używać paczek z menadżera pakietów za każdym razem musiał budować wszystkie zależności mojej aplikacji na swoim komputerze. Co najmniej dziwne.
1
Dużo ludzi wierzy w hype i w moc "wpisania sobie do CV", dlatego wierzy że mikroserwisy to samo dobro - które jest łatwe, super, mega, 10/10, i działa dla małych, dużych i średnich projektów.
Tymczasem w rzeczywistości mikroserwisy to bardzo trudna architektura, której wprowadzenie wymaga dużo skilla, dużo czasu, i bardzo łatwo jest przez pomyłkę zostać z jeszcze większym spaghetti który mieliśmy. Niestety nie zawsze hype odpowiada rzeczywistości 
Przez to jest praktycznie tylko dobre do bardzo dużych projektów, gdzie możemy sobie pozwolić na wkładanie man-hours po to żeby projekt mógł być rozwijany przez niezależne zespoły. Ale jesli tego nie potrzebujemy, to to jest czas i energia wyrzucone w błoto, w rozwiązywanie niepotrzebnych problemów i rzucanie sobie kłód pod nogi.
Dodatkowo - większość ludzi która się zabiera za mikroserwisy robi to głównie po to żeby osiągnąć modularność (mają przekonanie, że jeśli dwa serwisy są osobnymi procesami, to nie bedzie się dało zrobić spaghetti). Smutną ironią jest to że po pierwsze modularność można osiągnąć dużo prościej i lepiej (jak się ma trochę skilla w designowaniu projektów), a sięgając po mikroserwisy przenoszą swój brak skilla w designowaniu modułów - na brak skilla w designowaniu serwisów; przez co serwisy które w ten sposób powstają mają te same wady i problemy które miałyby ich moduły - tylko że teraz ma jeszcze dodatkową complexity wyniakającą z dockerów, deployów, sieci, etc.
Jeśli nie umiesz zrobić dobrych modułów w pojedynczej aplikacji, to na pewno też nie uda Ci się zrobić dobrych serwisów, bo to jest praktycznie ten sam skill.
0
@Riddle ale przecież udowodniliśmy Ci, że mikroserwisy nie istnieją a tym bardziej w bardzo dużych projektach.
1
To pierwsze to jest build, nie release. Release i deploy to to samo w omawianym kontekście.
Pewnie zależy od kontekstu ;-) Dla mnie kontekstem są: (mikro)serwisy + CI/CD + ciągły deployment (i tu nie wyobrażam sobie braku testów). Tu pojawia się aż 4 terminy, w tym 2 razy CD, więc jest pole do interpretacji, np. traktowania CD(elivery) i CD(eployment) jako tego samego. Dlaczego łączę to z (mikro)serwisami)? Bo bez CI/CDD to może być trudne w realizacji.
Build, release i deploy to są różne rzeczy. Tak, tak samo jako jabłko, słoik z podsmażonym jabłkiem i szarlotka. Nie każde jabłko nadaje się do podsmażenia (choć to pewnie kwestia indywidualna ;-) )
Podobnie, nie każdy słoik z jabłkiem nadaje się do produkcyjnego użycia (np. nie sprawdziliśmy szczelności słoika; ponownie kwestia indywidualna). Szarlotka ze sfermentowanym jabłkiem pewnie znajdzie swoich amatorów. Podobnie jak sfermentowane ryby, czy piwo z mewy.
Tylko po co robić taką zależność? Po co odpalać jakieś dodatkowe deploymenty zależności?
Ile kosztuje wypuszczenie komponentu, który wywali produkcję? $$$, reputacji, czasu, zdrowia. Skoro można zmniejszyć ryzyko takich kosztów, przez użycie automatów, to dlaczego tego nie robić?
W imię nazewnictwa?
To trochę brzmi jakbym zamiast używać paczek z menadżera pakietów za każdym razem musiał budować wszystkie zależności mojej aplikacji na swoim komputerze. Co najmniej dziwne.
Tak, early feedback może wydawać się dziwny (po co mi ktoś ma mówić, że jest problem, może jeszcze trzeba będzie go rozwiązać i jeszcze w (mikro)serwisie ;-) ).
W ogólności możesz mieć takie zależności (ale nie musisz, może inna branża, specyfika działalności):
serwisy <- produkty (oparte o architekturę (mikro)serwisów ) <- klienci -> serwisy/produkty 3pp
Jako autor serwisu nie masz kontroli nad strategią wdrażania produktów u klientów, ani tego jak jest używany. Co możesz zrobić to:
a) powiadomić "hej jest nowa wersja" (np. z joba na Gitlaba/Jenkinsa wołasz np. Spinnakera, który wie kogo zawołać dla danej zmiany i wie komu przekazać feedback o nowej wersji) albo nie powiadamiać
b) obsłużyć feedback "wywaliło sia na tej nowej wersji" albo ignorować ten feedback
c) dostarczyć
Nie twierdzę, że istnieje jedyna słuszna dla wszystkich strategia, a jedynie oceniam jako nonsens nazywanie czegoś mikroserwisem, bądź nie (w zależności od przyjętej strategii dostarczania zmian na produkcję). Rozumiem też podejście typu "nic mnie nie obchodzi, żyję w swoim silosie i jest mi z tym dobrze".
Po podliczeniu zysków i strat z tej dyskusji, uruchamiam stop-lossa. Chyba, że ktoś chce się podzielić swoimi doświadczeniami na temat CI/CDD w połączeniu z (mikro)serwisami. Chętnie poczytam o problemach, kontekście i rozwiązaniach. 
0
yarel napisał(a):
Pewnie zależy od kontekstu ;-) Dla mnie kontekstem są: (mikro)serwisy + CI/CD + ciągły deployment (i tu nie wyobrażam sobie braku testów). Tu pojawia się aż 4 terminy, w tym 2 razy CD, więc jest pole do interpretacji, np. traktowania CD(elivery) i CD(eployment) jako tego samego. Dlaczego łączę to z (mikro)serwisami)? Bo bez CI/CDD to może być trudne w realizacji.
Nadal Ci ucieka znaczenie terminu "mikroserwis". Wygląda to tak, jakby dla Ciebie jedyny sposób żeby zapewnić odpowiednie działanie serwisu to jest przetestować go w całości. I to z punktu widzenia CI/CD jest poprawne. Tylko że to o czym mówisz to nie jest mikroserwis :D W najlepszym wypadku to jest rozdystrybuowany monolit - a jeśli nazwa "monolit" Ci nie pasuje, to można to nazwać "service-oriented architecture", czyli że masz serwisy które ze sobą gadają i jest testujesz razem.
Ale "service-oriented architecture" to nie to samo co mikroserwis. Mikroserwisy buduje się tak, żeby dało się je rozwijać i testować osobno (i nie rozwijało i nie testowało razem). Więc czy da się budować mikroserwisy z Ci/CD? Owszem - tak długo jak Twój proces CI/CD dotyczy tylko jednego MS (a nie wszystkich razem). Zapytasz więc - to przecież bez testów to się rozwali. I odpowiedź na to jest dwojaka: rozwali się jeśli masz rozdystrybuowany monolit (lub "service-oriented architecture", jak wolisz), bo wtedy zmiany mogą wpłynąć na siebie nawzajem, i musisz mieć testy żeby się przed tym zabezpieczyć. Ale jeśli masz mikroserwisy (czyli aplikacje które są niezależnie deployowalne), to zmiany w nich nie wpływają na siebie nawzajem - dlatego że są zbudowane tak, żeby zmiany między nimi na siebie nie wpływały - więc nie trzeba ich testować (a nawet nie można, bo to nałożyłoby coupling na nie).
Wygląda to tak jakby koncept "aplikacji które są niezależne od siebie" Ci się nie mieścił w głowie, i jakbyś cały czas miał przekonanie że one muszą na siebie wpływać, a skoro tak to mogą się nawzajem zepsuć, a skoro tak to trzeba je przetestować razem. No i jeśli wyjdziesz z założenia że "nie da się zrobić niezależnych aplikacji", to faktycznie musisz dojść do wniosku że "trzeba je przetestować razem".
Odpowiedź jest prosta: jeśli ograniczysz coupling między serwisami do minimum, MS będą dopasowane do bounded contextu, będą miały stabilne interfejsy (wykreowane wieloma iteracjami), i wszystkie zmiany będą kompatybilne wstecz względem interfejsu; to te dwa serwisy mają bardzo nikłą szansę na siebie wpłynąć, wręcz żadną. A skoro tak, to można o dwóch mikroserwisach myśleć jak o osobnych aplikacjach, a skoro tak to nie trzeba ich testować razem, bo szansa na to że jedna zepsuje drugą mała, wręcz taka że nie trzeba się tym martwić. I to można nazwać mianem "mikroserwis". Jeśli nie spełniasz tych kryteriów, to niestety ale Twój projekt to nie są MS
0
@Riddle: Przykład z życia wzięty. Jest sobie ogromna firma spedycyjna, która posiada na oko z 50 aplikacji: śledzenie paczek, zbieranie informacji o przewoźnikach, widok na centra dystrybucyjne, dane ciężarówek, i tak dalej. Każda z takich aplikacji jest osobnym mikroserwisem, ponieważ ze sobą nie rozmawiają. Pracuję przy jednej z nich, nie mam pojęcia co dzieje się w innych, i nie bardzo mnie o to obchodzi, bo ich procesy na mnie nie wpływają.
Wszystkie jednak mają wspólną rzecz: są dostępne jako pojedyńcze kafelki w głównym widoku - żeby użytkownik musiał zarejestrować się raz, a nie 50. Wchodząc do mojej aplikacji, dostaję informację, z nazwijmy go, user-service, który dostarcza mi informację o użytkowniku: jego id (w tamtym systemie, nie moim!), imię i nazwisko, preferowany język i tak dalej.
User-service postanawia wprowadzić GDPR, i przestaje w tokenie wrzucać informacje powszechnie uznawane jako wrażliwe, zmienia kontrakt jaki dotychczas mieliśmy.
Czy moja aplikacja przestaje być mikroserwisem?
1
dargenn napisał(a):
@Riddle: Przykład z życia wzięty. Jest sobie ogromna firma spedycyjna, która posiada na oko z 50 aplikacji: śledzenie paczek, zbieranie informacji o przewoźnikach, widok na centra dystrybucyjne, dane ciężarówek, i tak dalej. Każda z takich aplikacji jest osobnym mikroserwisem, ponieważ ze sobą nie rozmawiają. Pracuję przy jednej z nich, nie mam pojęcia co dzieje się w innych, i nie bardzo mnie o to obchodzi, bo ich procesy na mnie nie wpływają.
Wszystkie jednak mają wspólną rzecz: są dostępne jako pojedyńcze kafelki w głównym widoku - żeby użytkownik musiał zarejestrować się raz, a nie 50. Wchodząc do mojej aplikacji, dostaję informację, z nazwijmy go, user-service, który dostarcza mi informację o użytkowniku: jego id (w tamtym systemie, nie moim!), imię i nazwisko, preferowany język i tak dalej.
User-service postanawia wprowadzić GDPR, i przestaje w tokenie wrzucać informacje powszechnie uznawane jako wrażliwe, zmienia kontrakt jaki dotychczas mieliśmy.
Czy moja aplikacja przestaje być mikroserwisem?
Jeśli zmiana interfejsu zostanie wprowadzona w sposób kompatybilny wstecz, to nie przesatnie, dlatego że mikroserwis może być zależny od interfejsu. Aczkolwiek zmianę tego interfejsu trzeba wprowadzić w kodzie tak, żeby nie wpyłnęła na inne serwisy - bo jeśli po prostu sobie zrobisz od tak deploy Twojego serwisu, to on zepsuje inne - i wtedy faktycznie można powiedzieć że nie jest to MS. Należy wprowadzić go w sposób kompatybilny wstecz, np zacząć wspierać dwa interfejsy, i poczekać aż inne mikroserwisy przestaną korzystać ze starego - wtedy można usunąć ten stary interfejs. Można to zrobić albo wersjonowaniem i strzelaniem pod inne path, albo dodawaniem nowych opcjonalnych pól (żeby po czasie przerobić je na wymagane, jeśli wszystkie serwisy się dostosują).
Mogłoby to wyglądać tak:
- Serwis A korzysta z interfejsu v1, oraz Serwis B korzysta z interfejsu v1.
- Jeden z serwisów wprowadza drugi interfejs v2, który spełnia wymagania GDPR. Nadal akceptuje pełnoprawnie v1.
- W pewnym momencie drugi serwis zmienia interfejs z v1 na v2 - również musi to zrobić w taki sposób żeby było to kompatybilne wstecz i nic nie zepsuło. Od tego momentu oba gadają w v2.
- Oba serwisy mogą usunąć interfejs v1.
Na żadnym kroku nie można przetestować obu mikroserwisów razem, bo to doda zależności między nimi. Jedyne co można zrobić, to przetestować zgodność pojedynczych serwisów ze spodziewanym interfejsem.
Czy może zajść sytuacja w której jakiś mikroserwis nigdy nie zacznie wspierać v2? Oczywiście. Co wtedy? Nic, musisz wspierać oba interfejsy w nieskończoność. No to jak to tak, mam mieć zduplikowany kod? Niestety tak - mikroserwisy to jest trade pomiędzy kosztem utrzymania a niezależnością.
Jeśli te kryteria nie są spełnione, to nasza architektura to nie jest mikroserwisy, tylko jak mówiłem: rozdystrybuowany monolit.
Z uwagi na powyższe: nie polecami mikroserwisów nikomu kto ma mały lub średni projekt - takie coś zaczyna być opłacalne na prawdę dopiero przy gigant-projektach.
PS: Jest to trochę podobne do sytuacji w której Android może wypuszczać nowe wersje, i nie musi się testować z aplikacjami ze sklepu play - musi tylko przetestować czy interfejs jest zgodny - i zakłada że jeśli interfejs jest zgodny, to apki będą po prostu działać (system => apka). Tylko z mikroserwisami to jest dodatkowo zrobione w dwie strony (a <=> b). To byłaby sytuacja jakby apek na android się nie testowało na emulatorze w danej wersji, tylko sprawdzało sam interfejs.
PS2: Czyli w skrócie, jeszcze innym określeniem MS może być: "Mikroserwisy nie będą nigdy w stanie zrobić czegoś, czego nie wspiera interfejs" (czyli inaczej niż w wypadku rozdystrybuowanego monolitu, gdzie jak chcesz zrobić coś czego nie wspiera interfejs, to po prostu go zmieniasz, potencjalnie coś psując, więc musisz testować wszystko razem).