Microservices are being increasingly adopted by many organizations. In recent years, several design and architectural patterns have evolved to address various challenges associated with them. Service Mesh is one such pattern, and AppMesh is an AWS implementation of the service mesh that address some of the challenges related to interservice communication.
The need for App Mesh
Microservices is an application architecture pattern in which a set of smaller services collaborate together to solve a larger business problem. Microservices evolved as an alternative to address the challenges faced with monolithic architecture, where applications were packaged and delivered as one unit and ran in a single process. On the other hand, each microservice architecture runs as a separate entity. They primarily use simple http verbs and a standard semantics known as RESTful interfaces for the interservice communication. gRPC is another protocol used for low latency, high performance interservice communication.
Microservices are loosely coupled and can scale independently. They are also designed to handle failures with redundancy across data centers to ensure business continuity. This effectively means that not only are many services collaborating to solve a business problem, but there are also multiple instances of them spread across the network.
The traditional way of deploying the microservice is to pack them as part of the operating system image and deploy onto a virtual machine. More recently, docker containers are increasingly becoming popular as default choice for hosting microservices. Microservices are packed as part of a docker image and run as containers. Containers are lightweight as they leverage the docker image’s layered file system and share the host OS kernel. Containers can be confined to runwithin a predefinedCPU and memory limits, making them very resource efficient. A host can have multiple containers running on them. According to a 2018 Cloud Native Computing Foundation survey1, 73% of respondents were using containers in production, with the remaining 27% planning to use them in the future.
Irrespective of the hosting environment, the consumer of the microservices needs away to locate healthy instances. Service registry along with service discovery is the pattern that solves this problem. AWS Application and Network Load Balancer Target groups act as service registry and facilitate access to services through their endpoint. But having a load balancer to also facilitate interservice communication is an unnecessary overhead. Load balancer charges alone can run several thousand dollars and its cost calculation is based on multiple dimensions, such as instance hours, new connections, connection duration, processed bytes and rules evaluation. It makes a compelling case to look for better alternatives.
CloudMap,a recently introduced offering from AWS,acts as service registry and facilitates service lookup with AWS domain name system Route53 or with a simple name using APIs. AWS container orchestration service ECS is well integrated with CloudMap. ECScan register service instances to CloudMap. andcan update health of the service based on the container health checks. CloudMap also tightly integrates with Route53 for DNS based lookups, making the registered services discoverable with DNS queries. While CloudMap solves the problem of service discovery, service mesh addresses the complexity related to interservice communication.
AppMesh, an AWS implementation, is composed of control plane components such as virtual nodes, virtual service and virtual routers. These control plane components abstract service lookup and interservice calls. AppMesh also includes Envoy, a CNCF implementation of service proxy that runs alongside the application container as a sidecar. AppMesh pushes the user-configured rules to Envoy, while Envoy intercepts all traffic to and from the application containers and applies the rules (See Figure 1).