Konstantin Emelyanov - Fotolia
Microsoft made an aggressive move against Google with the launch of Open Service Mesh this week, a development that is likely to have significant ripple effects among multi-cloud management tools.
The early-stage open source service mesh project is a reference implementation of the Cloud Native Computing Foundation's (CNCF) Service Mesh Interface (SMI) interoperability standards, and will be donated to the CNCF later in its development, according to a Microsoft blog post.
Service mesh is an architectural approach to microservices networking that uses a network of container proxies, called sidecars, managed by a central control plane. Open source Envoy is already considered the industry standard sidecar, but multiple control plane products and projects, including Google and IBM's Istio, are still vying for dominance.
Experts say Microsoft's move, which quickly follows a recent open source governance controversy about Google's Istio service mesh, is an obvious swipe at Google.
"The timing of this is not an accident, less than a month after Google put Istio into Open Usage Commons," said Tom Petrocelli, analyst at Amalgam Insights. "This really kicks Istio in the chin while it's already on the ground."
Last month, Google donated Istio to an open source organization it created called the Open Usage Commons, which governs open source trademarks, but not their copyright licenses. So far only Google software projects are part of the new organization. Most industry watchers have been critical of Google's choice not to donate Istio to the CNCF, the open source foundation it originally created to govern Kubernetes, saying it leaves Google with too much control over Istio.
Microsoft's Open Service Mesh (OSM) also has the potential to be a significant turning point for both service mesh and multi-cloud management in the industry, depending on how other vendors and contributors respond. So far, Microsoft has not named any other corporate contributors to OSM, but some major enterprise software vendors with Kubernetes container orchestration offerings, such as HPE, have yet to cement their allegiance to a service mesh project, and could add to OSM's momentum.
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.
"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.
Jeremy Pullen CEO, Polodis
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.
"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."