Microsoft unveils Open Service Mesh, vows donation to CNCF

Open Service Mesh sets the stage for shifting alliances

An IBM spokesperson did not respond to requests for comment about whether the company will support Open Service Mesh, but the company, an Istio co-creator, has been vocal about its disappointment that Google has refused to donate Istio to the CNCF. If that disappointment is strong enough for IBM to defect to OSM, it would put significant momentum behind Microsoft's project as a potential industry standard.

"Don't take your eyes off VMware, either," Petrocelli said. So far, VMware has supported Istio in its Tanzu Kubernetes platform. "Red Hat and IBM have much more invested in Istio, but VMware, Rancher/SUSE and HPE could change [course] much more easily."

The service mesh market is already fragmented among multiple projects that also include existing CNCF properties Linkerd and Kuma, as well as the open core HashiCorp Consul Connect. There's also the possibility that Microsoft OSM could cause it to fracture further, with IBM, Red Hat and Google behind Istio and other major vendors joining Microsoft in OSM. (Microsoft and HashiCorp also recently inked a partnership to offer Consul Connect as an Azure public cloud service, and Microsoft reps said that deal will not be affected by OSM.)

So far, Red Hat officials are sticking with Istio, though they view Open Service Mesh as a positive move for the industry.

"We welcome the entry of Open Service Mesh into the open source community and are very interested in seeing where the project goes from here," said Brian Harrington, principal product manager of OpenShift Service Mesh at Red Hat, in an emailed statement through a spokesperson. "There are many opportunities within a diverse and growing set of open source service meshes and, like all true open source projects, these technologies will evolve to meet the best outcome for their end users."

For Red Hat, however, there is no directional change, Harrington emphasized.

"Envoy continues to play a critical role as a foundation for OpenShift Service Mesh and we are still invested in Istio," he said. "[This] announcement affirms that other organizations recognize the same key components in building a stable service mesh."

Whether Open Service Mesh becomes a standard among major vendors or not, it's likely to have a significant effect on how the service mesh market will look once mainstream enterprises are ready to use cloud-native technology in production, which is still a few years away, industry experts say. 

Jeremy Pullen

"The [enterprise] customers I've worked with over the last couple years were relatively late adopters, and service mesh isn't on a lot of their radars," said Jeremy Pullen, CEO of Polodis, a digital transformation consulting firm in Atlanta. "Most of them don't care so much about open source governance, but what they care about is compatibility [between systems]."

Open Service Mesh has the potential to offer standardized interoperability between public and private cloud networks, which will be of interest to enterprises as they mature in cloud computing and use of cloud-native infrastructure, Pullen said.

Open Service Mesh focuses on interoperability

Open Service Mesh builds on SMI, which is expressly not a service mesh implementation, but rather a set of standard API specifications designed within CNCF. If followed, the specs allow service mesh interoperability across multiple types of networks, including other service meshes, and public, private and hybrid clouds.

The [enterprise] customers I've worked with over the last couple years were relatively late adopters, and service mesh isn't on a lot of their radars. Most of them don't care so much about open source governance, but what they care about is compatibility [between systems].

The service mesh layer will be a key component of broadly accessible, real-world multi-cloud container portability as mainstream enterprise cloud-native applications advance, Pullen said.

"Service mesh should help that, theoretically, especially if there's standardization of it, but it's going to require an interesting rework to make any Docker container compatible with any container cluster," he said. "It's more than putting something in Docker, it's about that ability to route services in a somewhat decoupled way."

Simplicity and ease of use were also a point of emphasis in Microsoft's OSM rollout, which analysts said seemed to target another common complaint about operational complexity among early adopters of Istio. OSM, by contrast, will build in some services that have been complex for service mesh early adopters to set up themselves, such as mutual TLS authentication.

Microsoft also used what it calls a "no cliffs" design philosophy in building Open Service Mesh, meaning that if a user needs to do something more advanced than what the SMI APIs offer, such as the circuit breaking technique for stopping traffic flow to a faulty endpoint, they can default to the raw Envoy APIs instead. This approach makes OSM more flexible and extensible as service mesh architectures evolve, Microsoft claims.

Brad Casemore

"Istio has struggled with complexity for some time, and it has also had trouble accommodating some extensibility concerns of customers," said Brad Casemore, an analyst at IDC. "Of the two issues, though, simplicity of operation was cited as the most acute area requiring improvement by enterprises."

Istio tried to address this with a move from a distributed microservices architecture to a monolith for its control plane with its version 1.5 release, but "even then, work remained to be done," Casemore said.

Casemore echoed Pullen's comments about the importance of simplicity and extensibility in appealing to the enterprise mainstream.

"[That] requires a much greater degree of operational simplicity," Casemore said. "Microsoft, given its history and lengthy experience working with enterprise customers, likely believes it is culturally well placed to crack that particular nut."