Jak chodzi o zmianę podziału, to zgodzę się jeżeli chodzi o nakład pracy większy w przypadku mikroserwisów, ale taka zmiana jest często łatwiejsza na nich jeżeli projekt pracuje już na produkcji. Fakt dobrze poruszony jest wątek, że trzeba przez jakiś czas używać dwóch rozwiązań w tym samym czasie użyć feature toggle, do przełączania. Ale realnie tak duże zmiany na produkcji są ciężkie i ryzykowne w monolicie, i może się zdarzyć że testy e2e nie zabezpieczały pewnych skrajnych scenariuszy i walnie. W przypadku mikroserwisów i użyciu feature toogle, włączamy sypie się powrót. Tak samo jak detekcja danych, możemy na środowiskach testowych upewnić się że działa logując zwrotki z obu mikroserwisów, i mieć pewność że wszystko działa prawidłowo. Z moich doświadczeń, to akurat najmniej ważne funkcjonalności najbardziej chce biznes. Co do tego co bym dodał do Waszych podcastów to byłoby podsumowanie. Taki skrót wszystkich omówionych tematów dla utrwalenia.
Dzięki za komentarz :) Odnośnie zmian na monolicie i feature toggli, to bardzo słuszna uwaga! Zwłaszcza jeśli mamy do czynienia z tymi "złymi" monolitami, czyli po prostu z kulą błota. I o ile wprowadzanie takich zmian w monolicie faktycznie jest trudne o tyle rozwiązanie które podałeś tam również się aplikuje. Jest to "Strangler Pattern", gdzie "chowasz" logikę pod odpowiednią fasadą i pod spodem utrzymujesz zarówno starą i nową implementację. Ma to ten plus, że możesz porównywać zarówno nowe jak i stare rozwiązanie (porównanie w ramach jednej instancji jest łatwiejsze niż po sieci). Mając oba możesz decydować czy działa nowe, a stare tylko nasłuchuje i porównuje, czy już nowe, a stare dalej chodzi jako ewentualny bezpiecznik, czy już w całości pozbywasz się "staroci". Tak w ogóle, to jest to jeden ze sposobów refaktoringu w kierunku modularyzacji. Co do drugiej kwestii, to również miałem podobne doświadczenia. I tu nauczyłem się od Kuby Nabrdalika, żeby zmienić podejście w rozmowie z biznesem. Ale to zdecydowanie temat na cały odcinek a nie jeden komentarz. Dzięki też za sugestie z tymi skrótami. W kolejnych odcinkach próbowaliśmy robić takie podsumowania, ale faktycznie mogło to być za krótkie.
![Dzielenie aplikacji na moduły [D&D #2]](http://i.ytimg.com/vi/dfzGDdDgn5g/mqdefault.jpg)
![Dzielenie aplikacji na moduły [D&D #2]](/img/tr.png)
Genialny podcast. ❤
Zapraszamy do kolejnych odcinków ;)
Jak chodzi o zmianę podziału, to zgodzę się jeżeli chodzi o nakład pracy większy w przypadku mikroserwisów, ale taka zmiana jest często łatwiejsza na nich jeżeli projekt pracuje już na produkcji.
Fakt dobrze poruszony jest wątek, że trzeba przez jakiś czas używać dwóch rozwiązań w tym samym czasie użyć feature toggle, do przełączania. Ale realnie tak duże zmiany na produkcji są ciężkie i ryzykowne w monolicie, i może się zdarzyć że testy e2e nie zabezpieczały pewnych skrajnych scenariuszy i walnie. W przypadku mikroserwisów i użyciu feature toogle, włączamy sypie się powrót. Tak samo jak detekcja danych, możemy na środowiskach testowych upewnić się że działa logując zwrotki z obu mikroserwisów, i mieć pewność że wszystko działa prawidłowo.
Z moich doświadczeń, to akurat najmniej ważne funkcjonalności najbardziej chce biznes.
Co do tego co bym dodał do Waszych podcastów to byłoby podsumowanie. Taki skrót wszystkich omówionych tematów dla utrwalenia.
Dzięki za komentarz :)
Odnośnie zmian na monolicie i feature toggli, to bardzo słuszna uwaga! Zwłaszcza jeśli mamy do czynienia z tymi "złymi" monolitami, czyli po prostu z kulą błota.
I o ile wprowadzanie takich zmian w monolicie faktycznie jest trudne o tyle rozwiązanie które podałeś tam również się aplikuje. Jest to "Strangler Pattern", gdzie "chowasz" logikę pod odpowiednią fasadą i pod spodem utrzymujesz zarówno starą i nową implementację. Ma to ten plus, że możesz porównywać zarówno nowe jak i stare rozwiązanie (porównanie w ramach jednej instancji jest łatwiejsze niż po sieci). Mając oba możesz decydować czy działa nowe, a stare tylko nasłuchuje i porównuje, czy już nowe, a stare dalej chodzi jako ewentualny bezpiecznik, czy już w całości pozbywasz się "staroci". Tak w ogóle, to jest to jeden ze sposobów refaktoringu w kierunku modularyzacji.
Co do drugiej kwestii, to również miałem podobne doświadczenia. I tu nauczyłem się od Kuby Nabrdalika, żeby zmienić podejście w rozmowie z biznesem. Ale to zdecydowanie temat na cały odcinek a nie jeden komentarz.
Dzięki też za sugestie z tymi skrótami. W kolejnych odcinkach próbowaliśmy robić takie podsumowania, ale faktycznie mogło to być za krótkie.