rg-dev #44 - Modularny monolit i komunikacja w Mikroserwisach!
Zapraszamy na kolejne 44. spotkanie rg-dev!
Widzimy się 26. maja w Rzeszowskich Piwnicach (dawna Estrada Caffee)!
=====================================================================
Kamil Bączek - modularny monolit
Opis:
Podczas prezentacji odpowiemy sobie na pytania: Czym charakteryzuje się styl architektoniczny modularny monolit? Dlaczego warto rozpocząć projekt od modularnego monolitu? Jak wyznaczyć granice pomiędzy modułami? Jak wygląda struktura takiego projektu? Przedstawie na przykładzie w .NET, najważniejsze elementy implementacji. Pokaże przykłady prostych modułów typu CRUD oraz moduły gdzie występują procesy biznesowe. Opis mogę dopracować jeśli bedzie potrzeba, gdy bedziecie wrzucać na meetup to konkretne spotkanie.
Bio:
Kamil Bączek, .NET Team Leader w SoftwareMind. Fan architektury oraz software design. Ciągle szuka nowych technik, aby jego projekty stały się bardziej utrzymywalne i rozszerzalne. Prowadzi blog ArtOfSoftwareDesign.net. Kamil rozwija projekt open source “Estimation Tool”, który jest rozbudowanym przykładem zastosowania architektury modularnego monolitu oraz Domain Driven Design. Uwielbia dyskutować na tematy związane z Software Craftsmanship. Jego hobby to siłownia.
=====================================================================
Wojciech Rząsa - Mikroserwisy - od HTTP do Kafki (czyli tam i z powrotem?)
Opis:
Komunikacja w mikroserwisach - jak powinna być zrealizowana?
Oczywiście komunikacja oparta na HTTP jest łatwiejsza do poprawnej implementacji i zapewne także do zaprojektowania. Zwłaszcza, że wielu deweloperów i architektów ma sporo doświadczenia z takim podejściem. Z drugiej strony podejście asynchroniczne, oparte na wiadomościach przesyłanych za pomocą kolejek ma wiele zalet. Pozwala tworzyć rozwiązania odporne na awarie, które nawet w przypadku wystąpienia usterek czy przeciążeń nadal mogą dostarczać usługi użytkownikom.
Większość komunikacji jaką w FLYR Inc. zrealizowaliśmy w naszym produkcie była synchroniczna, oparta na HTTP. Na pewnym etapie rozwoju systemu okazało się jednak, że do zrealizowania wymaganej funkcjonalności potrzebujemy czegoś bardziej elastycznego i... asynchronicznego. Jakie decyzje podjęliśmy? Co zrobiliśmy, żeby te decyzje nie były ostateczne, żebyśmy mogli zmienić te, które w przyszłości okażą się błędne? Jak zapewniliśmy, że deweloperzy będą poprawnie wykorzystywać message brokera, właściwie używać jego sterowników, a każdy serwis będzie miał wiarygodny healthcheck dla Kubernetes? Na te pytania postaram się odpowiedzieć opowiadając swoją historię. Na podsumowane opowiem też parę historii o tym z jakimi problemami walczyliśmy przy samym wdrażaniu asynchronicznej komunikacji w naszym systemie i czego się przy tej okazji nauczyliśmy.
Nie mam dla Was jedynie słusznych rozwiązań i rad, które zawsze się sprawdzą. Ale mogę podzielić się z Wami błędami, które udało nam się naprawić i tymi, których udało nam się uniknąć.
=====================================================================
Spotkanie możliwe dzięki naszym partnerom: PGS Software, Ideo oraz FABRITY, za co im serdecznie dziękujemy!
Zapraszamy do kontaktu wszystkich chętnych do wystąpienia podczas kolejnych spotkań!
Zachęcamy do zapisywania się ;)
