tag:blogger.com,1999:blog-5197374494377847819.post4686968455293559956..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: Microservices w kontekście DDDSławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-5197374494377847819.post-32970322641671043802014-06-23T13:47:22.668+02:002014-06-23T13:47:22.668+02:00To ja jeszcze dorzucę taką myśl:
Przy MS zamienia...To ja jeszcze dorzucę taką myśl:<br /><br />Przy MS zamieniamy ogromny problem miękko-organizacyjny (współpraca między wieloma rozproszonymi zespołami nad jednym code-basem, propagacja wiedzy domenowej i synchronizacja, pilnowanie granic kontekstów) na masę średnich problemów technicznych (deployment, provisioning, monitoring, testowalność, network issues, etc.).<br /><br />A jakby nie patrzeć, ludzie którzy maczają w tym palce, mają dużo większe predyspozycje do rozwiązywania problemów technicznych, niż miękko-organizacyjnych.<br /><br />Dlatego, czym bliżej jesteś kodu i czym więcej musisz współpracować pomiędzy zespołami, by coś zaimplementować, tym masz większe parcie na mikroserwisy.jnbhttps://www.blogger.com/profile/11945481488520599011noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-44778714775475034122014-05-28T08:57:31.098+02:002014-05-28T08:57:31.098+02:00Moim zdaniem MS warto stosować, jeśli chcesz rozwi...Moim zdaniem MS warto stosować, jeśli chcesz rozwiązać problem skalowalności i ewentualnie wdrażania zmian. Dopóki nie ma jednego z powyższych, chyba lepszym rozwiązaniem będzie odpowiednia izolacja BC na poziomie pakietów (byle nie na zasadzie 'domain', 'usecases', 'services'). Pamiętajmy, że MS powinien mieć swój model, więc schodzenie niżej niż BC będzie w moim mniemaniu powodowało konieczność stworzenia jakiegoś shared modułu z domeną, co przeczy idei łatwości przepisania/izolacji MS.<br />Jeśli mamy podział funkcjonalny w pakietach, z dobrze zdefiniowanym API to IMHO łatwo wtedy stworzyć MS, problemem zostaje infrastruktura, ale od tego też są spece.<br />Na MS jest hype, ale z czasem wszystko sie uspokoi i tak jak kiedyś do wszystkiego próbowano zastosować DDD, tak teraz do wszystkiego próbuje się zastosować MS.pibuhttps://www.blogger.com/profile/09969717174350892250noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-22170028512881756252014-05-17T18:18:42.280+02:002014-05-17T18:18:42.280+02:00Bardzo ciekawe spostrzeżenia pojawiają się tu w ko...Bardzo ciekawe spostrzeżenia pojawiają się tu w komentarzach, szczególnie Sławka, żeby zacząć od podziału logicznego. <br /><br />Szum wokół MS może trochę przesłaniać fakt, że problemy dobrego modelu rozwiązania i jego wdrożenia są do pewnego stopnia ortogonalne.<br /><br />Idea MS wypłynęła na szersze internetowe wody, gdy paru lekko już brodatych architektów mających w głowie filozofię UNIXa, zaczęło głośno się wypowiadać, że król jest nagi, to znaczy przykładowy JBoss nie jest jedynym słusznym sposobem wdrażania, zwłaszcza, jeśli praktycznie nie korzystamy z gazyliona usług które przeciętny kontener J2EE oferuje. Mikroserwisy są bardzo DevOps-friendly (aplikacja == proces w systemie, każdy to zrozumie i ogarnie) i w drugą stronę, wymagają bardzo dojrzałego działu DevOps, bo w przeciwnym razie będzie bolało.<br /><br />Z drugiej strony zaczynam się obawiać, że nasza światek mody i hype'u przejmie ideę MS, i przemieli na swój sposób. Z jednego onanizmu możemy przejść w drugi. Już byłem świadkiem dyskusji nad pomysłem zastosowania mikroserwisów, ale brak wsparcia do dependency injection w jednym z gotowych "frameworków" już go dyskwalifikował :)Tomek Cejnerhttps://www.blogger.com/profile/15182716934876959212noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-79115790757956318412014-05-17T12:37:14.786+02:002014-05-17T12:37:14.786+02:00@Michał
Tak, o tym właśnie rozmawiamy:
1. z jedne...@Michał<br /><br />Tak, o tym właśnie rozmawiamy:<br />1. z jednej strony: jak jeszcze technicznie można osiągnąć tę separację, np: pakiety, widoczność bibliotek itd...<br />Tak samo jak mogę przepisać MS, mogę przepisać artefakt mavena. MS ew. bardziej bezkompromisowo wymusza granice i dobre api. Ale można zadać pytanie: dlaczego zespół nie potrafi projektować granic i przestrzegać ich reguł? Problemem jest skill techniczny czy wiedza o domenie problemu? Oba problemy są symptomami głębszych problemów w organizacja.<br /><br />2. Kosz MS. To się samo nie skoordynuje w proces i samo się nie wdroży...<br /><br /><br />A co do granicy BC to najlepsza zasada: granica wiedzy Eksperta Domenowego - zakładając, że w dużym projekcie bierze udział wielu ED. A duże BC można w głębi dzielić na poddomeny (kilka poddomen jest spiętych jedną warstwą API) - i z poddomen bym jednak nie robił osobnych MS ze względu na koszt zarządzania tym. BC ma spójne API, które techniczne może żyć jako MS.<br /><br /><br /><br /><br />A tak w ogóle to pojawia się jeszcze kwestia stylu projektowania API: drobno czy grubo ziarniście. Pomysł za uczynienie MS z agregatu wydaje się szalony, ale trzeba by zdać pytanie: po co ktoś może potrzebować takiej ziarnistości? Skończymy z remote interfejsem do EJB... po co? "because we can" jak mawia się w daleko stąd:PSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-24927891919229822932014-05-17T00:24:37.481+02:002014-05-17T00:24:37.481+02:00Ja bym spojrzał na to MS jako na rozwiązanie pewne...Ja bym spojrzał na to MS jako na rozwiązanie pewnego problemu - rozwoju i utrzymania. Wybrażam sobie, że rozumowanie mogło wyglądać tak: "Soft staje się coraz wiekszy, biznes rozwija się coraz dynamiczniej, jest dużo zmian, dużo eksperymentów. Nawet, gdy stosujemy wszystkie seksi wzorce, to żmudnie się refaktoryzuje i rozbudowuje soft. Jest po prostu za duży, a działanie "dziel i rządź" jest b. kostowne po przekroczeniu pewnej skali. Hmmm....co zrobić...No to może piszmy tak, aby nie trzeba było refaktoryzować! Piszmy tak, aby taniej było zaorać dany fragment i napisać go od nowa. Takie mini systemy w systemie...O! Micro services!"<br /><br />W tym kontekście MS z zakresie Use Case - dlaczego nie? MS jako BC brzmi dobrze. Ale też kierowałbym się nalogiczną zasadą co do Agregatów - projektuj małe BCs.<br /><br />Tak jak koledzy wspomnieli - gwóźdź programu jest w pytaniu: "Jaka jest metoda na wyznaczanie "właściwych" BCs i jak dobierać ich "rozmiar" ?Anonymoushttps://www.blogger.com/profile/03968505875451301931noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-16930997524496081462014-05-16T14:00:09.043+02:002014-05-16T14:00:09.043+02:00Podsumowując nasze listy "cnót" można si...Podsumowując nasze listy "cnót" można się zastanowić jak inaczej można by rozwiązać te problemy (np. jarki, pod warunkiem, że uda się nam ustalić stabilne api:).<br /><br />...oraz czy problemy tak na prawdę się rozwiążą gdy wejdziemy w szczegóły - np: stabilność api, zarządzenie wersjami itd... Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-72158103351289572062014-05-16T13:52:54.652+02:002014-05-16T13:52:54.652+02:00@Sławek, dzięki za bardzo fajne spostrzeżenia. Z u...@Sławek, dzięki za bardzo fajne spostrzeżenia. Z uwagi na to, że są bardzo techniczne, to jeszcze bym dodał bardziej organizacyjne:<br />- coś, co można niezależnie developować (oddzielny team, oddzielne repo ze źródłami, oddzielny proces budowania i releasu)<br />- coś, co można oddzielnie "sprzedawać" klientom (np. produkty na półkę z pluginami)<br /><br />Problemy się nie przenoszą - zostają tam, gdzie były - MS dają nam (IMHO) dodatkowe narzędzie, które może wpłynąć na podejmowanie decyzji przy tych problemach.<br /><br />Co niestety dalej nie daje nam mierzalnej heurystyki, która mogłaby nam służyć przy (nie)decydowaniu się na użycie MS. :)Piotr Wyczesany (@pwyczes)http://www.eventuallyinconsistent.com/noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-75159644991827035302014-05-16T13:22:50.407+02:002014-05-16T13:22:50.407+02:00@Piotr
Zacznę od końca, bo zastanowienie się nad t...@Piotr<br />Zacznę od końca, bo zastanowienie się nad tym jakie problem rozwiązuje MS jest właśnie "kluczem" o jaki pytasz...<br /><br />Są różne głosy<br />- coś coś mieści się w głowie - ok też jestem zdania, że problem niemieszczenia się w głowie jest przyczyną bałaganu i błędów.<br /><br />Ale można by to rozwiązać po prosto modularyzacją i komponentami (technicznie zależy od platformy).<br /><br />Pytanie jeszcze w czyjej głowie się nie mieść:) Bo to zależy.<br /><br />Ale w nietrywialnym systemie w głowie się nie zmieści koordynacja MS.<br /><br />- odporność na awarie. pada nam jeden MS, ale reszta działa. Idea piękna, ale coś potrzeba czegoś ponad MS (ESB, Saga itd)<br /><br />- Skalowanie - jw.<br /><br />Więc jak zwykle wracamy do klasycznych problemów... MS ich nie rozwiązuje, przenosi w inne miejsce...<br /><br />Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-65919585259521753672014-05-16T11:43:28.404+02:002014-05-16T11:43:28.404+02:00A to nie jest troszkę tak, że pojęcie microservice...A to nie jest troszkę tak, że pojęcie microservice'u możnaby umiejscowić w infrastrukturze?<br />Jeśli tak, to wówczas w zależności od problemu (jak @Marcin pisze) możemy _wykorzystać_ microservice na poziomie<br /> - Bounded Contextu,<br /> - Business Componentu w danym Bounded Context'cie (http://www.udidahan.com/2012/02/10/udi-greg-reach-cqrs-agreement/),<br /> - Kilku agregatów blisko leżących ze sobą - przykładowo współdzielących jakiś Workflow, czy też Sagę (trochę j.w.),<br /> - pojedynczego agregatu,<br /> - w ogóle nie wykorzystywać microservice'u, bo to nie ma sensu<br />Jeśli tak popatrzymy, to uzyskujemy dodatkowy cenny młotek do naszego toolboxa, którego użycie na odpowiednim poziomie mogłoby mieć uzasadnienie (uzasadniając nawet w.w. kuriozum).<br /><br />Jeśli z technicznego punktu widzenia popatrzymy na wnętrze microservice'u jako Haxagon (Ports & Adapters), to znowu wracamy do dyskusji jak Hexagon wpisuje się w DDD (i ponownie wybór na poziomach wymienionych powyżej).<br /><br />Co do rozpraszania - zgadzam się z @Marcinem. Być może, w niektórych przypadkach, okaże sie, że nie potrzeba specjalnej infrastruktury, bo wszystkie porty i adaptery działają w jednej maszynie wirtualnej (czy tam procesie), choć samo logiczne wydzielenie microservice'u wpłynie na jakość kodu.<br /><br />@Sławek - pełna zgoda z rozpoczęciem na poziomie logicznym. Tylko potem (jak już mamy Bounded Contexty) - co dalej? ;) Jaki klucz przyjąć do określenia kiedy microservice jest tym, co nam najlepiej pomoże?Piotr Wyczesany (@pwyczes)http://www.eventuallyinconsistent.com/noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-38624298227857313052014-05-14T22:27:36.459+02:002014-05-14T22:27:36.459+02:00Chyba zbliżamy się do uber-definicji:)
MS powinie...Chyba zbliżamy się do uber-definicji:)<br /><br />MS powinien mieć dobrze zdefiniowaną strukturę - np. warstwową: co najmniej api i domena.<br /><br />I dzięki temu pojawi się model kanoniczny - kontrakt na poziomie API i hermetyczna domena modelująca BC.<br /><br />Jak to będzie ogarnięte, to prawdopodobieństwo porażki jest mocno zredukowane, znacznie mocniej niż techniczne sposoby wdrożenia tego kodziku... Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-79202034658291571952014-05-14T22:14:18.277+02:002014-05-14T22:14:18.277+02:00Dokładnie tak, zacząć do znalezienia bounded conte...Dokładnie tak, zacząć do znalezienia bounded contexts i odpowiednim użyciu pakietów czy namespace-ów.<br /><br />Mimo że wywołania są robione w ramach jednego procesu (JVM) lub nawet w ramach jednego "unit of work" (Thread Local), kodować tak jak gdyby komunikacja przekraczała te granice. To trudne, jak podświadomie wiemy że to ten sam proces czy transakcja i można pójść na skróty :-(<br /><br />Dzięki temu mamy szansę na jako taki decoupling naszych bounded contexts.<br /><br />Jak już upewnimy się że wszystko działa, granice bounded context i publiczne api są ok, to można myśleć o "distibuted architecture".<br /><br />Wystarczy prześledzić historię Axon Framework, wersja 1.x w zasadzie pozwalała zbudować system w ramach jednej JVM. I co? goście z Trifork i tak tego używali bo dawało dobrą architekturę i decoupling.<br /><br />Dopiero wersja 2.x pozwala rozproszyć system i wcale nie jestem pewien że robi to wystarczająco dobrze ;-)Mhttps://www.blogger.com/profile/16794683082546782284noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-31254784520991055562014-05-14T20:33:55.555+02:002014-05-14T20:33:55.555+02:00@Wojtek
Dzięki za linka, lektura szczególnie komen...@Wojtek<br />Dzięki za linka, lektura szczególnie komentarzy uświadamia, że ludzie walczą z różnymi bólami i dlatego nie mogą się dogadać...<br /><br />Jednych boli wdrożenie, innych potrzeba różnych technologii a innych podział logiczny.<br /><br />IMHO trzeba zacząć od pakietów/namespace:)<br />Czyli Bounded Context - namysł nad podziałem logicznym. Bo to jest trudne i później praktycznie nieodwracalne oraz brzemienne w skutkach jeżeli chodzi o zrozumienie problemu domenowego.<br /><br />A dopiero w dalszej kolejności można zacząć zastanawiać się czy chcemy to rozpraszać, wprowadzać asynchroniczność itd...Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-70600906445255403422014-05-14T20:25:36.156+02:002014-05-14T20:25:36.156+02:00@Marcin
Tak... podstawowa zasada rozprasza obiektó...@Marcin<br />Tak... podstawowa zasada rozprasza obiektów Fowlera: "Just don't":)<br /><br />Fajnie, że nawiązałeś do złożoności esencjonalnej - gdzieś musi być orkiestracja całego procesu.<br /><br />W poście podlikowałem klasyczny teskt: http://www.rgoarchitects.com/Files/fallacies.pdf<br /><br /><br />Dzięki za linka do Journej (zaraz zaczynam czytać, fajny obrazek mają na głównej) i za linka do Twojego projektu - trochę klasek jest więc pewnie za kilka wieczorów ogarnę:)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-25647558988719951562014-05-14T20:12:37.461+02:002014-05-14T20:12:37.461+02:00@Jarek - też wydaje mi się, że zejście do poziomu ...@Jarek - też wydaje mi się, że zejście do poziomu Agregatu to kuriozum. To byłoby niżej niż Use Case... nanoserwis czyli stare "dobre" RMI.<br /><br />Podszedł bym tak: Bounded Context to jakieś kilka/kilkanaście agregatów, nad nimi warstwa Application Logic, która koncepcyjnie modeluje usługi (układające się w podproces złożony z kilku UC) a z technicznego puntu widzenia jest de facto API modułu (mikroserwisu po nowemu).Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-54183886465568973602014-05-14T18:31:44.296+02:002014-05-14T18:31:44.296+02:00To i ja coś podlinkuje. http://highscalability.com...To i ja coś podlinkuje. http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html <br />Wojtek (szogun1987)https://www.blogger.com/profile/11115881096519896556noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-43475149377231506412014-05-14T11:34:57.079+02:002014-05-14T11:34:57.079+02:00Na papierze idea "micro services" wygląd...Na papierze idea "micro services" wygląda bardzo kusząco. W praktyce pojawiają się przynajmniej dwa dylematy:<br /><br />Essential Complexity - jak podzielić system? Znajomość strategic design z DDD może dać tu jakieś wskazówki. Ale zagadnienie jest naprawdę trudne.<br /><br />Accidental Complexity - próba rozproszenia systemu bez świetnej infrastruktury (event bus / command bus, monitoring, deduplication etc.) i procesów (continous deployment) to strzał w stopę. <br /><br />Jak przychodzi mi chęć na rozpraszanie systemów to zawsze powtarzam sobie najpierw ze 100 razy, don't do that, don't do that ...<br /><br />Ale pewnie czasem trzeba ze względu na złożonośc, wielkość zespołu, skalowalność itp.<br /><br />Polecam lekturę CQRS Journey, jest ebook i kodzik http://msdn.microsoft.com/en-us/library/jj554200.aspx. Mamy trzy gotowe bounded context-y, więc można sobie spróbować zrobić z tego microservices. <br /><br />Nie wiem czy mogę ale tu są moje piersze próby wykorzystując Axon-a żeby nie utkąć na infrastrukturze:<br /><br />https://github.com/mkuthan/example-axonMhttps://www.blogger.com/profile/16794683082546782284noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-1201972282062165302014-05-13T22:58:03.013+02:002014-05-13T22:58:03.013+02:00Hm... też mam problem z artykułami o mikrousługach...Hm... też mam problem z artykułami o mikrousługach, pisał o tym Fowler, tego przesłania chyba nie zrozumiałem, granica "tego pomysłu" dąży do obiektu/agregatu z jego interfejsem... ale to chyba już przegięcie... SOA złożone z pojedynczych use cas'ów??? Kontekst i dziedzinowa specyfika raczej wyklucza "jednej czynności" jako kompletnej kontekstowo aplikacji ....ToJaJarekhttps://www.blogger.com/profile/07492446399792666065noreply@blogger.com