- mamy serwisy zombi które generują koszty
Nikt Ci nie każde mieć serwisów zombie - nie chcesz, to je wyłącasz. A ponieważ to jest mikroserwis, to żaden inny serwis od niego nie zależy, więc możesz bez problemu go położyc.
- mamy serwisy które pchają w ciul alertów, że nie mogą dobić się do jakiegoś serwisu
Nic w architekturze MS nie mówi o żadnych alertach. Jeśli sobie je dodałeś (Albo ktoś inny je dodał), to możesz albo je wyłączyć, albo zignorować, albo napisać swoje MS tak żeby nie rzucały tych alertów jak się nie mogą gdzieś dobić.
Cokolwiek co Ci przeszkadza w alertach - sam sobie to dodałeś, bo nic w MS nie mówi że alerty mają być gdziekolwiek.
- mamy ogromne opóźnienia bo zamiast walidować zwinnie tematy biznesowe (i chociażby czy o niczym nie zapomnieliśmy) to dowiadujemy sie dopiero przy pierwszym pełnym uruchomieniu procesu na produkcji
- i najważniejsze pierwsza walidacja systemu jest na produkcji.
Widzisz, że zrobiłeś z tego waterfalla ?
To pozwól że podsumuję:
- Ja mówię, że żeby coś było mikroserwisem, to musi być niezależnie deployowalne, więc zmiany należy wprowadzić niezależnie od siebie, jak tylko będą gotowe (co znaczy że część zmian może wejść dzisiaj, część później, a część za miesiąc). Więc znaczy to, że faktycznie ten "cały proces" o którym mówisz można go doświadczyć dopiero jak ostatni element będzie skończony - no jakby siłą rzeczy, ale część procesu można już sprawdzać od razu jak tylko się pojawi, czyli np po kilku dniach, bez czekania na ostatni element układanki.
- Ty mówisz, że można to wdrożyć dopiero jak wszystkie będą gotowe i będzie można je przetestować razem, dobrze rozumiem? Czyli rozumiem że jak ostatni element będzie gotowy dopiero za miesiąc, to za miesiąc go wdrażamy, tak?
I mówisz że to podejście które opisałem z mikroserwisami jest waterfallem i nie agile?
Ja osobiście jakbym miał rozdzielać zadania i tworzyć wymagania pod taki system to bym sie mega bał wdrażać coś nowego.
Czy się bać czy nie - ja bym się nie bał, dlatego że każdy z tych mikroserwisów jest zbudowany tak, żeby był niezależy od innych. Więc zmiana w jednym, nie zepsuje niczego w innym. Co do wymagań biznesowych - mikroserwisy powinny być dopasowane do bounded contextu, więc większość z nich siedzi w ramach pojedynczego mikroserwisu. Rzadko się zdarza sytuacja że wymagania biznesowe rozpościerają się na kilka mikroserwisów, a na pewno nie na aż 5; dlatego napisałem w poście wyżej że to jest raczej hardcore'owy przypadek.
Przy czym myślę że ostatecznie mówimy o różnych rzeczach. Ja mówię o architekturze mikroserwisów, która ma pewną konkretną definicję - np to że mikroserwisy muszą być niezależnie deployowalne - i mówię jakie to ma konsekwencje (np to że nie można ich przetestować razem).
Ty mówisz, jak rozumiem, o czymś innym - mówisz o swoim projekcie, albo o swoich wyobrażeniach czym mikroserwis może być. Może masz wyobrażenie jak niektóre serwisy mogłyby wyglądać, i nie gra Ci to z tym o czym ja mówię.
Może myślisz o serwisach, które mają zależności (więc głupotą jest ich nie testować razem). Może myślisz o serwisach które nie pasują do bounded context (więc ciężko jest wprowadzić zmiany tylko w jednym z nich), możę myślisz o serwisie który ma niestabilne interfejsy (więc ciężko jest wprowadzić zmianę niezależnie od innych). Tylko że jeśli myślisz o takich projektach - to to nie są mikroserwisy.
A ten argument, że waterfall i agile - nadal do mnie nie trafia. Przecież z mikroserwisami możemy zebrać feedback jak to tylko możliwe. Jak tylko pierwszy z mikroserwisów jest skończony, to trafia na produkcję - wszyscy którzy tworzą pozostałe mikroserwisy to widzą. Od razu mają feedback. Potem drugi mikroserwis jest skończony, i też trafia na produkcję - i od momentu kiedy jest to gotowe, to jest deployowane. Więc feedback jest najszybciej jak się da.
Pisałeś że to co ja proponuję to jest waterfall, a tymczasem nie widzę czemu to miałby być waterfall, bo nie widzę żeby cokolwiek co ja proponuję powodowało jakiś zastój - upubliczniamy gotowe rozwiązania jak tylko są gotowe, tak szybko jak to możliwe. Owszem - "finalny" proces, o którym mówisz będzie dostepny dopiero jak ostatni element będzie skończony; ale przecież dokładnie to samo byś miał bezmikroserwisów - też widziałbyś finalny proces dopiero jak ostatni element będzie skończony.
MS mają być dopasowane do bounded context, czyli mikroserwis powinien pasować do jakiegoś rejonu domeny biznesowej (i zazwyczaj każdy MS ma osobny storage, jeśli masz na myśli takie coś jak postgres albo s3, chyba że masz na myśli coś innego pod słowem "storage", to wyjaśnij. Bardzo nieprecyzyjnie się wyrażasz, że nie wiem o co Ci chodzi w ogóle).