Personal blog of Yzmir Ramirez

Microsoft today announced the launch of a new open-source service mesh based on the Envoy proxy. The Open Service Mesh is meant to be a reference implementation of the Service Mesh Interface (SMI) spec, a standard interface for service meshes on Kubernetes that has the backing of most of the players in this ecosystem.

The company plans to donate Open Service Mesh to the Cloud Native Computing Foundation (CNCF) to ensure that it is community-led and has open governance.

“SMI is really resonating with folks and so we really thought that there was room in the ecosystem for a reference implementation of SMI where the mesh technology was first and foremost implementing those SMI APIs and making it the best possible SMI experience for customers,” Microsoft director of partner management for Azure Compute (and CNCF board member) Gabe Monroy told me.

Image Credits: Microsoft

He also added that, because SMI provides the lowest common denominator API design, Open Service Mesh gives users the ability to “bail out” to raw Envoy if they need some more advanced features. This “no cliffs” design, Monroy noted, is core to the philosophy behind Open Service Mesh.

As for its feature set, SMI handles all of the standard service mesh features you’d expect, including securing communications between services using mTLS, managing access control policies, service monitoring and more.

Image Credits: Microsoft

There are plenty of other service mesh technologies in the market today, though. So why would Microsoft launch this?

“What our customers have been telling us is that solutions that are out there today, Istio being a good example, are extremely complex,” he said. “It’s not just me saying this. We see the data in the AKS 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. And so the solutions that were out there all had something that wasn’t quite right and we really felt like something lighter weight and something with more of an SMI focus was what was going to hit the sweet spot for the customers that are dabbling in this technology today.”

Monroy also noted that Open Service Mesh can sit alongside other solutions like Linkerd, for example.

A lot of pundits expected Google to also donate its Istio service mesh to the CNCF. That move didn’t materialize. “It’s funny. A lot of people are very focused on the governance aspect of this,” he said. “I think when people over-focus on that, you lose sight of how are customers doing with this technology. And the truth is that customers are not having a great time with Istio in the wild today. I think even folks who are deep in that community will acknowledge that and that’s really the reason why we’re not interested in contributing to that ecosystem at the moment.”

API management platform Kong today announced that it is donating its open-source Kuma control plane technology to the Cloud Native Computing Foundation (CNCF). Since Kong built Kuma on top of the Envoy service mesh — and Envoy is part of the CNCF’s stable of open-source projects — donating it to this specific foundation was likely an obvious move.

The company first open-sourced Kuma in September 2019. In addition to donating it to the CNCF, the company also today launched version 0.6 of the codebase, which introduces a new hybrid mode that enables Kuma-based service meshes to support applications that run on complex heterogeneous environments, including VMs, Kubernetes clusters and multiple data centers.

Image Credits: Kong

Kong co-founder and CTO Marco Palladino says that the goal was always to donate Kuma to the CNCF.

“The industry needs and deserves to have a cloud native, Envoy-based control plane that is open and not governed by a single commercial entity,” he writes in today’s announcement. “From a technology standpoint, it makes no sense for individual companies to create their own control plane but rather build their own unique applications on proven technologies like Envoy and Kuma. We welcome the broader community to join Kuma on Slack and on our bi-weekly community calls to contribute to the project and continue the incredible momentum we have achieved so far.”

Kuma will become a CNCF Sandbox project. The sandbox is the first stage that projects go through to become full graduated CNCF projects. Currently, the foundation is home to 31 sandbox projects, and Kong argues that Kuma is now production-ready and at the right stage where it can profit from the overall CNCF ecosystem.

“It’s truly remarkable to see the ecosystem around Envoy continue to develop, and as a vendor-neutral organization, CNCF is the ideal home for Kuma,” said Matt Klein, the creator of the Envoy proxy. “Now developers have access to the service mesh data plane they love with Envoy as well as a CNCF-hosted Envoy-based control plane with Kuma, offering a powerful combination to make it easier to create and manage cloud native applications.”

Service mesh is just beginning to take hold in the cloud-native world, and as it does, vendors are looking for ways to help customers understand it. One way to simplify the complexity of dealing with the growing number of service mesh products out there is to package it as a service. Today, HashiCorp announced a new service on Azure to address that need, building it into the Consul product.

HashiCorp co-founder and CTO Armon Dadgar says it’s a fully managed service. “We’ve partnered closely with Microsoft to offer a native Consul [service mesh] service. At the highest level, the goal here is, how do we make it basically push-button,” Dadgar told TechCrunch.

He adds that there is extremely tight integration in terms of billing and permissions, as well as other management functions, as you would expect with a managed service in the public cloud. Brendan Burns, one of the original Kubernetes developers, who is now a distinguished engineer at Microsoft, says the HashiCorp solution really strips away a lot of the complexity associated with running a service mesh.

“In this case, HashiCorp is using some integration into the Azure control plane to run Consul for you. So you just consume the service mesh. You don’t have to worry about the operations of the service mesh, Burns said. He added, “This is really turning it into a service instead of a do-it-yourself exercise.”

Service meshes are tools used in conjunction with containers and Kubernetes in a dynamic cloud native environment to help micro services communicate and interoperate with one another. There is a growing number of them, including Istio, Envoy and Linkerd, jockeying for position right now.

Burns makes it clear that while Microsoft is working closely with HashiCorp on this project, it’s also working with other vendors, as well. “Our goal with the service mesh interface specification was really to let a lot of partners be successful on the platform. You know, there’s a bunch of different service meshes. It’s a place where we feel like there’s a lot of evolution and experimentation happening, so we want to make sure that our customers can can find the right solution for them,” Burns explained.

The HashiCorp Consul service is currently in private beta.

As containers and microservices have proliferated, a new kind of tool called the service mesh has developed to help manage and understand interactions between services. While Kubernetes has emerged as the clear container orchestration tool of choice, there is much less certainty in the service mesh market. Solo.io today announced a new open-source tool called Service Mesh Hub, designed to help companies manage multiple service meshes in a single interface.

It is early days for the service mesh concept, but there are already multiple offerings, including Istio, Linkerd (pronounced Linker-Dee) and Envoy. While the market sorts itself it out, it requires a new set of tools, a management layer, so that developers and operations can monitor and understand what’s happening inside the various service meshes they are running.

Idit Levine, founder and CEO at Solo, says she formed the company because she saw an opportunity to develop a set of tooling for a nascent market. Since founding the company in 2017, it has developed several open-source tools to fill that service mesh tool vacuum.

Levine says that she recognized that companies would be using multiple service meshes for multiple situations and that not every company would have the technical capabilities to manage this. That is where the idea for the Service Mesh Hub was born.

It’s a centralized place for companies to add the different service mesh tools they are using, understand the interactions happening within the mesh and add extensions to each one from a kind of extension app store. Solo wants to make adding these tools a simple matter of pointing and clicking. While it obviously still requires a certain level of knowledge about how these tools work, it removes some of the complexity around managing them.

Solo.io Service Mesh Hub (Screenshot: Solo.io)

“The reason we created this is because we believe service mesh is something big, and we want people to use it, and we feel it’s hard to adopt right now. We believe by creating that kind of framework or platform, it will make it easier for people to actually use it,” Levine told TechCrunch.

The vision is that eventually companies will be able to add extensions to the store for free, or even at some point for a fee, and it is through these paid extensions that the company will be able to make money. She recognized that some companies will be creating extensions for internal use only, and in those cases, they can add them to the hub and mark them as private and only that company can see them.

For every abstraction it seems, there is a new set of problems to solve. The service mesh is a response to the problem of managing multiple services. It solves three key issues, according to Levine. It allows a company to route the microservices, have visibility into them to see logs and metrics of the mesh and to provide security to manage which services can talk to each other.

Levine’s company is a response to the issues that have developed around understanding and managing the service meshes themselves. She says she doesn’t worry about a big company coming in and undermining her mission because she says that they are too focused on their own tools to create a set of uber-management tools like these (but that doesn’t mean the company wouldn’t be an attractive acquisition target).

So far, the company has taken more than $13 million in funding, according to Crunchbase data.

With each new set of technologies comes a new set of terms. In the containerized world, applications are broken down into discrete pieces or micro services. As these services proliferate, it creates a service mesh, a network of services and the interactions that take place as they interact. For each new technology like this, it requires a management layer, especially for the network administrators to understand and control the new concept, in this case, the service mesh.

Today at Google Cloud Next, the company announced the Beta of Traffic Director for open service mesh, specifically to help network managers understand what’s happening in their service mesh.

“To accelerate adoption and reduce the toil of managing service mesh, we’re excited to introduce Traffic Director, our new GCP-managed, enterprise-ready configuration and traffic control plane for service mesh that enables global resiliency, intelligent load balancing, and advanced traffic control capabilities like canary deployments,” Brad Calder, VP of engineering for technical infrastructure at Google Cloud, wrote in a blog post introducing the tool.

Traffic Director provides a way for operations to deploy a service mesh on their networks and have more control over how it works and interacts with the rest of the system. The tool works with Virtual Machines, Compute Engine on GCP, or in a containerized approach, GKE on GCP.

The product is just launching into Beta today, but the road map includes additional security features and support for hybrid environments, and eventually integration with Anthos, the hybrid management tool the company introduced yesterday at Google Cloud Next.

 Buoyant, a company founded by former Twitter infrastructure engineers William Morgan and Oliver Gould, today announced that it has raised a $10.5 million Series A round. Read More