Microsoft has announced that it will release its own open source service mesh — called Open Service Mesh (OSM) — and transfer it to the Cloud Native Computing Foundation (CNCF) as soon as possible.

This sets the Redmond-based company apart from its cloud rival Google, which recently announced that its own Istio service mesh will no longer be part of the vendor-neutral CNCF and will instead sit under Google’s own Open Usage Commons foundation.

Read next: What is Google’s Open Usage Commons — and why?

The service mesh has quickly become a vital part of the modern cloud native computing stack, as it essentially enables communication, monitoring, and load balancing between disparate parts of today’s microservices-based architecture.

This differs from the popular container orchestration service Kubernetes in its level of granularity. When run in tandem with Kubernetes, a service mesh enables deeper security policy and encryption enforcement and automated load balancing and circuit breaking functionality.

Where Microsoft is looking to set itself apart — aside from the philosophical debate over open source software and governance issues — is in offering as much simplicity as possible.

“What our customers have been telling us is that solutions that are out there today, Istio being a good example, are extremely complex,” Microsoft director of product management for Azure Compute and CNCF board member Gabe Monroy told TechCrunch.

“It’s not just me saying this. We see the data in the [Azure Kubernetes Service] support queue of customers who are trying to use this stuff — and they’re struggling right here. This is just hard technology to use — hard technology to build at scale,” he added.

Until now Microsoft had set itself out as a neutral party in the service mesh battle, offering Azure customers a Service Mesh Interface that supported various options, including popular open source options such as Istio, Linkerd and Consul, as well as Amazon Web Services’ own App Mesh. 

Now, according to Microsoft, OSM is intended to be as lightweight an option as possible. It runs on Kubernetes, and the data plane element is based on the popular Envoy proxy, all configured with service mesh interface APIs. Long story short? “OSM injects an Envoy proxy as a sidecar container next to each instance of an application,” the vendor states.

Source

LEAVE A REPLY

Please enter your comment!
Please enter your name here