Best Tools to Manage Microservices

Microservices can be seen as a process of developing software systems that emphasize on structuring solo function modules with precise actions and interfaces. Being one of the pillars of IoT, they are growing to become the standard architecture. The microservice architecture ensures continuous placement/transport of intricate applications, allowing establishments to advance their tech infrastructure.

As more organizations migrate from monoliths to microservices, they encounter new challenges connected with the way distributed systems are organized. Having hundreds of microservices, you end up with a spider web of connections and concerns about organizing these connections effectively.

There are a number of tools helping engineers to design the microservices architecture and deploy it, Kubernetes (K8s) being probably one of the most popular of them.

However, even when you manage the installation of all components, there remain questions of maintenance, eventual upgrades or changing them. Management is a burden that requires request routing, service observability, rate limiting (incoming and outgoing), authentication, failure management and fault injection, circuit breakers, rolling upgrades, and telemetry.

Service mesh

To manage deployed services, special communicators are used that are called service meshes. A service mesh is a configurable, low-latency infrastructure layer. It is designed to handle a high volume of network-based interprocess communication among application infrastructure services using APIs. A service mesh ensures that such communication is fast, reliable, and secure by providing critical capabilities such as service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and support for the circuit breaker pattern.

A service mesh is a networking model that is somewhat analogous to TCP/IP but at a higher layer of abstraction. Like TCP, the service mesh abstracts the mechanics of delivering requests between services and it doesn’t care about the actual payload or how it’s encoded. Its goal is to provide a uniform, application-wide point for introducing visibility and control into the application runtime.

In practice, the service mesh is usually implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

As a service mesh grows in size and complexity, it can become harder to understand and manage. Different companies try to come up with service mesh solutions that would ensure effective management of microservices. The best solutions, in our opinion, are

• Istio,
• Linkerd (merged with Conduit), and
• Consul (Connect).

Istio

Istio is an open source service mesh launched in 2017 by Google, IBM, and Lyft that is designed to connect, secure, and monitor microservices. It has two planes, a control plane and data plane. The data plane is composed of a set of intelligent Envoy proxies, deployed as sidecars, which prevents communication between microservices from altering the application code. Envoy proxies provide dynamic service discovery, load balancing, TLS termination, HTTP/2 and gRPC proxies, circuit breakers, health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics. The control plane manages and configures the proxies to route traffic. It comprises three components:

• Pilot, the core component used for traffic management that configures all Envoy proxy instances;
• Mixer, a platform-independent component that enforces access control and usage policies across the service mesh and collects and analyzes telemetry reports; and
• Citadel, the Certificate Authority and Policy enforcer.

Istio layers transparently onto existing distributed applications. Moreover, it is also a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system.

Istio benefits:

• rich features, including automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic;
• fine-grained control of traffic behaviour with extensive routing rules, retries, failovers, and fault injection;
• pluggable policy layer and configuration API that supports access controls, rate limits, and quotas;
• automatic metrics, logs, and traces of all traffic within a cluster;
• strong identity-based authentication and authorization policies;
• secure service-to-service communication.

Linkerd

Linkerd is a fully open-source service mesh for Kubernetes and other frameworks developed as a Cloud Native Computing Foundation project in the Linkerd GitHub organization. In 2018 it merged with Conduit to form Linkerd 2.0, growing from a cluster-wide service mesh to a composable service sidecar. It can do end-to-end encryption and automatic proxy injection but lacks complex routing and tracing capabilities.

Architecturally, Linkerd has the control plane and the data plane. The control plane is a set of services that run in a dedicated namespace. Within the control plane, the Controller consists of multiple containers (including public-api, proxy-api, destination, tap) that provide most functionalities: aggregate telemetry data, provide a user-facing API, provide control data to the data plane proxies, etc. Linkerd uses Prometheus, to expose and store metrics, whilst the Grafana dashboard renders and displays dashboards that can be reached from the Linkerd dashboard. The data plane consists of ultralight transparent proxies running next to each service instance. Because they’re transparent, these proxies act as out-of-process network stacks, sending telemetry to, and receiving control signals from the control plane. With this design, Linkerd measures and manipulates traffic to and from your service without introducing excessive latency.

Linkerd benefits:

• a lightweight service mesh that can be placed on top of any existing platform;
• simple installation and CLI tools and doesn’t require a platform admin to be used;
• easy services running with runtime debugging, observability, reliability, and security
• Linkerd doesn’t offer a rich array of features, but it is an easy service mesh that can be ideal for organizations that aren’t operating vast amounts of microservices.

Consul Connect

Consul Connect, launched by HashiCorp in July, 2018, is an extension of Consul, a highly available and distributed service discovery and KV store. It adds service mesh capabilities and provides secure service-to-service communication with automatic TLS encryption and identity-based authorization. It emphasises service discovery and service identity management. Similarly to Istio and Linkerd, it uses the Envoy proxy and the sidecar pattern.

As an extension of Consul, Consul Connect synchronizes Kubernetes and Consul services. It also offers integrations with Vault for certificate and secret management, further extending the service discovery provided by Consul.

Consul Connect uses mutual TLS to automatically encrypt communications between containers. The cluster consists of multiple EC2 instances, each running a Consul agent which is connected to a central Consul server which tracks what tasks are running in the cluster, and their location.

Each such task is made up of an application container, and a Consul Connect sidecar container. On startup, the Consul Connect sidecar registers the application container’s IP address into Consul via the Consul agent. The Consul Connect sidecar can also be configured to provide a local proxy that serves as a secure network channel to another application container.

The data plane for Consul and, by extension, for Consul Connect, is pluggable. It includes a built-in proxy with a larger performance trade off for ease of use and optionally third party proxies such as Envoy. The ability to use the right proxy for the job allows flexible heterogeneous deployments where different proxies may be more correct for the applications they’re proxying.

Consul Connect benefits:

• unique capabilities when implementing multi-cluster workloads or when working with a heterogeneous infrastructure;
• connections via gateways to enable connections between services in each datacenter without externally routable IPs at the service level;
• intention replications;
• security policy implementation between different clusters to ensure the persistence of the security model.

As you can see, Istio, Linkerd, and Consul Connect have their benefits that may or may not match your technology stack’s requirements.

In brief, Istio is the most advanced service mesh available, but it is at the same time more complex and difficult to manage.

Linkerd is easier but less flexible, so it is mostly suitable for smaller projects that require satisfactory performance with less effort.

Consul Connect offers integrations with other HashiCorp solutions, Consul and Vault.

At present, the task remains tough with many organizations starting the journey but encountering multiple issues on the way. Many settle with a mix of monolith and microservices as a workaround, but future growth of microservices as part of the IoT ecosystems is likely to push them to full transfer — requiring new friendlier tools for deployment and management. Therefore, we’ll soon see more solutions that would be able to address specific problems or will offer easier ways to manage microservices.