Based on some discussion, we need to investigate the relationship between MicroProfile and Service Mesh.
MicroProfile defines programming model for developing cloud-native microservices. Cloud Native microservices developed with MicroProfile can take advantage of a Service Mesh by extracting many concerns away from the development of the microservice itself. It is important for MicroProfile to understand the capabilities of service mesh, so that MicroProfile can offer complimentary features for the infrastructure and avoid the conflicts. Let’s find out what they can offer first.
A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast and reliable. Cloud-native microservices needs a service mesh infrastructure to provide service to service communication QoS. In practice, the service mesh add some lightweigh proxies without microservices needing to be aware. By default, proxies handle only intra-service mesh cluster from source to destination.
The service mesh is a networking model, sitting at layer of transport e.g. TCP/IP. It handles service to service communications. Service mesh manages the communication in the language-agnostic way.
There are two popular service mesh as follows:
The above two implementations are both open-source projects and designed for cloud-natvie microservices. Istio uses Lyfts' Envoy as a sidecar proxy while Linkerd is built on top of Netty and Finagle. Istio offers more functionalities than Linkerd, such as enforcing access control and usage policies across the service mesh. Refer to this page for more comparison
This specification looks at the service mesh in general with more focus on Istio.
MicroProfile defines a programming model for developing cloud-native microservices. It offers the following capabilities, such as config, Fault Tolerance, Metrics, Health, JWT, Open API, Open Tracing etc. As we progress, more and more specification might be defined in MicroProfile.