Learn more about service mesh fundamentals in The Enterprise Path to Service Mesh Archictures (2nd Edition) - free book and excellent resource which addresses how to evaluate your organization’s readiness, provides factors to consider when building new applications and converting existing applications to best take advantage of a service mesh, and offers insight on deployment architectures used to get you there.
Client libraries (microservices frameworks) became very popular as microservices took a foothold in modern application design to avoid rewriting the same logic in every service. Example frameworks include the following:
An open source remote procedure call (RPC) library built on Netty for engineers that want a strongly-typed language on the Java Virtual Machine (JVM). Finagle is written in Scala.
An open source latency and fault tolerance library designed to isolate points of access to remote systems, services, and third-party libraries; stop cascading failure; and enable resilience. Hystrix is written in Java.
An open source Inter-Process Communication (IPCs) library with built-in software load balancers. Ribbon is written in Java.
An open source toolkit for building microservices (or elegant monoliths) with gRPC as the primary messaging pattern. Gokit is written in Go and comes with pluggable serialization and transport.
See the Layer5 service mesh landscape for a comprehensive perspective of and characterizing of all popular client libraries.
Prior to the availability of service meshes, developers used language-specific microservices frameworks to improve the resiliency, security, and observability of their services. The drawback of client libraries is that they embed infrastructure concerns into your application code. Services that embed the same client library across themselves in the presence of a service mesh incorporate duplicative code. Inconsistency is a concern for services that include different client libraries or different versions of the same client library. In environments with polyglot microservices, different client libraries are used.
Getting teams to update their client libraries can be an arduous process. When these infrastructure concerns are embedded in your service code, you'll need to track down your developers to update and reconfigure these libraries. It can take a long time to get a consistent configuration with the same and most recent version deployed. Enforcing consistency is challenging. As seen in the figure below, these frameworks couple your services with the infrastructure.
Figure 1: Services architecture using client libraries coupled with application logic
Different services teams must negotiate things like timeouts and retries when infrastructure code is embedded in the application. A service mesh not only decouples infrastructure code from application code, but it also decouples teams. Service meshes are typically implemented as infrastructure that exists outside of your applications, but as their adoption increases, this is changing, and their use for influencing or implementing business logic is becoming more prevalent.
Design your deployments the way you want. Drag-and-drop your cloud native infrastructure using a pallete of thousands of versioned Kubernetes components. Say goodbye to YAML configurations. Have your cloud native deployments automatically diagrammed. Deployments configured and modeled in Designer mode, can be deployed into your environment and managed using Visualizer. Discover a catalog of best practice cloud native patterns