From microservices to service mesh: the new era of TARS
Isabella Ferreira
Published at 12/17/2020
Views 2242

The term microservices was introduced in 2005 by Peter Rodgers during a presentation in the Web Services Edge conference. The popularity of microservices is on the rise because it can solve many challenges such as high scalability and high performance. However, as the operational complexity of microservices grows, developers may need to choose a microservices framework that has specific requirements, such as load balancing and scaling, service discovery, and monitoring.

The aforementioned requirements, also called service governance, are not provided by all microservices frameworks and even if it is provided, it might be very hard for companies to enforce service governance if the framework does not support development with multiple programming languages. This is because microservices are built independently by small teams that have the flexibility to choose their own tools and coding languages. TARS, a microservices framework created in 2008 by Tencent, is a framework that currently supports both service governance and multiple programming languages.

After having all services independently developed, service-to-service communication is what makes microservices possible. The problem is that as the application grows, communication gets more and more complex. Thus, even if the communication logic can be coded into each service, it will get chaotic at some point.

To address the communication problem, service mesh was created in 2016. A service mesh is a software infrastructure layer for controlling and monitoring service-to-service communication in microservices applications [17]. The rise of service mesh is tied to the rise of cloud applications. In the cloud native world, an application might consist of hundreds of services, each service might have thousands of instances, and each of those instances might have constantly-changing states as they are dynamically scheduled by an orchestrator (such as Kubernetes). Thus, managing service-to-service communication is vital to ensure performance, reliability, and security. Based on that, service mesh comes into such scenarios and abstracts away all the communication complexities without the need to make any changes to the application.

But, what is the difference between microservices and service mesh?

Microservices have many advantages. It allows developers to make changes to applications' services without the need to redeploy the entire application. It also allows small teams to work on each service independently and it provides them the flexibility to choose their own tools and/or programming languages. Despite the microservices advantages, handling the service communication in microservices is challenging. Most of the time, microservices depend upon third-party libraries or components to provide functionalities such as service discovery, load balancing, etc. TARS already provides support to those types of functionalities. However, these components need to be configured inside the application code and based on the used programming language, the implementation will vary. When those external libraries are upgraded, the application also needs to be updated. Consequently, this increases the application complexity, since developers also need to be aware of those external libraries and troubleshoot issues that may arise when implementing or upgrading them.

Service mesh: The solution of the problem

Service mesh is a way to control how different parts of an application share data with one another [5]. Thus, service mesh has a dedicated infrastructure layer built into the app that decouples this complexity from your application and instead, uses a service proxy and lets it handle the complexity for you. This makes it easier to optimize communication and avoid downtime as the application grows. Service mesh provides a bunch of functionalities such as traffic management, service discovery, authentication, monitoring, and security. With service mesh, we push the network functions down into the infrastructure with minimal overhead and high decentralization with the ability to control, configure, and monitor applications [10]. Hence, the application only contains the implementation of business functionalities, while the service mesh handles the communication.

The sidecar design pattern to implement service mesh

The sidecar design pattern consists of deploying a proxy alongside the services in order to implement service mesh. The sidecars abstract the complexity away from the application and handle functionalities like service discovery and load balancing. As you can see in the image below, the service mesh layer connects to a sidecar container that runs alongside the application. Multiple copies of the same sidecar are attached to each microservice.

The sidecar design pattern. Image extracted from [11].

When should you use TARS and service mesh?

The TARS framework has been around for 12 years, and it allows service governance capability and supports multiple programming languages. TARS' service governance not only involves the commonly needed functions such as service registration, discovery, load balance, and fault tolerance, but also provides special governance capabilities to face massive access and system overload. Furthermore, TARS currently supports C++, Golang, Java, Node.js, PHP.

On the other hand, service mesh is still in the early stages of development [9]. Service mesh is a very promising technology, since it uniformly controls the communication traffic across multiple services, and a series of service mesh frameworks through Istio - a service mesh framework - can support service governance [7]. Additionally, by using the sidecar model, Istio can support multiple programming languages [8].

Although TARS has many advantages such as its high performance [12], TARS is a very heavy framework if compared to service mesh. Additionally, TARS might be over complex for beginners. On the other hand, service mesh is easier to understand and probably easier to use. Not having to change the application’s source code makes it definitely easier for development, troubleshooting, and maintenance.

Hence, if you are looking for a more robust microservice architecture with high performance, service governance, and that supports multiple programming languages, then TARS is your best option! If you are looking for a new technology that it is easier to use and to understand but that might not achieve the same performance, then service mesh frameworks are your best shot.

Service mesh in the roadmap of TARS

After 12 years of existence, TARS is looking to upgrade further and hoping to create more convenience as a microservices framework. The TARS team is currently looking to incorporate the service mesh in their framework in order to make it easier and more accessible to developers. Hence, TARS + service mesh together would allow developers to have an easier to use and more lightweight framework with high performance.

About the author:
Isabella Ferreira is an Advocate at TARS Foundation, a cloud-native open-source microservice foundation under the Linux Foundation.