The traditional monolithic application architecture is now outdated thanks to the rise of microservices. Microservices architecture has changed the way applications are built and shipped. Decomposing a single application into several independent containerized services makes application development easier. Developers can design isolated components that can be integrated to form a fully functional application and these components can also be reused in future applications.
Birth of the service mesh
In microservices-based applications, developers were required to add routing logic for interprocess communication inside each service. This worked fine, but complex applications, especially cloud-native ones, need something better. Enter the service mesh. A service mesh is a dedicated infrastructure layer built directly into the application that eases service-to-service communication. A service mesh manages the logic that governs the movement of requests between the various services. How it does this is that it adds an abstraction layer that separates the requests themselves from their origin or destination services. A service mesh uses proxies to help requests travel through a sequence of services to provide the desired functionality, seamlessly. Envoy, developed by Lyft, is one of the most popular open source sidecar proxy services in the Kubernetes ecosystem that is used by various service meshes.
With the help of a service mesh, developers can simply work on their applications without having to care about writing separate code right into the services they build. This helps them focus on their business goals rather than the underlying plumbing. A service mesh also helps in monitoring applications. Service mesh can help track application performance and developers can use that insight to optimize applications while avoiding downtime.
The service mesh market: What are your options?
Istio is arguably one of the most popular service meshes out right now. Based on Envoy Proxy, Istio is an open source solution that is the result of collaboration between Google, IBM, and Lyft. Most vendors in the Kubernetes ecosystem are working on developing solutions based on Istio. But there are a few other service mesh solutions out there that developers who are looking to experiment with microservices can adopt. Here are some of the options worth considering.
1. Linkerd by Buoyant
Linkerd (pronounced Linker-dee), was the first service mesh to ever be developed back in 2016. Linkerd has garnered a lot of fame. Twitter infrastructure engineers William Morgan and Oliver Gould are the co-founders of Buoyant. They developed Linkerd on top of Twitter’s Finagle libraries to help tackle issues that large production systems are exposed to. Written in Scala, Linkerd is easy to install and provides developers with a more transparent view of inter-service communication by separating communication logic from services. Users can monitor the request flow in their applications and fix issues with ease.
Linkerd is language neutral, which means it lets users choose the language they want to develop their application in. Users can easily scale their applications to handle a large number of requests. Many companies including Karma, Paypal, and Ticketmaster use Linkerd for production. Linkerd allows support for various container platforms like Docker, DC/OS, Amazon ECS, and Kubernetes. Support for standalone applications is also provided by Linkerd.
Conduit is another product that was developed by Buoyant as a lightweight alternative to Linkerd. Conduit uses low resource sidecar proxy with Kubernetes clusters to deliver easier deployment and better performance of applications. Conduit helps developers by reducing configurations and resource overhead. But after a seven month run as a separate project, Buoyant merged Conduit with Linkerd 2.0.
Linkerd has witnessed a complete overhaul with its new version 2.0 that was launched in 2018. The biggest news about v2.0 is that Linkerd was adopted by the CNCF, bringing it officially into the Kubernetes stable where it rightly belongs. Linkerd 2.0 is more compact and much faster than its predecessor. With a new service sidecar design, platform owners can build applications incrementally and deploy service mesh functionality on each service separately. This results in more secure and less complex infrastructure.
Linkerd is great at revealing the exact location of failures so that developers can eliminate issues instantaneously. With the new version, developers get a live view of requests which can help identify failures. Linkerd shows graphs of dependencies and various visualizations depicting success rates, latencies among other metrics on instant Grafana dashboards. Linkerd is the most worthy alternative to Istio, and recent updates show that it has a promising future ahead of it.
2. SuperGloo by Solo.io
Solo offers open source products like Gloo functional gateway, Sqoop GrapQl server, and SuperGloo to help enterprises develop cloud native applications with ease. Solo.io’s service mesh orchestration platform, SuperGloo, has become really popular in the last few months and rightly so. SuperGloo offers far more automated and simpler service mesh functionality than its peers. Users who are reluctant to shift to the service mesh approach won’t have a hard time using SuperGloo as it automates installation and relieves developers of the cumbersome task of writing complicated YAML files. Developers can use all the service mesh features through an interactive UI without having to configure them manually.
SuperGloo takes care of both ingress (north-south) traffic and mesh (east-west) traffic and provides users with a unified management experience. Users can choose to pair any service mesh and any ingress of their liking and get a seamless experience as SuperGloo takes care of all the installations and configurations required for any ingress-mesh pair to work. Users have the freedom of migrating to different meshes with the help of SuperGloo’s unified interface. SuperGloo makes it possible for developers to use a single product on any service mesh without having to make any changes.
Solo plans on making SuperGloo a multiservice mesh infrastructure. According to Solo, the future is multimesh, which means users can have the power to use various service meshes based on their applications’ needs. For enterprises using different service meshes, SuperGloo can help “glue” them together without the stress of difficult configuration. In a multicloud world, this vendor-agnostic approach is bound to turn heads.
3. Consul by HashiCorp
The most impressive thing about HashiCorp is that it’s built a comprehensive suite of products that are deeply integrated with each other and solve for a wide range of challenges across the spectrum of cloud-native. While Terraform is the most popular of HashiCorp’s products, Consul is another promising product from the HashiCorp stable. It is an open source tool that helps developers deal with cloud-based infrastructure issues.
Consul is based on agents or clients to manage service to service communication. All the nodes in a cluster run a Consul client that manages a local cache. This cache gets regularly updated from servers. Since no external communication takes place, each service API responds quicker, hence delivering a much faster user experience. Consul is written in Go and is primarily a service registry that provides discovery.
Consul is built on the premise that load balancers are not efficient in a microservices setup. According to HashiCorp, load balancers increase cost, lead to latency, and provide a single point of failure. The solution to that is using a registry that contains the information of all nodes and services in a particular cluster. Services query this registry to connect directly to other services using dynamically updated DNS instead of using load balancers. This feature is known as service discovery, and is core to any service mesh offering available today.
Consul prioritizes authentication of connections among different services rather than encryption. It provides only control plane services. However, it supports Envoy for data plane and sidecar solutions. It also focuses only on mesh traffic. Several ingress traffic vendors offer integration with Consul. For now, Consul Connect is limited to layer 4 support, but layer 7 support is in the pipeline. Consul relies on Envoy for observation features as Consul itself doesn’t have many of those features. Consul clients can provide a health check on services and local nodes. Service discovery uses these health checks to route traffic away from unhealthy services or nodes. Consul also supports multiple data centers. This helps users grow to new regions without having to worry about building additional layers of abstraction.
Service mesh market: What’s ahead?
There are various other vendors in the market that offer service mesh. Envoy service mesh is another option. The popular sidecar proxy vendor used its proxy concept that it shares with various vendors to develop its own service mesh offering that seems quite promising. NGINX is using Istio to develop its own service mesh product. All these alternatives offer features that set them apart from each other. Ultimately, selecting a service mesh vendor boils down to the enterprise requirements. However, this is a new paradigm and developers switching to service mesh need to be prepared to experiment with these options to find the right fit for them. Developers should also try to actively take part in the open source communities to improve service mesh implementation. But, nonetheless, this is the future. It’s safe to say that taking service mesh lightly won’t bode well for enterprises in the future. With the current pace of innovation, the traditional monolithic application infrastructure is sure to become obsolete soon. Adopting service mesh is no longer a trend, it’s a necessity. A healthy sign of this is that Istio is not the only option — there is a robust ecosystem of service mesh tooling available today that can meet different needs.
Featured image: Pixabay
