Smuci mnie jak wiele z tych antypaternów, o których wspominałeś występowało w mojej poprzedniej pracy... Ale cieszy mnie, że zmieniłem pracę na BEC. Liczę, że skoro zaprosili takiego prelegenta, to dbają o dobrą architekturę.
Skad najlepiej czerpac wiedze dotyczaca tych pul wątków (na request, bazy danych itp), zuzycia cpu itp? Od teorii po praktyke? Zeby moc sie tym pobawic w lokalnych warunkach.
Co masz konkretnei ma nysli? Teorię dotyczącą pól wątków? W zależności od technologii w któej pracujesz to w dokumentacji (trudna ściezka dla nowicjusza) lub różnego rodzaju kursach online (któe co prawda często są ogólne i prawie zawsze nei wyczerpują tematu ale dla nowicjusza to imho ok). Jeżeli chodzi o praktykę to, zakładając, że masz jakąś aplikację która działa i jest od nie jakich ruch, możesz ywykorzystać metryki (grafana, prometheus itp) gdzie możesz sobie wizualizować właśnie takie rzeczy jak utylizacja wątków itp.
Możliwe, że bazy danych są oparte o sequencery i w takim przypadku spójny backup danych jest niezbędny ponieważ istnieje ryzyko że dane pomiędzy serwisami się rozsynchronizuja i będą wskazywać na id, zupełnie innego rekordu niż pierwotnie. W takim scenariuszu to nie backup jest problemem tylko niepoprawnie zaprojektowane mikro serwisy/tabele bazodanowe. W sumie nie za często spotykam się z omawianiem tego problemu na prezentacjach, a źle zaprojektowana baza danych z mojego doświadczenia to największa kula u nogi projektu.
@@mrngwozdz Ciekawa uwaga. Ale się z nią nie zgadzam. Nie widziałem przypadku by ktoś wykonywał backup baz wszystkich mikroserwisów na raz i oczekiwał w tym backupie spójności. No bo niby czemu miałoby to służyć, skoro cały system i tak musi być zbudowany w oparciu o effectively-once delivery, oraz przywracanie danych każdego mikroserwisu jest kompletnie niezależne od pozostałych? Chyba nie mówimy o tym samym. Wspominasz o źle zaprojektowanej bazie jako problemie projektu, podczas każdy z mikroserwisów ma swoje własne bazy, enkapsuluje dane, ma swoje własne read-modele (zawsze nieaktualne), i idealnie powinien mieć w dupie co się dzieje w pozostałych mikroserwisach (resiliency). Pewnie łatwiej byłoby się dogadać jakbyśmy przyjeli jakieś założenia (np: event-driven na k8s z PostgreSQL, Redis lub MongoDB per serwis i Kafką z topic'ami z nieskończoną retencją gdzie pasuje + read modele w oparciu o compacted topics i Kafka Streams). Na przykład takie coś gitlab.com/jakubn/usage-analyzer/-/blob/main/README.md?ref_type=heads Możesz na tym przykładzie wytłumaczyć do czego miałby służyć "spójny backup danych"?
@@JakubNabrdalik Dzięki za odpowiedź. Zacznijmy od tego że rozmawiamy o problemie który faktycznie występuje w projektach, ale nie powinien istnieć w przypadku prawidłowo wykonanej architektury mikrousługowej. Spróbuję wyjaśnić prawdopodobny problem kolegi @mariuszgodziszewski8511 na przykładzie z życia, gdzie sam ostatnio miałem "przyjemność" pracować przy projekcie gdzie taki "spójny backup danych" występował. Projekt całkiem spory, wszystko na rhelu z openshiftem na pokładzie (Self-managed) i oczywiście mikrousługami. Problem pojawił się taki, że osoby które prowadziły ten projekt wcześniej pracowali na monolitach i wszystkie tabele w bazach danych były na sequencerach. Dane pomiędzy serwisami często były powiązane właśnie po nich co doprowadziło do sytuacji gdzie w jednym module, odpowiedzialnym za raporty coś się mocno podziało nie tak, na tyle że trzeba było przywracać bazę danych. Gdyby została przywrócona tylko baza danych w module raportującym, okazałoby się że serwis, który wiązał po id z raportami zacząłby dostawać nie swoje raporty (do czasu wyrównania sequencerów do stanu poprzedniego). I tak o to powstała potrzeba przywracania baz danych dla wszystkich mikrousług, bo jeden z serwisów miał problem. Pewnie dla Ciebie opisana sytuacja jest niedorzeczna bo jest to zwyczajnie kardynalny, podstawowy błąd. No ale cóż, tak to wygląda w wielu projektach szczególnie gdy ktoś przechodzi z pisania monolitów do mikrousług. Podsumowując "spójny backup danych" jest odpowiedzią na problem, który nie powinien istnieć przy dobrze zaprojektowanej architekturze, co zresztą udowadniasz dziwiąc się na tak zadane pytanie. Także @mariuszgodziszewski8511 - jeżeli doszło do sytuacji, że potrzebujecie takiej funkcjonalności to znaczy że coś mocno poszło nie tak.
2:31 os/360 IBM do 1979 roku większość projektów upadała więc matematycy (KNUTH) (kryzys programowania) zajęli się sprawą żeby uporządkować sprawy a inny wymyślili programowanie obiektowe w c++ (sorry C) 6:32 tak jak pisałem (ale cicho sza o kryzysie programowania) a teraz rozwiąniem ma być ML i w ogóle wszyscy na bruk... coś co nie potrafi między 2 a 4 zdaniem dostrzec sprzeczności z drugiej strony taki system jest chyba nie możliwy według niezupełności arytmetyki tw. Godla .. czyli niemożność zautomatyzowania matematyki .. ale lepiej nie mówić o tym co nie działa albo jest sprzeczne i trudne do odkręcenia grunt że nowe rzeczy powstają nowe typy procesorów PCM zamiast HBM może kiedyś memrystory ... nowy hype AGI za 3 lata.. a ja myślę że Winter is Comming Again AI Winter.. 14:14 to nic innego jak modele w logice i podejście no właśnie formalizacji do matematyki bazując na kryzysie po 1930 czyli tworzenie modeli.. meta meta meta ... model może zautomatyzować te meta.. no tak ML ... end
Smutne/zabawne jest to, że z tego powodu, że programiści nie potrafią się dogadać, tworzą skomplikowane (rozproszone) architektury, żeby uniknąć bólu związanego z komunikacją z ludźmi...
Dogadać? Jak masz 50,100,200 osób w projekcie to nie nazwałbym tego "dogadaniem". A co dopiero w ogromnych projektach? To jest niewykonalne. Do 20 osób może można się "dogadać".
@@krystianlaskowski bo mówi o moim doświadczeniu. Przerabiałem to co on i się z tym zgadzam. To co proponuje jest lepszym rozwiązaniem niż popełnianie błędów które są w necie i wielu firmach IT.
Na confiturze 2023 jest talk jakuba o zdrowiu psychicznemu i wymienia tam kilka rzeczy któe pozwalają lepiej o nie zadbać dzięki mikroserwisom (continuous deployment, observability, autonomy, tdd itp). Pracowałem w zespole rozwijającym mikroserwis który miała utonomię i przykładał uwagę do testów -> teraz pracuję w zespole dopisującym ify w monolicie bez testów z releasem raz na kwartał i manualnymi testerami którzy są klikaczami i jednak poziom wygody a przez to stresu pogorszył się o kilka rzędów wielkości przez co myślę o zmianie.
3:33 Panie Nabrdalik ach, no tak, bo przecież prawdziwy dział QA to elita, a testerzy manualni to tylko tacy od klikania przycisków. Jakież to wzniosłe podejście! Zapewne każda aplikacja naprawi się sama, jeśli tylko dostatecznie długo popatrzymy na wykresy i automatyczne testy, prawda?
Bardzo dużo konkretnej wiedzy, przekazane krótko zwięźle. Brawo!
Świetna odpowiedź o bezsensie szacowania przy braku wiedzy z przeszłości
Smuci mnie jak wiele z tych antypaternów, o których wspominałeś występowało w mojej poprzedniej pracy... Ale cieszy mnie, że zmieniłem pracę na BEC. Liczę, że skoro zaprosili takiego prelegenta, to dbają o dobrą architekturę.
I jak wrażenia?
1:26:09 czy ktoś wie o jakim konkretnie nagraniu mowa?
Chodziło mi o stronę en.wikipedia.org/wiki/Fallacies_of_distributed_computing
@@JakubNabrdalik dziękuje!
1:08:48 wspominany jest pattern którego nazwy że słuchu nie udało mi się rozkodować. Można prosić o zapisanie?
Strangler pattern
1:1:50 - niech rzuci kamieniem ten, kto we własnym jednoosobowym projekcie nie musiał rozwiązywać merge conflictów ;-)
Git człowiek!
Skad najlepiej czerpac wiedze dotyczaca tych pul wątków (na request, bazy danych itp), zuzycia cpu itp? Od teorii po praktyke? Zeby moc sie tym pobawic w lokalnych warunkach.
Co masz konkretnei ma nysli? Teorię dotyczącą pól wątków? W zależności od technologii w któej pracujesz to w dokumentacji (trudna ściezka dla nowicjusza) lub różnego rodzaju kursach online (któe co prawda często są ogólne i prawie zawsze nei wyczerpują tematu ale dla nowicjusza to imho ok). Jeżeli chodzi o praktykę to, zakładając, że masz jakąś aplikację która działa i jest od nie jakich ruch, możesz ywykorzystać metryki (grafana, prometheus itp) gdzie możesz sobie wizualizować właśnie takie rzeczy jak utylizacja wątków itp.
jak zrobić spójny backup danych w sytuacji 10^X mikroservisów z własnymi bazami ?
Co to jest spójny backup mikroserwisów?
I do czego ma służyć?
Możliwe, że bazy danych są oparte o sequencery i w takim przypadku spójny backup danych jest niezbędny ponieważ istnieje ryzyko że dane pomiędzy serwisami się rozsynchronizuja i będą wskazywać na id, zupełnie innego rekordu niż pierwotnie.
W takim scenariuszu to nie backup jest problemem tylko niepoprawnie zaprojektowane mikro serwisy/tabele bazodanowe. W sumie nie za często spotykam się z omawianiem tego problemu na prezentacjach, a źle zaprojektowana baza danych z mojego doświadczenia to największa kula u nogi projektu.
@@mrngwozdz Ciekawa uwaga. Ale się z nią nie zgadzam. Nie widziałem przypadku by ktoś wykonywał backup baz wszystkich mikroserwisów na raz i oczekiwał w tym backupie spójności. No bo niby czemu miałoby to służyć, skoro cały system i tak musi być zbudowany w oparciu o effectively-once delivery, oraz przywracanie danych każdego mikroserwisu jest kompletnie niezależne od pozostałych?
Chyba nie mówimy o tym samym. Wspominasz o źle zaprojektowanej bazie jako problemie projektu, podczas każdy z mikroserwisów ma swoje własne bazy, enkapsuluje dane, ma swoje własne read-modele (zawsze nieaktualne), i idealnie powinien mieć w dupie co się dzieje w pozostałych mikroserwisach (resiliency).
Pewnie łatwiej byłoby się dogadać jakbyśmy przyjeli jakieś założenia (np: event-driven na k8s z PostgreSQL, Redis lub MongoDB per serwis i Kafką z topic'ami z nieskończoną retencją gdzie pasuje + read modele w oparciu o compacted topics i Kafka Streams). Na przykład takie coś gitlab.com/jakubn/usage-analyzer/-/blob/main/README.md?ref_type=heads
Możesz na tym przykładzie wytłumaczyć do czego miałby służyć "spójny backup danych"?
@@JakubNabrdalik Dzięki za odpowiedź. Zacznijmy od tego że rozmawiamy o problemie który faktycznie występuje w projektach, ale nie powinien istnieć w przypadku prawidłowo wykonanej architektury mikrousługowej.
Spróbuję wyjaśnić prawdopodobny problem kolegi @mariuszgodziszewski8511 na przykładzie z życia, gdzie sam ostatnio miałem "przyjemność" pracować przy projekcie gdzie taki "spójny backup danych" występował.
Projekt całkiem spory, wszystko na rhelu z openshiftem na pokładzie (Self-managed) i oczywiście mikrousługami. Problem pojawił się taki, że osoby które prowadziły ten projekt wcześniej pracowali na monolitach i wszystkie tabele w bazach danych były na sequencerach. Dane pomiędzy serwisami często były powiązane właśnie po nich co doprowadziło do sytuacji gdzie w jednym module, odpowiedzialnym za raporty coś się mocno podziało nie tak, na tyle że trzeba było przywracać bazę danych.
Gdyby została przywrócona tylko baza danych w module raportującym, okazałoby się że serwis, który wiązał po id z raportami zacząłby dostawać nie swoje raporty (do czasu wyrównania sequencerów do stanu poprzedniego).
I tak o to powstała potrzeba przywracania baz danych dla wszystkich mikrousług, bo jeden z serwisów miał problem.
Pewnie dla Ciebie opisana sytuacja jest niedorzeczna bo jest to zwyczajnie kardynalny, podstawowy błąd. No ale cóż, tak to wygląda w wielu projektach szczególnie gdy ktoś przechodzi z pisania monolitów do mikrousług.
Podsumowując "spójny backup danych" jest odpowiedzią na problem, który nie powinien istnieć przy dobrze zaprojektowanej architekturze, co zresztą udowadniasz dziwiąc się na tak zadane pytanie.
Także @mariuszgodziszewski8511 - jeżeli doszło do sytuacji, że potrzebujecie takiej funkcjonalności to znaczy że coś mocno poszło nie tak.
@@mrngwozdz Wow, dzięki za odpowiedź. To faktycznie sytuacja chora w samych założeniach.
2:31 os/360 IBM do 1979 roku większość projektów upadała więc matematycy (KNUTH) (kryzys programowania) zajęli się sprawą żeby uporządkować sprawy a inny wymyślili programowanie obiektowe w c++ (sorry C) 6:32 tak jak pisałem (ale cicho sza o kryzysie programowania) a teraz rozwiąniem ma być ML i w ogóle wszyscy na bruk... coś co nie potrafi między 2 a 4 zdaniem dostrzec sprzeczności z drugiej strony taki system jest chyba nie możliwy według niezupełności arytmetyki tw. Godla .. czyli niemożność zautomatyzowania matematyki .. ale lepiej nie mówić o tym co nie działa albo jest sprzeczne i trudne do odkręcenia grunt że nowe rzeczy powstają nowe typy procesorów PCM zamiast HBM może kiedyś memrystory ... nowy hype AGI za 3 lata.. a ja myślę że Winter is Comming Again AI Winter.. 14:14 to nic innego jak modele w logice i podejście no właśnie formalizacji do matematyki bazując na kryzysie po 1930 czyli tworzenie modeli.. meta meta meta ... model może zautomatyzować te meta.. no tak ML ... end
2:22:55 - mega szacunek Jakub za ten tekst, to właśnie pokazuje patologię pod tytułem "outsourcing". Inaczej zwany al...ierą :)
Jakiego tabletu używa tutaj Pan Jakub, że tak fajnie może rysować LIVE?
ja tam widzę makbuka
@@ArekTheBoss Musisz mieć bardzo dobry wzrok 😄W której minucie?
@@ArekTheBoss Bardzo prawdopodobne. W 1:10:44 wspomina o AirPlay. :)
ipad, ale nie wiem, który pewnie pro
Smutne/zabawne jest to, że z tego powodu, że programiści nie potrafią się dogadać, tworzą skomplikowane (rozproszone) architektury, żeby uniknąć bólu związanego z komunikacją z ludźmi...
Conway's law
Dogadać? Jak masz 50,100,200 osób w projekcie to nie nazwałbym tego "dogadaniem". A co dopiero w ogromnych projektach? To jest niewykonalne. Do 20 osób może można się "dogadać".
Title in English, video in Polish. Good job, kurwa :)
Gościu zna się na rzeczy
Skąd wiesz? Bo brzmi mądrze? 😅
@@krystianlaskowski bo mówi o moim doświadczeniu. Przerabiałem to co on i się z tym zgadzam. To co proponuje jest lepszym rozwiązaniem niż popełnianie błędów które są w necie i wielu firmach IT.
Jaki cel ma nawiązanie w tytule do zdrowia psychicznego?
clickbait
microservice dobre
dzielenie roboty
(1h)
Na confiturze prowadzil prezentacje bardziej na temat zdrowia psychicznego ;)
W książce podanej w 5:45 masz odpowiedź
@@JakubNabrdalikczy prezentacja jest może dostępna pod jakimś URL?
Na confiturze 2023 jest talk jakuba o zdrowiu psychicznemu i wymienia tam kilka rzeczy któe pozwalają lepiej o nie zadbać dzięki mikroserwisom (continuous deployment, observability, autonomy, tdd itp). Pracowałem w zespole rozwijającym mikroserwis który miała utonomię i przykładał uwagę do testów -> teraz pracuję w zespole dopisującym ify w monolicie bez testów z releasem raz na kwartał i manualnymi testerami którzy są klikaczami i jednak poziom wygody a przez to stresu pogorszył się o kilka rzędów wielkości przez co myślę o zmianie.
❤
Bo nie umieją. Cieniasy. Nie obejrzałem minuty i już wiem dlaczego..
Dzban detected
@@takiezycie11 Pan Jakub nie zasłużył na takie słowa. Popitolił, ale jest fajny.
@@ambrozykleks626 xD
3:33 Panie Nabrdalik ach, no tak, bo przecież prawdziwy dział QA to elita, a testerzy manualni to tylko tacy od klikania przycisków. Jakież to wzniosłe podejście! Zapewne każda aplikacja naprawi się sama, jeśli tylko dostatecznie długo popatrzymy na wykresy i automatyczne testy, prawda?