Menu
I am planning to introduce K8s/Istio into my infra. Right now I have plenty of services which communicate with each other using RabbitMQ.
Service mesh concept seems to assume all services should be synchronous.
I'd like to keep at least some of my services async and take advantage of Mutual TLS Authentication which istio provides and also aggregated monitoring.
Is there any tools/methods which can help me to streamline management of both Sync and Async services?
Thanks,
547
A service mesh is a dedicated infrastructure layer that controls service-to-service communication over a network. This method enables separate parts of an application to communicate with each other. Service meshes appear commonly in concert with cloud-based applications, containers and microservices.
Popular service meshes include: Linkerd, Istio, Consul, Kuma, and Maesh. Supporting technologies within this space include: Layer 7-aware proxies, such as Envoy, HAProxy, NGINX, and MOSN; and service mesh orchestration, visualization, and understandability tooling, such as SuperGloo, Kiali, and Dive.
Conclusion. Service mesh is not an optional feature for consideration for organizations using a microservice architecture. It provides critical observability, reliability, and security features. As this runs on a platform level, it is not a burden on the core business application.
A Kubernetes service mesh is a tool that inserts security, observability, and reliability features to applications at the platform layer instead of the application layer. Service mesh technology predates Kubernetes.
Your application is decoupled from these operational capabilities and the service mesh moves them out of the application layer, and down to the infrastructure layer. These are some of the scenarios that can be enabled for your workloads when you use a service mesh:
All requests to or from a service pass through two proxies within the mesh: the proxy for the calling service and the proxy for the receiving service. This architecture abstracts all functions that are not related to the business logic away from services and service developers. The data plane manages the proxies and services.
There are several ways to enable correct service mesh communications. One way is to identify callers by their identifying service name and list them individually to specify the permitted callers for a service. Another way is to use labels as identifiers instead of service names.
For the advancement and adoption of service meshes, we believe that it is critical that they support event-driven or messaging-based communication
Please note that Istio can control non-HTTP protocols on top of TCP, including providing Mutual TLS Authentication. See this example of mTLS for HTTPS (treated as opaque TCP) - https://preliminary.istio.io/docs/tasks/security/https-overlay.html.
I am not familiar with AMQP, but since it is a protocol on top TCP, it should be possible to control it by Istio as opaque TCP.
136
Apparently there is WIP to add Async (Event driven) messaging to Envoy Proxy through Kafka filter: https://github.com/envoyproxy/envoy/issues/2852
Also good summary on using a Service Mesh for Event-Driven Messaging here: https://www.infoq.com/articles/service-mesh-event-driven-messaging
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
