Interview Microsoft has donated new open-source project the Open Service Mesh (OSM), described as a “lightweight and extensible service mesh that runs on Kubernetes,” to the Cloud Native Computing Foundation (CNCF).
The first thing that comes to mind when thinking about a service mesh for Kubernetes is Istio, recently in the news for Google’s failure to donate it to the CNCF, choosing instead to donate the trademark to the newly created (by Google) Open Usage Commons. Istio is the most commonly used, though there are other options, such as Linkerd – which is hosted by CNCF, and preferred by some for its performance and small size, although it lacks all the features of Istio.
Linkerd implements the Service Mesh Interface, introduced in May 2019 by vendors also including Microsoft and Hashicorp, in the hope of creating a standard interface for service meshes on Kubernetes. Istio does not implement SMI though there is an adapter. SMI is also hosted by CNCF.
Now Microsoft has come up with the OSM which is a new implementation of SMI. Similar to Linkerd, OSM is presented as a “lightweight and extensible service mesh that runs on Kubernetes,” but one key difference is that OSM uses Envoy for its proxy and communication bus, whereas Linkerd uses linkerd2-proxy, saying that this enables Linkerd to be “significantly smaller and faster than Envoy-based service meshes.” Istio also uses Envoy.
Gabe Monroy, Director of product for the Microsoft Azure Application Platform spoke to us about the new project.
Commons cause: IBM, Oracle, CNCF protest over Google’s handling of Istio governance
Why another service mesh? “There’s really two key differentiators,” said Monroy.
“The first is that OSM is designed to be a reference implementation for SMI. If you buy into the idea of portability between service mesh implementations and the feature set SMI offers, you will get a great experience with OSM.
“And second, where SMI doesn’t fit your needs and you need to do something advanced, let’s say circuit breaking, you can bail out to the raw Envoy xDS APIs in a safe way. The combination is hitting the sweet spot for our customers, who tend to be overwhelmed by the feature set that they find in other service meshes.”
Why not just use Linkerd? “We heard a lot of interest in consolidating around Envoy. That is not present in Linkerd. That has advantages, performance is great, but a lot of the ecosystem is rallying behind Envoy.”
What does Microsoft itself use, in its growing use of Kubernetes? “We don’t share details of what we implement internally. I will say though that there is a variety of different implementations that we have to contend with, which is part of the justification for SMI. It gives us the ability to have a common set of APIs.”
How does OSM compare to Istio, which is something of an industry standard, we asked?
“The key difference is that OSM is much lighter weight. A lot of AKS (Azure Kubernetes Service) customers are trying to use Istio and having a hard time, we see this from the support ticket volume. The design philosophy of Istio is trying to take the entirety of the Envoy ecosystem and have those APIs inside the Istio API surface.
“That is a burden for developers to learn, when most people are largely interested in three things. NTLS, the secure communication between services. Intelligent routing. And automatic metrics between services, latency, error rate. You don’t need all of Istio to do what customers are asking for. In fact, sometimes clusters fail as a result of all the complexity.”
Monroy said that calling OSM lightweight is not meant to imply that it lacks capability. “It is about being well engineered. It’s an intentional choice about which APIs you surface,” he said.
We want OSM to be simple to understand. That comes at a price, and that price is accessibility to advanced features
“We want OSM to be simple to understand. That comes at a price, and that price is accessibility to advanced features. We enable those advanced features by creating a bail-out to the raw Envoy APIs, not by adding more to the API surface.”
How close is the OSM to being ready to use? “Today this is an open source project, it is early days. Our goal is to develop a community around it, to help harden it and get it ready for production. It has been in development for some time inside Microsoft. The main SMI APIs all work. I’m hopeful that the people out there who are building their own Envoy-based service mesh control planes, and there are a number of them, will find OSM interesting.”
Monroy says that Microsoft has not lined up partners for the launch. “We wanted to release the project early. To be collaborative, we can’t take a fully baked piece of software and drop it on everyone. We want to take feedback.”
The donation to CNCF seems also like a riposted to Google’s refusal to do this with Istio, what is Monroy’s view on the subject? “A lot of the drama around open governance is doing a disservice to customers, who are focused on whether the technology works.
“On the broader topic of open governance, I am quite happy with the CNCF and the Linux Foundation and what they have been doing in the cloud native ecosystem. It’s hard to think of another foundation where you have the likes of Microsoft, Amazon, Google, Alibaba, coming together. We have to work together with our competitors in the open source ecosystem. When I look at Open Usage Commons, I’m not seeing the same multi-vendor diversity there. In fairness, it is early days, but I am happy with the CNCF and see no reason to diverge.”
Monroy said that Kubernetes remains hot technology. “Kubernetes is exploding in usage. It’s the fastest growing service in Azure compute history.” He also said that the launch of OSM does not imply that it will not support other options like Linkerd. “We have opinions in this space. We also have to make space for partners,” he said.
He also says that Microsoft intends to further simplify its use by developers, with OSM perhaps an example. “Anyone who says the developer experience for Kubernetes has been solved has not seen what I’ve seen,” he says.®