W Pracuj.pl przeszliśmy daleką drogę. Zaczęliśmy od dwóch dużych monolitycznych aplikacji rozwijanych przez dziesięcioosobowy zespół, wdrażanych raz w miesiąc. Skończyliśmy w miejscu, w którym 100 serwisów rozwijanych jest w myśli idei SOA* przez 80 deweloperów z 9 zespołów, a ich praca wdrażana jest produkcyjnie 75 razy każdego tygodnia. Jeśli chcesz wiedzieć, jakie problemy dzięki SOA udało nam się rozwiązać, jakie nowe problemy przez to się pojawiły, a jakie wciąż pozostają niezaadresowane, to zapraszamy na nasza prelekcję. * przyjmijmy, że microservices = soa done right

1. PRACUJ.PL – SOA ZROBIONE
(PRAWIE) DOBRZE
Kamil Piechociak
Krzysztof Staruch
GRUPA PRACUJ

2. AGENDA

3. CZEGO SIĘ DOWIECIE
Jakie konsekwencje niesie za sobą architektura rozproszona SOA.
Jakie narzędzia okazują się niezbędne z praktycznego punktu widzenia.
Jakich efektów (pozytywnych i negatywnych) można się spodziewać.

4. CZEGO SIĘ NIE DOWIECIE
Co to są mikroserwisy.
Ile linii kodu może posiadać mikroserwis.
Jakich klas użyć do budowy mikroserwisu.

5. HISTORIA

6. TROCHĘ HISTORII – ETAP I (ŚREDNIOWIECZE)
Skalowanie tylko wertykalne.
Coraz trudniejsza rozbudowa.
Słaba skalowalność zespołów.

7. TROCHĘ HISTORII – ETAP II (RENESANS)
Początki rozproszenia systemów –
odseparowane usługi SOA.
Pierwsze integracje (REST + instancja
RabbitMq).
Brak maszyn fizycznych.
Wprowadzenie chmury jako drugiego
data/hosting center.
System A
Application A
System B
Application B
DTSX

8. TROCHĘ HISTORII – ETAP III (TERAZ)
Refaktoring i przepisywanie
funkcjonalności do postaci niezależnych
usług SOA.
Skalowanie horyzontalne usług.
Wiele małych zespołów
skoncentrowanych na poszczególnych
usługach.

9. TROCHĘ HISTORII – ETAP IV (PRZYSZŁOŚĆ)

10. CZEGO SIĘ NAUCZYLIŚMY

11. WZROST ILOŚCI USŁUG
Liczba
repozytoriów
200
Liczba
maszyn
150

12. WZROST ILOŚCI USŁUG
Problem
Brak fizycznych zasobów
zaspokajających wzrost usług
Długi czas oczekiwania na maszyny
fizyczne
Rozwiązanie

13. DWA CENTRA HOSTINGOWE

14. WIELKA WERYFIKACJA (EYE OPENER)

15. NIEDOSTĘPNOŚĆ USŁUG
Usługa A
1
2
3
6
5
7

16. NIEDOSTĘPNOŚĆ USŁUG
Usługa A
1
2
3
6
5
7
5'

17. NIEDOSTĘPNOŚĆ USŁUG
Problem
Hosting
Center 2
Hosting
Center 1
Service A
Service B
RabbitMq
Service C
Rozwiązanie
Hosting
Center 1
Service A
Service B
RMQ
Cluster
Hosting
Center 2
Service C
RMQ
Cluster
federacja

18. DYNAMICZNA ZMIANA KONFIGURACJI – SERVICE
DISCOVERY
Problem
Stawianie nowych instancji usług
wymaga zmian konfiguracyjnych w
usługach zależnych.
Rejestr usług musi być systemem
rozproszonym wspierającym wiele
centrów hostingowych.
Client requesting
Service A
Service A
On X.X.X.X
Service A
On Y.Y.Y.Y
Service
Registry
Health
Check
Health
Check
Get me
Servce A
Announcements
(Hello / Goodbye)

19. PRZYSPIESZENIE DEVELOPMENTU
Problem
Potrzeba częstych releasów
Coraz rzadsze wdrożenia produkcyjne
Rozwiązanie
Continuous Integration & Delivery
Zdefiniowanie spójnego procesu
wdrożenia

20. WYZNACZANIE GRANIC
Problem
Odpowiedzialności usług zachodzą na
siebie.
Nie wiemy jak wyznaczyć granice
funkcjonalne pomiędzy usługami.
Nie mamy zidentyfikowanych
przepływów informacji między
systemami.
Rozwiązanie
Dekompozycja funkcjonalna systemów
poprzez Event Storming

21. ZBIERANIE LOGÓW I MONITORING
Problem
Ręczne przeszukiwanie logów na wielu
maszynach.
Wizualizacja kluczowych informacji na
podstawie rosnących logów.
Rozwiązanie
System zbierania rozproszonych logów –
Logstash (+ Elasticsearch + Kibana)

22. ZBIERANIE LOGÓW

23. PRZEPŁYW DANYCH POMIĘDZY USŁUGAMI
Problem
Identyfikacja jak dokładnie przebiega
przepływ danych procesu biznesowego
w odpowiedzi na żądanie.
Która usługa w danym przepływie jest
najbardziej czasochłonna.
Wizualizacja całego procesu
biznesowego.
Rozwiązanie
Tracer – mechanizm śledzący requesty

24. AUTENTYKACJA
Problem
Brak spójności mechanizmów
autentykacji
 Użytkowników
 Systemów
Każdy system implementuje własny
mechanizm autentykacji / autoryzacji.
Synchronizacja danych o użytkownikach
między systemami.
Rozwiązanie
Wprowadzenie wspólnego systemu
autentykacji i mechanizmów Single Sign-
On

25. AUTENTYKACJA
User
Identity
Server
API Service B
Service A
User
Credentials
User
Token
User
Token
User
Token
User
Token
Service
Secret
Service
Token
Service C
Service
Token

26. STANDARDY KOMUNIKACJI
Problem
Usługi muszą umieć ze sobą rozmawiać
bez względu na technologię, w której są
napisane.
Mechanizmy komunikacji powinny być
maksymalnie proste do użycia.
Rozwiązanie
REST (HTTP)
AMQP (RabbitMq)

27. KONFIGURACJA ŚRODOWISK
Problem
Gwałtowny wzrost środowisk zwiększył
koszt utrzymania spójności instalacji i
konfiguracji.
Wiedza na temat konfiguracji jest
rozproszona pomiędzy zespołami.
Rozwiązanie
Automatyzacja konfiguracji środowisk
poprzez narzędzie zarządzania
konfiguracją.
Infrastructure as Code.
Centralne repozytorium konfiguracji.

28. EPILOG

29. EFEKTY ZMIAN
Przed
2 zespoły
3 wdrożenia produkcyjne miesięcznie
Brak skalowalności
Trudna rozwijalność
Po
9 niezależnych zespołów SCRUMowych
75 wdrożeń tygodniowo
Elastyczność
Większa dowolność technologiczna
(standardy technologicznie agnostyczne)

30. NIEROZWIĄZANE PROBLEMY
Kto to utrzymuje
Problem z pozyskaniem pewnych kompetencji technologicznych
Wysoka krzywa uczenia
Wyznaczenie ownerów usług
Ewidencja maszyn/usług
Czyje to eventy

31. NARZĘDZIA NIEZBĘDNE Z NASZEGO PUNKTU
WIDZENIA
1. Chmura
2. Liczba i lokalizacja zależności względem siebie
3. Service Discovery
4. CI / CD
5. Wyznaczenie granic odpowiedzialności usług
6. Rozproszone logowanie
7. Monitoring techniczny i biznesowy
8. OAuth2
9. Puppet
10. Międzyplatformowe standardy komunikacji (REST, AMQP)

32. DZIĘKI!