See all the things a service mesh can do

Service mesh adoption continues to grow, and some organizations are still trying to fully understand what a service mesh can and cannot do.

They may not realize that a service mesh is not just another single-purpose tool, but rather a tool that can address a variety of networking needs. A service mesh may actually help consolidate multiple existing tools to help reduce management effort and costs.

Take a look at these two multi-cloud network architectures.

Automating and offloading network services and security-related functions to a cloud-agnostic service mesh can help simplify management in multi-cloud environments.

Multi-cloud architecture using cloud vendor-specific network solutions:

Using a cloud-agnostic service mesh:

Many service mesh products include service discovery, zero-trust networking, and load balancing capabilities, while others go further to provide multi-cloud/multi-runtime connectivity, network automation, and north-south traffic control. Let’s look at the capabilities of a cloud-agnostic service mesh and its potential to consolidate existing tools across environments to help reduce management effort and expense.

Service Discovery

Service discovery allows developers to catalog and track the network location and health of all registered services on their network. It is an important capability in a dynamic environment where services are constantly added and removed. It is often the first step in serving a grid application.

There are many ways to get service discovery capabilities. But the common capabilities built into service discovery tools such as Kubernetes, Amazon EKS, Azure AKS, Google GKE, or AWS Cloud Map and Configuration Management Database (CMDB) are usually specific to the platform or cloud they run on. The scope of services they can discover is limited to the boundaries of their specific platform or cloud. However, today, most organizations run applications across multiple platforms or cloud environments, which means there are multiple service discovery solutions to learn, install, and manage.

A better approach is a cloud-agnostic service mesh that can span multiple runtimes. For example, HashiCorp Consor is an agnostic service mesh that includes support for Kubernetes, virtual machines, Amazon ECS, and HashiCorp Nomad, allowing organizations to centralize global service discovery across multiple heterogeneous environments.

By incorporating service discovery into a service mesh, platform teams can provide service discovery as a global shared service, reducing costs, improving compliance, and simplifying management compared to relying on individual teams to run and manage their own service discovery tools without any oversight.

Zero Trust Network

Organizations are increasingly looking to Zero Trust Networking to protect their networks and infrastructure rather than relying solely on traditional approaches to secure the network perimeter.

Unlike the traditional castle and moat security approach, which relies on protecting the perimeter which may not exist in modern cloud-based environments, zero trust security believes that no service access should be granted until it is authorized and authenticated, whether inside or outside the perimeter, and that all communications are encrypted.

Applying zero-trust network principles of authentication, authorization, and encryption is a primary service mesh capability. A service mesh automatically redirects inbound and outbound traffic between services through a proxy, usually a proxy. This allows authorization, authentication, and encryption responsibilities to be moved to the proxy.

A service mesh uses service identity rather than IP address as the unit for allowing or denying authorization, greatly simplifying the management of service-to-service communication.

Administrators can configure a single deny all policy that will be enforced by the proxy to block all service-to-service communication. Developers can add more granular policies to authorize specific services to communicate as needed.

The service mesh proxy will also ensure that all service-to-service communications are automatically authenticated and encrypted. Before any service communication, the proxy ensures that TLS certificates are exchanged and all traffic on the network is encrypted. This results in a more secure network that prevents lateral movement between services even after a network outage occurs.

Finally, service mesh essentially helps organizations shift left by providing administrators and developers with the ability to authorize, authenticate, and encrypt their network services early in the development cycle. By shifting left, organizations can reduce the risk of last-minute delays due to unforeseen security vulnerabilities before going into production. Additionally, shifting left with a service mesh allows network administrators to focus on securing the network perimeter rather than managing individual IP addresses.

A service mesh is a force multiplier for network administrators and an abstraction layer that allows developers to focus on their applications, not security logic, and avoid the heavy lifting of managing and rotating certificates and keys.

Load Balancing

Because data traffic on a service mesh flows through proxies, the service mesh can also control features such as traffic shaping. A simple example is load balancing between multiple instances of a service. A service mesh allows custom traffic patterns to be distributed directly between instances, rather than taking additional network hops through separate load balancing devices. A service mesh can dynamically adjust traffic distribution even as instances scale up or down. Using a service mesh can greatly reduce the cost and complexity of managing multiple different load balancing devices across multiple different environments and clouds.

and:

Multi-cloud connectivity

Many organizations have different teams and services spread across different networks and regions in a given cloud. Many companies also have services deployed across multiple cloud environments. Securely connecting these services across different cloud networks is a highly desirable capability that often requires significant effort from network teams. Additionally, the limitation of requiring non-overlapping Classless Inter-Domain Routing (CIDR) ranges between subnets can prevent network connectivity between virtual private clouds (VPCs) and virtual networks (VNETs). Service mesh products can securely connect services running on different cloud networks.

For example, HashiCorp-consu supports a multi-datacenter topology that uses a mesh gateway to establish secure connections between multiple Consul deployments in different networks running across clouds. Team A can deploy a Consul cluster on EKS. Team B can deploy a separate Consul cluster on AKS. Team C can deploy a Consul cluster on virtual machines in a private internal datacenter. A multi-datacenter configuration can be established between three Consul clusters, allowing services running between EKS, AKS, and virtual machines to connect securely without the need for additional network configuration such as VPN, Direct Connect, or ExpressRoutes. The Consul mesh gateway allows multiple Consul deployments to be clustered even if the IP ranges overlap across networks.

automation

Automation is especially beneficial in dynamic environments. Fluctuating demand requires operators to scale the number of service instances, a fairly simple task. However, network firewalls, load balancers, or other network infrastructure may need to be updated so that the new instances can be accessed. Similarly, new application services may require updates to network equipment before clients can access them.

Since most organizations have separate network and security teams, these workflows often involve manually requesting updates for network equipment, which can take hours or even days to complete. Downsizing or decommissioning a service can cause even more concern. This is because requests from network teams to remove IP addresses from network equipment can easily be ignored, leading to potential security breaches.

To address these challenges, some service meshes have built unique integrations with infrastructure configuration tools such as HashiCorp Terraform. Consul has a unique integration with Terraform that can automatically trigger updates and reconfigurations of network devices. Operators can configure Consul Terraform Sync (CTS) to automatically update devices such as firewalls and load balancers based on changes to services in the Consul catalog. The automation of these tasks reduces reliance on manual systems, improves workflow efficiency, and strengthens the security posture of an organization.

North-South Traffic Control

In addition to shaping and routing traffic between services within an organization's network, you also need to provide access to those services from external clients. For organizations that don't plan to expand beyond a single cloud, cloud-native options such as AWS API Gateway, Azure API Management, and Google Cloud API Gateway may be good choices. However, for organizations that run on multiple clouds, there is value in standardizing on a single common platform.

Some agnostic service meshes, including Consul, have built-in API gateways that can provide similar functionality to cloud-native options. This allows organizations to use a consistent management plane to manage traffic within the service mesh (east-west) and traffic from external clients (north-south), eliminating the need to deploy multiple different API gateways across different environments.

Who Benefits from Service Mesh Tooling Integration?

If a service mesh can help consolidate many different tools across different runtimes, should every organization incorporate a service mesh into their infrastructure? That depends.

For the 86% of organizations that are already in or planning to be in multiple clouds, service mesh can certainly help curb tool sprawl.

Even organizations that focus on a single cloud provider may have to deal with different runtimes chosen by different development teams. Standardizing on a service mesh to provide global service discovery, zero-trust networking, and load balancing can also help these organizations reduce tool sprawl. An agnostic service mesh like Consul can provide further tool integration with built-in capabilities to connect services between clouds, automate network device updates, and control access to external client services.

While some smaller organizations may not see significant consolidation of tools, at the very least, they can still benefit by adopting a service mesh as a force multiplier to improve their overall security posture without imposing additional effort on developers, platform engineers, or network engineers.