Dlaczego serwisu bez stanu stateless są beznadziejne. I co ma do tego dapr.

We’ve all seen systems that were tightly coupled, and maybe you are working in that kind of system right now. It seems that keeping codebase without high coupling its hard. Because most of the systems ends as not maintainable mess, we just need some time to make it like that. And I want to be clear, I’m not trying blaming any of you because I’ve done the same. But after 60 years from when coupling was invented, I think it’s time to stop chasing the newest technologies and focus on what is causing those p...

What I learned from $2500 Udi Dahan course Around the beginning of April 2020 Udi Dahan, owner of Particular Software, released his course in a form of online videos, for free. The big deal is that Udi is one of the world’s foremost experts on Service-Oriented Architecture, Distributed Systems, and Domain-Driven Design. This was a trigger for me and my whole team to watch the course and have a weekly discussion session to talk through completed chapters. Here is what I learned.Use messaging In his cour...

Ostatnio na blogu sporo o SOA. W poprzednim wpisie, poruszyłem temat kompatybilności, teraz czas na coś, co ma na celu zminimalizowanie ilości różnych wersji usług. Najprostszym sposobem na uniknięcie problemów z kompatybilnością jest po prostu nie wprowadzenie niekompatybilnych zmian. Consumer-driven contracts to prosty sposób, aby mieć pod kontrolą śledzenie zmian oraz ich wpływ  na konsumentów naszej usługi. Zwykle usługi posiadają pewien schemat (schema) czyli po prostu kontrakt. Najbardziej restry...

Chciałbym podzielić się z Wami moimi refleksami po obejrzeniu prezentacji Martina Fowlera i Jima Webbera zatytułowanej "Does My Bus Look Big in This?". Prezentacja ta odbywała się podczas konferencji QCon w Londynie w 2008 roku. Minęło już sporo czasu, jednak główne przesłanie nie straciło nic ze swojej aktualności. A przesłaniem tym jest: nie potrzebujemy wielkich, ciężkich i kosztownych produktów ESB! Pierwsza część prezentacj poświęcona jest charakteryzacji typowego pr...

W jaki sposób pokonać ograniczenia standardowego protokołu inwentarza usług, nie łamiąc przy tym zgodności ze standardami? Wzorzec Canonical Protocol zaleca wykorzystania jednego, standardowego, protokołu do komunikacji między usługami w ramach jednego inwentarza. Domyślnie oczywiście, protokołem tym są jakiegoś rodzaju usługi webowe (Basic WS, WS-*, REST), jednak nie jest to twarde wymaganie. Niezależnie od wyboru standardowego protokołu, mogą zdarzyć się sytuacje, kiedy jest on z jakichś przyczyn ni...

W jaki sposób infrastruktura przechowująca stan usług może być skalowana i zabezpieczona przed awarią? Odpowiedzią na to pytania jest wzorzec Service Grid. Jego nazwa może być nieco myląca. Nie ma on bowiem nic wspólnego z gridami oraz raczej niewiele z usługami w klasycznym pojęciu SOA. Service Grid jest nazwą dla podejścia, w którym wiele instancji infrastruktury przechowującej stan usług jest równolegle aktywnych (zwykle na wilu fizycznych maszynach). Instancje te współdzielą między sobą informacje d...

Jest to wzorzec z grupy porządkujących logiczny warstwy inwentarza (?) [inventory] usług. Pozostałe dwa z tej grupy to Entity Abstraction i Process Abstraction. Wszystkie trzy wzorce pomagają zidentyfikować różne grupy odpowiedzialności w "kandydatach na usługi". Skutkuje to wydzieleniem współnych zakresów odpowiedzialności do nowych usług lub łączeniem usług odpowiadających za ten sam aspekt rozwiązania. Utility Abstraction zajmuje się konkretnie funkcjonalnością wykorzystywaną we wszystkich fragm...

To właściwie dwa wzorce: Capability Composition oraz Capability Recomposition. Pierwszy z nich rozwiązuje problem usługi, która w celu wykonania swojego zadania potrzebueje logiki, która nie mieści się w jej zakresie odpowiedzialności. Aby problem rozwiązać, można poszerzyć zakres odpowiedzialności usługi, jednak prowadzi to do duplikacji logiki. Innym, lepszym i poprawnym, rozwiązaniem jest włączenie wywołania innej usługi jako elementu realizacji logiki tej pierwszej. Właściwie wydaje się to zup...

Druga notka na temat pojedynczej sesji TechEd i znów dotyczy prezentacji Juval-a Lowy. Tym razem na warsztat postanowiłem wziąć prezentację o nieco intrygującym tytule "The Zen of Architecture". W moim przekonaniu Lowy był gwiazdą tegorocznej edycji TechEd, przynajmniej jeśli chodzi o tematy mnie interesujące, czyli architektura, SOA i okolice.