Tworzenie architektury systemów odpowiadającej przyszłym potrzebom biznesu to wróżenie z fusów. Nie istnieje jedna strategia  na strategiczne planowanie systemu. Zbyt wczesne podjęcie decyzji o architekturze opartej o mikrousługi może utrudnić refaktoryzacje i wprowadzić zbyt dużą bezwładność systemu wyniesioną na poziom infrastruktury i spowolnić development. Z kolei monolit bardzo ciężko opanować.

Zaprezentuję propozycję budowy systemu rozpoczynając od dobrze zorganizowanego monolitu z wyraźnie zaznaczonymi zakresami techniczno-biznesowymi, umożliwiającego podjęcie decyzji w którym kierunku go dekomponować i jak go dostarczać. Jego założeniem będzie dobre wykorzystanie strategicznego i taktycznego Domain-Driven Design, oparcie o Hexagonal Archiecture. Zaprezentuję ciągłe i automatyczne monitorowanie złożoności przypadkowej różnej klasy narzędziami wbudowanymi w CI.

Zapraszam, jeżeli interesuje Cię budowa systemów o bogatej i skomplikowanej domenie biznesowej.

Wielu developerów nie zdaje sobie sprawy, że czas odpowiedzi z serwera to często mniej niż 20% czasu ładowania strony. To dlatego, że łatwo przeoczyć różnicę w prędkości działania strony na błyszczącym MacBooku połączonym szerokopasmowym łączem, a telefonem przeciętnego Kowalskiego korzystającego z sieci 3G. Tymczasem już połowa ruchu w polskim internecie odbywa się z urządzeń mobilnych, co powoduje, że wracamy do czasów gdy każdy bajt i linijka kodu miały znaczenie. Podczas prezentacji powiem o tym jak wydajność przekłada się na cele biznesowe i dlaczego stwierdzenie, że strona jest załadowana nie jest takie proste jak się wydaje. Przedstawię też jak monitorujemy szybkość ładowania stron w Allegro oraz jakie są główne problemy, które obserwujemy. Opowiem również jak sobie z nimi radzić przy pomocy technologii takich jak SPA, HTTP/2 i AMP.

Gdy mówimy o orkiestracji powinniśmy myśleć o filharmonii i dyrygencie, który wskazuje muzykom rytm dzięki czemu każdy muzyk wie kiedy zagrać swoją - znaną mu z nut - partię. Tak samo zachowuje się metoda, która wskazuje innym metodom, kiedy mają wykonać swoje - znane - zadanie. Z kolei choreografia to układ taneczny, który nie potrzebuje dyrygenta. Wystarczy muzyka i tancerze (np. baletu) doskonale wiedzą kiedy zatańczyć swoją partię. Muzyka tworzy dla nich pewne zdarzenia, które pozwalają im reagować na nie w z góry ustalony sposób. Podobnie działa metoda reagująca na zdarzenie- jeśli coś się wydarzy możemy wykonać z góry zaprogramowany kod. 

W oparciu o te dwa fundamentalne podejścia do pisania oprogramowania zbudowano wiele frameworków i narzędzi. Leżą one w podwałach takich architektur jak Event Driven Architecture, Microservices, CQRS, Hexagonal Architecture i wiele innych. Moim zdaniem jednak zbyt rzadko zastanawiamy się nad nimi. Niezależnie w którym buzzwordzie jesteś zakochany wielokrotnie będziesz stawał przed wyborem jednej z tych dwóch dróg.

Chciałbym Wam pokazać plusy i minusy stosowania Orkiestracji i Choreografii, ale przede wszystkim jak praktycznie je łączyć ze sobą budując własną architekturę złożonych systemów- zarówno na poziomie kodu źródłowego jak i całych komponentów.  

Nie macie czasem wrażenia, że z każdym kolejnym projektem staramy się dostosować do aktualnie panujących trendów na rynku? W ostatnich latach jak grzyby po deszczu pojawiają się nowe pojęcia związane z podejściem do architektury - Microservices, CQRS, Event Driven Architecture, Event Sourcing, Ports&Adapters, Serverless, ... Do tego rozkwit bardziej rozproszonych podejść spowodował wręcz nawałnicę narzędzi wspomagających programistów w pracy z infrastrukturą projektu. Docker, Mesos, Marathon, Mesosphere, Kubernetes, ... Coraz częściej nasze systemy opieramy o rozwiązania "chmurowe", powstają strony na których uczestnicy mogą zgadywać, czy dane słowo jest nazwą technologii BigData, czy nazwą pokemona. Nie możemy też zapomnieć, że ostatnio modne stają się wszelkiego rodzaju chatboty oraz machine learning. Czy to nie jest trochę za dużo? Nie za szybko?

Tym samym dzisiejszy specjalista, musi mieć oczy z każdej strony i poświęcać jeszcze więcej czasu na rozwój niż kiedyś... Z jednej strony informacje są coraz łatwiej dostępne- konferencje, kursy online, szkolenia, firmy konsultacyjne. Ale w gąszczu tego wszystkiego czasem trudno jest zdecydować się na następny krok. Jakie zatem podejście powinniśmy przyjąć? Jak się rozwijać i jak budować architekturę naszych systemów w sposób, który przetrwa próbę czasu?

Na te oraz inne trudne pytania postarają się odpowiedzieć specjaliści: Sebastian Malaca (UBS), Jarosław Pałka (AllegroTech / Symentis) oraz Piotr Pelczar (Euro Bank).

Panel poprowadzi Daniel Pokusa, kierownik ścieżki Software Architecture oraz Software Craftsmanship SpreadIT 2017