[dnaprawa]

(dłuższy wpis) 4 filary aplikacji mikroserwisowych z perspektywy Kubernetes

1) Komunikacja

W monolitycznych aplikacjach działających w pojedynczym procesie komponenty wywołują się nawzajem za pomocą metod na poziomie języka programowania lub wywołań funkcji.

Mogą być one silnie powiązane, jeśli tworzysz obiekty z kodem (na przykład new Class()) lub mogą być wywoływane w sposób rozłączony, jeśli używasz wstrzykiwania zależności, odwołując się do abstrakcji (np. IMyInterface), a nie konkretnych wystąpień obiektów. Tak czy inaczej, obiekty działają w ramach tego samego procesu (monolitu).

Jednym z największych wyzwań przy zmianie z aplikacji monolitycznej na aplikację opartą na mikroserwisach jest zmiana mechanizmu komunikacji.

Komunikacja synchroniczna

HTTP to protokół synchroniczny. Klient wysyła żądanie i czeka na odpowiedź. Jest to niezależne od wykonania kodu klienta. Jako że HTTP/HTTPS) jest synchroniczny – kod klienta może kontynuować swoje zadanie tylko wtedy, gdy otrzyma odpowiedź serwera.

Komunikacja asynchroniczna

Inne protokoły, takie jak AMQP (protokół obsługiwany przez wiele systemów operacyjnych i środowisk chmurowych), używają komunikatów asynchronicznych. Kod klienta lub nadawca wiadomości zwykle nie czeka na odpowiedź. Po prostu wysyła komunikat tak, jak w przypadku wysyłania komunikatu do kolejki RabbitMQ lub dowolnego innego brokera wiadomości.

2) Monitoring

Mając monolit monitorujemy.... monolit. Czasami wystarczy prosty ping, czy apka żyje. Czasami coś więcej. Ale ogólnie temat jest znacznie prostszy niż w architekturze rozproszonej.

Kluczowe jest, by wiedzieć, czy (i kiedy) dany komponent przestaje zachowywać się poprawnie. Potrzebujemy zatem czegoś więcej niż prosty ping. Pojawia się zatem pytanie:

Jak wdrożyć monitoring do całego systemu i jak ma się do tego Kubernetes?

Istnieje wiele rozwiązań. Są narzędzia płatne, ale są także sprawdzone w boju narzędzia open-source wchodzące w skład CNCF. I na takich właśnie się skupimy za tydzień podczas szkolenia.



3) Logowanie

Logować trzeba, to wiemy.
Tylko gdzie, i jak zarządzać tymi logami jeśli aplikacja jest wdrożona w Kubernetes?
Czy aplikacja powinna logować do pliku, bazy danych, a może gdzie indziej? (Z naciskiem na gdzie indziej)

Znowuż, wykorzystamy to co oferuje nam świat Cloud-Native i wdrożymy system logowania w praktyce.



4) Observability

Czyli inaczej mówiąc podstawa, jeśli chcesz wiedzieć co dzieje się w Twoim systemie w razie pojawienia się błędów.

Warto przyjrzeć się standardowi Open Telemetry.

Będziemy z niego także korzystać podczas webinaru
Zdradzę, że wykorzystamy do tego narzędzie Jaeger.

Jeżeli powyższe tematy Cię interesują (z naciskiem na Kubernetes!) wpadnij webinar.
Środa, 26.01.2022 godz. 20.00.

#wkontenerach #programowanie #programista15k #kubernetes #mikroserwisy #docker #informatyka

[Enzo_Molinari]

@dnaprawa: zapisany ( ͡° ͜ʖ ͡°)

[alex-fortune]

@dnaprawa: ad. 1 - co ma protokół komunikacji do sync/async? Możesz bez problemu wysyłać requesty http i dalej iść z kodem. Ad cała reszta - tyle o narzędziach, a tak mało o samych rozwiązaniach :/

[dnaprawa]

@alex-fortune: Możesz bez problemu wysyłać requesty http i dalej iść z kodem - no fizycznie owszem, możesz, ale w praktyce tak się nie robi przy mikroserwisach. Jeśli wysyłasz HTTP request to czekasz na odpowiedź, bo chcesz mieć rezultat. Ale wtedy czy mikroserwisy mają sens? :)