The comparison of Service Mesh and how it can be a game-changer for enterprises
Top 3 Service Mesh
According to a survey report in 2020, the top 3 most known service mesh are Istio, Linkerd and Consul, for both production and evaluation^1.
To get a better understanding of each product, below is a comparison table, showing features and capabilities of the three service mesh solutions.
|Developed by||Google, IBM, Lyft||Buoyant||HashiCorp|
|Service Proxy||Envoy||linkerd-proxy||defaults to Envoy, exchangeable|
|Advantages||Istio can be adapted and extended like no other Mesh. Its many features are available for Kubernetes and other platforms.||Linkerd version 2 is designed to be non-invasive and is optimized for performance and usability. Therefore, it requires little time to adopt.||Consul service mesh can be used in any Consul environment and therefore does not require a scheduler. The proxy can be changed and extended.|
|Drawbacks||Istio's flexibility can be overwhelming for teams who don't have the capacity for more complex technology. Also, Istio takes control of the ingress controller.||Linkerd 2 is deeply integrated with Kubernetes and cannot be expanded. Since Linkerd 2 does not rely on a third-party proxy, it cannot be extended easily.||Consul service mesh can only be used in combination with Consul.|
|Supported Protocols||TCP, HTTP/1.1+, HTTP/2, gRPC||TCP, HTTP/1.1+, HTTP/2, gRPC||TCP, HTTP/1.1+, HTTP/2, gRPC|
|Sidecar / Data Plane|
|Automatic Sidecar Injection||Yes||Yes||Yes|
to avoid pod network privileges
|Platform and Cloud Integrations|
|Platform||Kubernetes||Kubernetes||Kubernetes, Nomad, VMs (Universal)|
|Cloud Integrations||Google Cloud, Alibaba Cloud, IBM Cloud||DigitalOcean||Microsoft Azure|
|Mesh Expansion||Yes||No (planned for future release)||Yes|
|Service Mesh Interface Compatibility|
|Traffic Access Control||3rd party support||No||Yes|
|Traffic Specs||3rd party support||No||No|
|Traffic Split||3rd party support||Yes||Yes|
|Traffic Metrics||3rd party support||3rd party support||No|
|Access Log Generation||Yes||No (tap-Feature instead)||Yes|
|"Golden Signal” Metrics Generation||Yes||Yes||Yes|
|Per-Route Metrics||experimental||Yes||depending on the proxy used|
|Dashboard||Yes, using Kiali||Yes||Yes|
|Compatible Tracing-Backends||Jaeger, Zipkin, Solarwinds||all Backends supporting OpenCensus||Datadog, Jaeger, Zipkin, OpenTracing, Honeycomb|
|Load Balancing||yes (Round Robin, Random, Weighted, Least Request)||Yes (EWMA, exponentially weighted moving average)||yes (Round Robin, Random, Weighted, Least Request, Consistent Hash)|
|Percentage-based Traffic Splits||Yes||Yes, through SMI||Yes|
|Header- and Path-based Traffic Splits||Yes||No||Yes|
|Retry & Timeout||Yes||Yes||Yes|
|Path-based Retry & Timeout||Yes||Yes||Yes|
|Fault Injection||Yes||Yes, by adding a deployment and a traffic split config||No|
|External CA certificate and key pluggable||Yes, CA cert pluggable and CA integration (experimental)||Yes||HashiCorp Vault, ACM Private CA, custom CA|
Buoyant offers a service mesh that works by inserting lightweight micro-proxies alongside each application instance and then providing a uniform means of controlling and monitoring proxy behavior through the control plane^8. Buoyant is also the creator of Linkerd, the open source service mesh for Kubernetes.
Shown here is a typical Buoyant Linkerd Service Mesh deployment
Some of the key benefits are^9: Reliability
Linkerd improves reliability without code changes and offers critical reliability features such as retries, timeouts, traffic splitting, and more to almost any Kubernetes application.
Linkerd adds mutual TLS (mTLS) between services, transparently encrypting and authenticating connections without developer involvement, and it's the best practice for cloud native environments.
Linkerd's off-the-shelf powerful metrics, tracing, and request inspection features allow you to gain vital insights into the behavior and health of your Kubernetes application.
Consul is a service mesh solution from HashiCorp that provides a full featured control plane with service discovery, configuration, and segmentation functionality^10. Consul offers flexibility in using each feature individually as needed, or used together to build a full service mesh solution.
Shown here is a typical Consul Service Mesh deployment in Kubernetes Cluster^11
Some of the key benefits are^12: Service Discovery
Service providers can register a service, such as api or mysql and can be discovered by using DNS or HTTP by applications who look for available services.
Off-the-shelf Multi Datacenter
Consul users will not need to build additional layers of abstraction to grow to multiple regions, as Consul supports multiple datacenters function out of the box.
Health checks and network security
Consul provides health checks, either designated for a given service, or with the local node. In addition, Consul can generate TLS certificates and distribute it for services to establish mutual TLS connections.
Istio’s diverse features provide a uniform way to secure, connect, and monitor microservices and allows companies to successfully, and efficiently, run a distributed microservice architecture. Istio is able to integrate into any logging platform, or telemetry or policy system^13.
Shown here is a typical Istio Service Mesh deployment
Some of the key benefits are^14: Traffic management
Istio’s simplified configuration and traffic routing lets you control the flow of traffic and API calls between services.
Istio provides a secure communication channel, while also manages authentication, authorization, and encryption of service communication at scale.
Istio provides robust tracing, monitoring, and logging features that give you deep insights into your service mesh deployment.
Challenges in Service Mesh Adoption?
Implementation of Service Mesh continues to grow for larger companies, as shown in the following figure^15.
However, at the same time adoption trends for clusters <5 continues to drop. This means that adoption in smaller companies/organizations might be decreasing since 2017, as shown here^16.
Another finding is that according to the 2019 CNCF survey results, 27% Kubernetes users of respondents stated that service meshes were one of the challenges in using/deploying containers in the first place, especially in terms of picking the right tool and in day-to-day operations. ^17.
Moreover, a panel that consists of several known experts agreed that steep learning curves, challenges on usability and continuous maintenance are considerable human effort that are currently required for service mesh implementation^18. According to Brian Harrington of Redhat, service mesh may not be a good fit for companies with homogenous technology stack, and if you need very fine control over how services communicate^19. Which may be an indicator of why service mesh adoption continues to grow for larger companies.
How can service mesh be a game-changer for enterprises or any industry?
Enterprise applications are commonly monolithic and require services such as —load balancing, traffic managing, routing, monitoring, security policies, service and user authentication, and protection against intrusion and DDoS attacks are necessary services often implemented as discrete appliances^20. But as these monoliths become modernized into microservices, the efficient way to monitor and scale hundreds or thousands of containers in the same way is using service mesh.
Service meshes like Linkerd and Istio are tools for adding observability, security, and reliability features to applications by inserting them at the platform layer and is rapidly becoming a standard part of the cloud native stack, especially for Kubernetes adopters ^21. Another essential benefit of service mesh is that it can help by both providing invaluable network telemetry like requests/second, latency information, number of failures, etc as well as aiding in distributed tracing to get a visual understanding of how services interact with each other ^22. This would be a powerful way for developers to use their familiar tooling to debug services while not impacting production request flows.
Introduction to service mesh: definition, development, and types of services
A service mesh is a dedicated infrastructure layer for handling reliable service-to-service communication. Shown here is a typical service mesh architecture
Service Mesh such as Istio supports services by deploying a special sidecar proxy throughout the environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality, which includes^23 ^25: Service-to-service communication (service discovery and encryption)
- Observability (monitoring and tracing)
- Resiliency (circuit breakers and retries):
- Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
- Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
- A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
- Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
- Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.
Service Mesh as a breakthrough innovation in Kubernetes management.
As companies are moving from monolithic to microservices, organizations utilize Kubernetes to manage micro app deployment and management. However, keeping an eye on end-to-end communication, security and service availability becomes a burden for enterprise applications.
Service mesh like Linkerd or istio provides critical observability, reliability, and security features, especially in Kubernetes’ pod model and networking infrastructure which allow service meshes to be implemented very easily with minimal operational burden^26.
Foot Notes https://thenewstack.io/new-kubernetes-ebook-learn-the-latest-in-kubernetes-deployments-and-trends/  https://servicemesh.es/  https://www.synerzip.com/wp-content/uploads/2020/04/Service-Mesh-Comparisons-Webinar-Synerzip.pdf  https://konghq.com/blog/multi-cluster-multi-cloud-service-meshes-with-cncfs-kuma-and-envoy/  https://docs.aws.amazon.com/app-mesh/index.html  https://www.cncf.io/wp-content/uploads/2020/08/rfma-servicemesh-cncf.pdf  https://thenewstack.io/an-exploratory-guide-to-the-service-mesh-platforms/  https://www.idc.com/getdoc.jsp?containerId=prUS47222420  https://buoyant.io/linkerd/  https://www.consul.io/docs/intro  https://learn.hashicorp.com/tutorials/consul/kubernetes-reference-architecture?in=consul/kubernetes  https://www.consul.io/docs/intro  https://istio.io/latest/docs/concepts/what-is-istio/  https://istio.io/latest/docs/concepts/what-is-istio/  https://thenewstack.io/new-kubernetes-ebook-learn-the-latest-in-kubernetes-deployments-and-trends/  https://thenewstack.io/new-kubernetes-ebook-learn-the-latest-in-kubernetes-deployments-and-trends/  https://thenewstack.io/new-kubernetes-ebook-learn-the-latest-in-kubernetes-deployments-and-trends/  https://containerjournal.com/topics/container-management/service-mesh-not-100-ready-for-wide-adoption/  https://enterprisersproject.com/article/2019/7/service-mesh-how-to-make-case  https://www.brillio.com/insights/service-mesh-why-it-matters-for-distributed-computing/  https://buoyant.io/2020/10/12/what-is-a-service-mesh/  https://itnext.io/service-mesh-for-the-developer-workflow-a-series-be7f91ee145e  https://www.vmware.com/content/dam/learn/en/amer/fy21/pdf/498818_Service_Mesh_for_Dummies.pdf  https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/DEVNET-1697.pdf  https://istio.io/latest/docs/concepts/what-is-istio/  https://buoyant.io/2020/10/12/what-is-a-service-mesh/
How can we help?
At CloudCover, we are always looking forward for the next challenge. Drop us a line, we would love to hear from you.
Thanks for writing us! We'll be in touch real quick.Back to website