Service mesh dostarcza funkcjonalności pozwalających na zaadresowanie problemów odkrywania usług, obserwowalności, bezpieczeństwa czy odporności na awarie (observability, service discovery, security, resilience). Nie każdy i nie zawsze potrzebuje by te funkcjonalności były dostarczane przez service mesha.
Jakie stosy technologicznie wykorzystujecie do zaadresowania powyższych obszarów?
problemów odkrywania usług,
Do tego wystarczy zwykły DNS tak jak to robi k8s
obserwowalności
Każdy serwis ma własne metryki, logowanie i tracing
bezpieczeństwa
To temat rzeka
resilience
Dużo można zrobić po stronie klienta np. client side load balancing. Libki takie jak hystrix robią właśnie to
Co do samych service meshów to dużo z ich ficzerów implementuje coś co się nazywa data plane np. envoy proxy choć to nic dziwnego, bo np. takie istio przecież używa envoya. Same service meshe mają taki sens, że co prawda wszystko można ogarnąć bez nich, ale ich użycie sprawia, że dużo problemów odnośnie łączenia różnych gotowych usług i rozwiązań spada na twórców service mesha a nie na team produktowy
problemów odkrywania usług
DNS wbudowany w Kubernetesa.
obserwowalności,
Prometheus + konfiguracja autodiscovery podów/serwisów/endpointów w Kubernetesie.
bezpieczeństwa
Network Policies w Kubernetesie, odpalanie jako nie-root, readonly filesystem, skanowanie obrazów, limity...
czy odporności na awarie
Czy wspominałem już o Kubernetesie? 
(healthchecki, autoscaler, node taints, node pressure, eviction, affinity, restartPolicy... ogólnie pierdylion rzeczy, ciężko wymienić większość :P)
@kelog mocno się na warstwie infry/platformy skupiłeś, a service mesh dużo daje też na warstwie aplikacyjnej.
Observability - Prometheus spoko, ale do metryk... pozostaje kwestia logów/tracingu? Service Mesh powinien potrafić zbierać przynajmniej tracing, żeby można było śledzić wywołania pomiędzy serwisami (przepływ requestów).
Z tego co wiem sam Prometheus nijak tego nie zrobi, więc tutaj albo Service Mesh albo implementacja tego w każdym mikroserwisie. Jak chcesz bardziej szczegółowy tracing to bez jakiejś implementacji po stronie mikroserwisów i tak się nie obędzie.
Bezpieczeństwo - zależy na jakim poziomie. Jak masz wymuszone np. szyfrowanie ruchu pomiędzy mikroserwisami to service mesh może być przydatny, kubernetes sam tego nie załatwi. Albo robisz to TLSem i wtedy jakiś service mesh dużo upraszcza (inaczej musisz obsługiwac TLSa na poziomie każdego mikroserwisu), albo lecisz jakimiś szyfrowaniami na warstwach niższych - jakieś IPSec/MACSec itp.
Ale to znowu bardziej warstwa infrastrukturalna. Na warstwie aplikacyjnej niektóre service meshe potrafią wymuszać polityki autoryzujące, np. tokenami OAuth2. Znowu, bez service mesha albo api gatewaya takie rzeczy musisz implementować w apce.
Resiliency - service meshe powinny wspierać to na warstwie aplikacyjnej czyli np. dla protokołów HTTP mają jakieś circuit breakery/retry.
Nie doprecyzowałem, ale faktycznie chodzi o funkcjonalności na poziomie serwisów (mesh operuje w kontekście serwisów) więc jeśli np. bezpieczeństwo, to rozumiane w kontekście uwierzytelniania i autoryzacji (np. serwisA woła serwisB, czy A jest tym za kogo się podaje i czy może wołać operację X z B). Nie chodzi mi o to co jest lepsze i dlaczego, ale bardziej o wybrane/praktykowane technologie.