have probably heard about it, and usually in the same sentence that someone mentions "service mesh" there is typically the word "Istio" or "Linkerd", both prevalent implementations of this network abstraction layer. Service Mesh is an infrastructure layer created to control and handle all service-to- service communication needs in a micro services architecture. It controls the fl ow of the requests to the services, acts as a load balancer, encrypts data, discovers services, and aggregates them to your load balancer. Although you can determine the communication logic of your micro service in your code, the service mesh acts as an abstraction of this logic in a parallel infrastructure layer dedicated to it. The way it works is quite simple, and it uses just a proxy sidecar in each service pod to control it and provide information for your cluster. The sidecar proxy provides data and allows the exchange of information between services, with that you can focus on your business logic and leave the communication policies and routes to the service mesh controller.
use di ff erent methods and technologies to maintain tra ff i c visibility, logs, metrics, tracing, and security controls. The service mesh already brings all this in a centralized and organized way. Resilience Service mesh o ff ers mechanisms like Circuit Breaker, Latency-aware Load Balancing, a very consistent, enhanced, and robust service discovery. It allows you to con fi gure settings like retries, timeout, and deadlines in these services. Tra ffi c Control We can work with a very granular network tra ff i c control which permits an accurate and objective way to determine where the requests will be routed. Security Most service meshes o ff er a CA mechanism that dynamically generates certi fi cates for each service, ensuring s e c u r e s e r v i c e - t o - s e r v i c e communication. Delay & Fault Injection Most service meshes o ff er a way to con fi gure latency and failures to simulate what would happen in the real world. That way, you can analyze the behavior of your services in the case of a similar scenario. Less code for devs The features o ff ered by service mesh will reduce the amount of code that your dev team must write for your app. Many of your requirements for app controls and policies are already available in the service mesh features. Service Mesh
Micro services If you have a large scale application composed of micro services Visibility + Tracing + Metrics If you need to answer quickly and proactively regarding changes in customers behavior Deploy Strategies When you need controlled deployment methods like Canary and Blue/Green without the complexity of build that on top of k8s Security If you need or want to secure the communication between your services.
& Routing Suppose that you have an application that meets a huge demand, and this application is composed of several micro services communicating with each other. In these case, the communication fl ow can become a challenge since the requests between services can grow exponentially. You will probably need a sophisticated and intelligent routing strategy to keep the communication fl owing correctly and especially to maintain performance within the expected standards, avoiding degrading the communication between your services.
and IBM in partnership with Envoy Lyft team. Istio uses Envoy as a core component for your proxy sidecar strategy. Envoy is a distributed service proxy explicitly designed to work with micro services and mesh architectures. Istio General Information 12 About GitHub Starts 28.700+ GitHub Contributors 700+ License Apache 2.0 Version 1.9.x since jan/2019
services easier and safer by giving you runtime debugging, observability, reliability, and security—all without requiring any changes to your code. Linkerd is fully open source, licensed under Apache v2, and is a Cloud Native Computing Foundation graduated project. Linkerd is developed in the open in the Linkerd GitHub organization. Linkerd General Information 13 GitHub Starts 7000+ GitHub Contributors 200+ License Apache 2.0 Version 2.1.x About since fev/2016
- istio operator - helm packages Not at the moment Some, not well maintained What is required to bring Istio to clients? Have an o ffi cial terraform module? Have a community terraform module? We just need an operational k8s cluster
test and use Istio can use cert-manager to create mTLS certs ArgoCD Deploy strategies made easy like Canary and Blue/Green using Istio Tra ff i c Split features alongside ArgoCD Keptn Quality gateway to delivery APPs based on SLOs and rollback an app if a SLO rule is o ff ended Chaos Engineering We can test the resilience of our clusters with "service outage" simulations, chaosengineering-kit has a plugin for istio
Kubernetes How to install it ? - linkerd binary - helm packages - operator? no! Have an o ffi cial terraform module? We just need an operational k8s cluster Have a community terraform module? Not at the moment Some, not well maintained
Latency Low Regular Use of cluster resources Low High Security Good Good Sometimes Istio Proxy can consume more resources than the pod app itself, fact. Is it a problem? It depends. Istio can o ff er essential information or at least provide more availability for your service. If resources or cost is not a problem at all, then it's no problem. It's just a condition to run it. If cloud cost is an important variable, you should go with Linkerd, it's cheaper in terms of cloud costs.
v2 Apache v2 Core Language rust/go go GitHub Stars 7k+ 28k+ GitHub Contributors 200 700 GitHub First Release fev/16 jan/19 GitHub Latest Release 2.11.1 1.11.4 GitHub Releases 284 221 CVE Records 2021 0 6 Learning curve Low High Operation complexity Low regular > high Istio has more CVE records in 2021, and it also has more users and production cases. It's normal to fi nd issues when you have a large user base. Both are very secure projects.
you don't know what it is > When you don't know how it'll help your operation > When you don't know how it'll help your app performance > When you don't know how it'll help your app availability > When you don't know how it'll improve your business strategy > When the default k8s service discovery is enough for your needs > When the default k8s rollout is enough for your needs > When you don't have a large number of micro services to manage > When you don't have any micro services at all > When you don't have a massive tra ff i c fl ow for your services > When you don't need to secure the communication between your services
> Can be costly depending of the technology > Can be complex to the client understand how it works and to see the bene fi ts For our operation and team > It's simple to install, but complex to customize > The learning curve can be challenging > It's more complex to fi nd and fi x problems > It may change the way we deploy apps, requiring pipelines adjustments > It's one more system to deal, operate, update and also one more to fail The main projects related to service MESH are constantly evolving. A ton of new features are being created, tested, and delivered on each version. We're going to sail over these releases with a lot of new things to consider and try. Updates can be challenging as technology evolves. It's still evolving
installation and test > Dashboard installation and test > Mesh injection on a service (emojivoto app) > Fail injection test (book app) > Retries con fi guration using service pro fi les > Timeout con fi guration using service pro fi les Notes We have followed the Linkerd documentation to install, test, and try some features. Everything works as expected without any problems. The retries and timeout tests needed a swagger pro fi le for the APP, this can be tricky if the client doesn't have it ready for use. Another important information is that Linkerd can use any ingress, helping to minimise changes in your cluster and deployments con fi gurations.
the business requirements for a service mesh matches with Linkerd features, we should use it. It's simpler, lighter, faster and also it's very secure. In terms of cost, can be cheaper if we're looking to reduce the client cloud bills. If the costs is not an essential variable, and if the complexity is well considered and accepted by the client, Istio can be a great solution for the project because of the integrations and extra features. We need to consider that Istio is very popular and our clients will probably ask for it, we have to be ready to install it and maintain it. Consul is also another widespread service mesh implementation that we should consider and understand how it works at least. In the end, our team should master Istio and Linkerd and know how to work with Consul in production.