Past Meetup

rg-dev #21 - Messaging i Distributed Systems!

This Meetup is past

98 people went

Location image of event venue

Details

Sezon 2018/2019 czas zacząć!

Zapraszamy na pierwsze po wakacyjnej przerwie spotkanie grupy rg-dev :).

Wystąpią:
1. Szymon Pobiega.
2. Wojtek Rząsa.

Szymon Pobiega - I shall say this only once
==========================================

And you shall do it only once. Exactly once. That's a very common assumption for most of business software. One trigger equals one outcome. As it turns out, it is easier said than done.

One way to solve the problem is to prevent messages from getting duplicated in the fist place. This requires transactions spanning data stores and messaging systems which is neither fast nor widely available.

Another way is taking advantage of natural idempotency of some operations, e.g. setting a value. But let's face it, most business code is more complex than that.

Right from the trenches, I'll show you the Outbox pattern which makes distributed transaction look like a rusty old timer. Join me in this talk and make sure you'll never refund a customer twice, again.

The Outbox records the IDs of processed messages so that duplicates are safely ignored. The outgoing messages are not dispatched immediately but first persisted along the business data to prevent ghost 👻 messages. The Outbox pattern has low performance footprint (lower than a distributed transaction spanning a queue and a databse) and can be used with any type of data stores.

O Szymonie:
-----------------

Szymon Pobiega used to work on various business software for almost a decade. Of all the ideas and petterns he learnt along the way, messaging had the most profound impact. He built his first micro service system with MSMQ and NServiceBus 1.9 some 9 years ago and this was a life-changing experience.

Over three years ago Szymon quit consulting and joined Particular Software with hope to use his field experience to make NServiceBus even better. Szymon is focused, in Particular (pun intended), on message routing patterns and handling of failures. Besides that he enjoys building remotely controlled vehicles with Lego.

Wojtek Rząsa - Przewidywanie zmian wydajności aplikacji rozproszonych
==================================

Wszyscy tworzymy systemy rozproszone, nawet jeśli to „tylko proste aplikacje www”. Z aplikacją rozproszoną mamy do czynienia już wtedy, gdy biblioteka frontendowa przechowuje stan kontrolek, który musi być zsynchronizowany z backendem. Innym przykładem jest uruchomienie aplikacji w środowisku produkcyjnym bazującym na rozproszonej infrastrukturze cloudowej. Oczywistym przykładem jest też korzystanie z zewnętrznych API. Środowisko rozproszone jest z natury zmienne i trudno przewidywalne. Czy zastanawialiście się kiedyś jaki wpływ na wydajność Waszej aplikacji będą miały zmiany tego środowiska? Jak się zmieni wydajność aplikacji gdy wydłuży się czas odpowiedzi jednego z zewnętrznych serwisów? A jeśli load balancer nierówno rozłoży obciążenie na poszczególne serwery aplikacji, albo jeśli zmienicie wydajność i liczbę maszyn które obsługują aplikację? Można to oczywiście przetestować, ale wymaga to na ogół sporo wysiłku i poniesienia niemałego kosztu (wliczając w to cenny czas pracy). Można to jednak zrobić łatwiej, szybciej i taniej. Zaprezentuję dwa konkretne przykłady w których przewiduję zmiany wydajności rzeczywistych aplikacji z mniejszym wysiłkiem i w krótszym czasie niż można to zrobić za pomocą testów. W swojej pracy używam symulacji, która pozwala analizować zachowanie systemu opisanego wygodnym, przejrzystym językiem dziedzinowym (DSL).

O Wojtku:
--------------

Informatyk z zamiłowania i z zawodu. Obecnie pracownik naukowo-dydaktyczny z doktoratem, ale przede wszystkim inżynier. Od dawna interesuje się systemami rozproszonymi i wytwarzaniem oprogramowania. Modeluje i bada wydajność sysyemów rozproszoych. Pracuje na Politechnice Rzeszowskiej, współtworzy Rzeszowską grupę użytkowników języka Ruby (http://RRUG.pl)