Context
As Microservices architecture isolates system functionalities into multiple independent services, the communication mechanism between these services plays a key role for a scalable, available, and high-performance architecture.
A service mesh is an infrastructure layer that manages service communication in a transparent and language-independent way. It helps to configure how service instances perform critical actions such as service discovery, load balancing, data encryption, and authentication and authorization.
Applicability
Service Mesh pattern is more applicable when you have:
- Services in multiple programming languages requiring a common architectural pattern for communication.
- Offloading responsibilities such as security, service discovery, load balancing, authentication, monitoring, etc.
- Particularly useful in synchronous communication (REST, gRPC, WebSocket). For asynchronous or event-driven, it can co-exist along with event-mesh or messaging architecture.
Istio
Istio is the most popular open-source service mesh created by Google, IBM, and Lyft with native integration to Kubernetes, and Envoy as Service Proxy. Istio Control plane handles automatic load balancing, routing, policy management, observability (metrics, logs & traces), authentication and communication, and many more.
Istio as Managed Service is available with:
AWS App Mesh
AWS App Mesh is a managed service providing application-level networking and service communication support for Microservices architecture. It also uses Envoy proxy making it compatible with multiple solution approaches. It supports h AWS Fargate, Amazon EC2, Amazon ECS, Amazon EKS, and Kubernetes running on AWS.
Features Comparison
While there is no silver bullet for comparison, it is dependent on system context and applicability to meet functional & non-functional requirements. The below list includes all the key features required for the system under consideration as part of our research with High & Low or Yes & No as relative measures:
| Feature | AWS App Mesh | Istio | Notes & Key Observations |
|---|---|---|---|
| Operations cost | Low | High | Istio: Self-managed Control plane. Operational overhead if not using managed service of Istio. |
| Portability | Low | High | Istio is built for Kubernetes and also supports VMs and is compliant to SMI (via adapter). It can be integrated with self-managed K8s, EKS, GKE, etc. First-class support for Google Cloud (Istio on GKE) |
| Flexibility | Low | High | Istio is extensible & vendor-neutral App Mesh – first-class support for EKS, ECS, Fargate. However, even with Kubernetes on EC2, need to use AWS |
| Ease of setup (with EKS) | Medium | High | Istio – Setting up with EKS requires a learning curve and a deeper understanding of Istio. Click here to see details. App Mesh – With EKS, setting up is easy especially because of AWS support and integration. Click here to see details. |
| Observability | Medium | High | Istio – Tracing by adding request header is available out-of-the-box.Click here to see details. App Mesh – The application code needs to be updated to enable tracing. Click here to see details. |
| Kubernetes support | Low | High | Istio natively integrates with Kubernetes |
| Multi cluster support | High | Yes | App Mesh – https://aws.amazon.com/blogs/containers/leveraging-app-mesh-with-amazon-eks-in-a-multi-account-environment/ Istio – https://istio.io/latest/docs/setup/install/multicluster/. |
| Weighted routing | Yes | Yes | Useful for A/B, Canary deployments, etc. |
| Rate Limiting | No | Yes | App Mesh feature planned in App Mesh Roadmap |
| Fault management | Partial | Yes | Both support timeout, retry circuit breakers. However, Istio also supports variable jitter between retries, health checks, failure injection. App mesh does not allow using custom error codes for retry configuration and only applies default policy. Click here for more details. |
| Traffic Mirroring | No | Yes | Istio allows traffic mirroring currently while App Mesh does not have this feature right now. Click here to read more about Istio Traffic Monitoring. |
| Security – mTLS and Authentication | Yes | Yes | Both support mTLS. However, Istio offers more granular control over mTLS setup including automatic certificate rollover Also, Istio allows request Authentication and has integration available with Auth0, Keycloak, etc. Click here for more details on Istio. App Mesh has IAM integration which is a plus for AWS workloads and setup. |
Conclusion
Each technology selection is contextual – a system under consideration, organizational maturity, architecture maturity, developer skill-set, architecture roadmap, alignment with current organizational technology landscape, security considerations, etc.
Considering above factors, in my perspective below guiding principles help to make the service mesh selection decision:
| AWS App Mesh is more suitable if you: | Istio Service Mesh is more suitable if you: |
|---|---|
| • Are AWS aligned and have no intentions to move to another cloud vendor or support multi-cloud • Are not concerned about granular control and available features meet the requirements • Do not wish to invest much in the operation and installation overhead or do not have the engineering capability available • Do not need elaborate observability and can update applications for request tracing • Have a low number of applications or have the leverage to update applications for some of the concerns not available | • Are aligned with Opensource & Industry standard solution and plan to be more aligned with more transparent and multi-cloud • Need granular control and need flexibility in managing mesh network, policies, configuration, setup, etc. • Are looking for detailed monitoring and observability • Have a large number of existing microservices (with varied tech stacks) and have no possibility of updating all of them for concerns like request tracing • Have engineers with knowledge of Istio and bandwidth to manage and operate the mesh infrastructure and configuration |
References