How AWS, Azure and Google approach service mesh technology

AWS

Amazon has perhaps the most application-specific approach to service mesh, with three different options. There's AWS App Mesh, the basic layer to connect and monitor microservices traffic. Then, there's RoboMQ, a third-party platform available via AWS Marketplace, that Amazon describes as an "enterprise service mesh for hybrid cloud integration." And, finally, there's AWS Fargate, which provides a fully abstracted hosting environment for containers. Users can combine all three. However, there's little harmony among these options, and doing so can create unnecessary operational confusion.

Amazon's approach suggests the company plans to build a resource abstraction layer that will envelope all Amazon hosting options, from VMs to serverless. This layer will likely handle connections, deployment and scaling for all resources, and it will look like an extended version of Fargate. In the meantime, Amazon has basic mesh capabilities in App Mesh and RoboMQ.

Google Cloud

Google may also be in the throes of an effort to redefine its cloud offerings. Its basic service mesh technology is provided through the integration of Kubernetes and Istio, an open source service mesh Google helped develop, but is also available independent of its cloud services. Last year, Google began to position the Kubernetes-Istio pairing as a central piece to a hybrid cloud strategy that links Google Kubernetes Engine with users' private data centers. Google also has Google App Engine, which is its full-blown framework for microservices and containers.

Google's service mesh approach is firmly grounded in Istio, which works across all public clouds and on premises. By linking Istio with Kubernetes, another open source tool, Google has created a portable service mesh and orchestration model rather than one exclusive to its cloud. In contrast, App Engine is a cloud-specific, as-a-service framework for microservices, one where the service mesh is embedded and hidden. As the Kubernetes-Istio model is still new compared to App Engine, users could benefit from some more thorough documentation on that service mesh approach.

Microsoft Azure

Microsoft may have the most straightforward approach to service mesh. Azure Service Fabric is Microsoft's microservices framework, designed from the ground up to work on its public cloud, on premises and in hybrid and multi-cloud architectures. The recently added Service Fabric Mesh is a PaaS service mesh technology that has fully virtualized application resources, which means it handles deployment, resilience and autoscaling -- much as serverless would.

Microsoft's service mesh approach is tuned to hybrid cloud, which has been its greatest strength in the public cloud market. Service Fabric Mesh is designed to provide the same abstract hosting features that can be found on other cloud platforms but without any disruption to the overall Azure service mesh approach. The downside is that it's a proprietary model, and non-Microsoft users are likely to want something more agnostic.

Find the right service mesh technology

In addition to knowing what each cloud provider offers, organizations also need to understand which of these service mesh approaches best meets their needs.

Let's start with serverless-like iterations that need to fully manage application deployment, connectivity and lifecycles. These types of service mesh offerings -- such as Fargate or App Engine -- are difficult to deploy across public cloud boundaries, or even across the public cloud and on-premises data centers, unless developers organize groups of microservices to stay within a single hosting environment.

Some users only want service mesh connectivity and load balancing for their microservices. Here, Microsoft users will want to consider Azure Service Fabric. It supports deployment on other public clouds, which makes it the top service mesh for multi-cloud. Also consider Google's Kubernetes Engine and Istio, particularly if you're a Kubernetes shop. Amazon's basic service mesh tools are great for AWS users, but less versatile in multi- and hybrid cloud deployments.

The middle ground, where most users will probably find themselves, is a bit more difficult to read at this point. Microsoft and Google have signaled they'll support a fairly portable service mesh vision via Azure Service Fabric and Google's Kubernetes-Istio combination, respectively. Amazon's middle ground is still divided and somewhat primitive compared to its competitors, which likely means more upgrades are on the way.

In the long run, service mesh, managed container services and even serverless are likely to converge into a single uniform resource model for applications. Even when that happens, though, individual cloud providers have little to gain by letting their approaches cross over into competitive clouds. The more diverse your cloud provider choices are and the more elastic you want your resources to be, the more you'll need that middle-ground approach for your services.