Selecting a service mesh implementation for managing microservices

Abstract: Microservice architectures are the base of modern cloud applications. With the adoption of microservices, application teams manage to reduce codebase complexity and write more modular services that can run inter-dependently. Despite all the advantages offered by microservices over monolithic architectures, they introduce additional complexities, such as handling inter-service communication, ensuring security, introducing traceability, and achieving acceptable performance. To manage all these microservices, the orchestrator tool Kubernetes has shown promising results, but it is not sufficient to tackle all the cross-cutting concerns of the applications. With more complex architectures, it becomes difficult to troubleshoot and trace inter-service application programming interface calls. For this purpose, the service mesh technology emerged and is being introduced in many companies. There are different implementations available for service mesh, with some being more compatible with specific cloud providers than others. The selection of an adequate service mesh shapes the entire application deployment process. If chosen wrongly, it might introduce further complexities or performance losses. This thesis investigates ways to make this decision more efficiently. It takes into account the company’s needs of service mesh and compares implementations to meet performance expectations with minimal deployment efforts. Specially, we perform different testing scenarios to compare AWS cloud specific, AWS App Mesh with most widely used, Istio service mesh. The outcome suggests that AWS App Mesh performs consistently for all cases with acceptable latency ranges, but, Istio outperforms AWS App Mesh under standard conditions, such as high but manageable request load on the application. In addition, Istio can achieve the same deployment with less lines of code as compared to that of AWS App Mesh. On the other hand, resource utilization by these service meshes is found to be a non-conclusive factor for selecting the service mesh implementation. With these outcomes, application teams can make more well-informed decisions to run the production-grade workloads with an efficient service mesh implementation.