Simplifying Enterprise Service Mesh Operations

Service meshes were supposed to be the answer to one of microservices’ longest-standing questions: how do I get my services to talk to each other securely? When tools like Istio arrived, they brought with them the hope of traffic management, service identity, encryption, and observability. For many teams, however, they also brought operational complexity. How do you run service mesh across dozens of services, and often across multiple Kubernetes clusters? How do you manage all the configs, security policies, upgrades, and monitoring?

Enter Solo.io and its Gloo Mesh product that’s built to help you adopt and run a service mesh, especially in larger-scale environments with lots of clusters. An important point to note is that the goal here isn’t to get Istio up and running; it’s to make service mesh operations manageable at scale.

Operational reality

Now, while microservices make it possible to build services independently, in practice, however, that means adding complexity to a platform that, let’s face it, is already pretty complicated. Additionally, each of those services needs to communicate with other services over a network, which needs to be reliable, observable, and secure. If you don’t have a standard way of dealing with communication, you’ll end up implementing retries, timeouts, and security checks independently in application code.

The good news here is that that’s exactly what service meshes were built for: to shift that complexity into the infrastructure layer, instead of having to write it into application code. As opposed to every service being responsible for its own networking, the mesh provides those capabilities automatically via sidecar proxies and centralized control planes. And while it does make your platform more reliable and more secure, someone still needs to manage the mesh.

Service mesh management

In the Kubernetes ecosystem, Istio is easily one of the most popular service mesh technologies. An open-source service mesh that provides all the features you need, from traffic shaping and mTLS, through to policy and telemetry. Running Istio in production, however, can be tricky. Platform teams must handle configuration updates, upgrades between versions, and operational policies that affect every service in the mesh.

Solo.io’s approach is all about making it easier to run an Istio mesh in your production environment, without losing any of its capabilities. By providing a simple way to manage configurations and policies, Gloo Mesh makes it easier to control how a mesh runs across multiple clusters. This helps maintain consistency in how services communicate, regardless of where those services run.

With Gloo Mesh, you can define your policies in one place and then apply them to as many clusters as you like. That keeps all your services talking to each other consistently, across clusters. For companies running large platforms, this sort of control becomes essential to maintaining operational reliability.

Improved observability

The biggest benefit of Service mesh technology is the increased observability of inter-service communication. With traditional microservice architecture, it can be challenging to monitor, trace, and debug inter-service communication issues. Failures can occur across multiple services, and you would typically have to go dig around and piece together application logs and metrics to understand the root cause.

With a service mesh, it’s a lot easier because you have all of the telemetry data available at the proxy layer. You can look at metrics, traces, and traffic patterns without having to change the code in your applications. Solo’s tools take this a step further and provide a way for you to aggregate the telemetry data across clusters and visualize it for the platform team. This gives the platform team a way to see what is going on between all of the different services that make up the platform, and to even spot problems before the users see them. This is particularly important if there are hundreds of services running on the platform. 

Multi-cluster environments

With multiple clusters and multiple environments, maintaining consistent traffic and security policies is often considered one of the biggest operational challenges. In a small environment, you can manage this by setting up routing rules, retries, timeouts, and access control policies at the cluster level. At an enterprise scale, however, this will not work. A policy that has been applied in one cluster may not exist in another, and this can lead to availability or security problems.

Solo’s tools provide a way to manage policies at the mesh level. Using tools like Gloo Mesh, platform teams can apply policies across multiple clusters. Policies can be applied once and rolled out consistently across the different clusters in your environment. That way, you don’t need to have every single microservice developer manage their own configurations themselves, and you can avoid configuration drift. You can apply policies related to retries, failover, and access control in one place and have them apply everywhere. 

The future of service mesh technology

In conclusion, one of the reasons service mesh adoption has been slow is because of the complexity of running a service mesh. The tools Solo develops are designed to reduce this complexity and make it easier to deploy and manage a service mesh in a Kubernetes environment. They provide platform teams with centralized control over their service mesh, better visibility into what is going on in their environment, and a way to manage their security policies at the mesh level. They enable platform teams to treat the service mesh as infrastructure, as opposed to just another operational burden. 

As the scale of microservices environments continues to increase exponentially, finding ways to manage their service meshes consistently across multiple clusters is going to be critical for platform teams.