We're a full-service IT house providing financial IT solutions for 25% of Danish bank customers. We enable them to invest online, take out loans and transfer money. In other words, everything it takes to run a bank.
We're a group of ambitious, open-minded people who love to develop and deliver financial technology solutions. With branches in Denmark and Poland, our company includes over 1700 people. Together we crack complex code through informal collaborations based on trust and a flat hierarchy.
Through knowledge exchange, we all can grow and develop professionally and personally. Our knowledge-sharing space in BEC Poland Warsaw office is always open to people and IT communities passionate about technology.
No dobrze, ale to jest po prostu SRP i zaprzestanie pisania kodu domenowego jako "to co mi PM opisał", zaaplikowanie tego za szybko łatwo prowadzi do wyciągania przedwczesnych abstrakcji nawet bez DDD.
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ę.
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
Osobiście mam spory żal do tej prezentacji. Mimo iż merytorycznie bardzo mocna w większości przypadków, to przedstawia bardzo czarno-biało wyższość mikroserwisów nad innego rodzaju architekturą (tu: monolitem). Wiadomo że rzeczywistość nie jest czarno-biała. Chyba że klucz kryje się w stwierdzeniu "dużego monolitu", który dość niekonkretnie definiuje grupę docelową. Wg Randy'ego Shoupa (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-9Q7GANXn02k.html) 1% systemów wpada w tę kategorię. Oczywiście każdy chce mieć poczucie, że jest w tych 1%. Dlaczego z mikroserwisami należy ostrożnie? M. in. z powodu Fallacies of distributed programming, o których wspomina Kuba, ale bardzo wybiórczo i pobieżnie. Tworzenie systemów rozproszonych nie jest łatwe i w niemal każdym przypadku, kiedy Kuba odnosi się do omawianych problemów i stwierdza "to proste", w praktyce, jeśli schodzimy poniżej ivory tower view, nie jest proste. Jest sporo rzeczy, które wprowadzają komplikacje i to znaczące, które wprowadzają złożoność np. data locality i idąca za tym eventual consistency, eventual consistency w ogóle, proprawna implementacja komunikacji messagingowej (reordering, duplication, domain events vs state transfer events), congnitive load infrastruktury i zrozumienia tego co się dzieje w systemie. No free lunch. Co jest nie do zrobienia w monolicie to głównie: niezależnych stacków technologicznych, niezależność wdrożeń, wysoka efektywność skalowania (mimo że całkiem nieźle można skalować nawet duże systemy). Reszta jest do ogarnięcia, nie wchodząc w Fallacies of distributed programming. Rzeczywistość jest dużo bardziej zniuansowana.
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.
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...
Od 5 lat pajtam sie po roznych firmach i zespolach i nigdy nie widzialem jeszcze dobrze skonstruowanego srodowiska stworzonego metodykami zwinnymi. Wszystko po lebkach, dlug technologiczny jak z Warszawy do Nowego Yorku, zespoly wypalone, management najwazniejszy, zespol nie ma nic do powiedzenia w zadnej kwestii, nie ma bezposredniego kontaktu z klientem, kazdy "robi swoje" i nosa poza "swoje" nie wysciubia, etc. Metodyki zwinne powinno sie zlikwidowac. To jest nieudany projekt i tylko co jakis czas ktos sie objawia, zeby zaprezentowac jak zrobic z tego cos uzytecznego. Jedyne czemu tak naprawde sluza to wieksza kontrola nad technicznymi i ucieczka od odpowiedzialnosci przez ludzi biznesu "bo przeciez zawsze mozemy zmienic kierunek". Wszystko jest w tych Agile'ach najwazniejsze, tylko nie dobra, inzynieryjna robota. Stad zreszta wzial sie ruch "software craftsmanship". Lub inaczej, Google zadnych Agile'ow nie robi i nadal dobrze sobie radzi.
@@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.
#My nootes The actual problems you're trying to solve The costs and risks of adopting a new architecture The benefits in terms maintainability, flexibility and long-term costs Entities define the business rules Use cases implement application logic and orchestrate entities Interface adapters translate user requests into use cases Frameworks implement the platform-specific code The 'main' component combines everything by depending on abstractions
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.
If there is only one version of the library shared, is this a coupling to a dependencies? This can became a disadvantages because of the need to develop a module based on a specific library version?
If we use monorepos and change version to shell and microfrontends, does it mean we need to deploy all artefacts from shell to microfrontends? Do we lose one of the main advantage of loading micro frontends in runtime and avoiding building shell app every time something's changed in MFE?
