Keynote: Consul Connect and the VMware Service Mesh specification

Many companies are preparing for the proliferation of service mesh providers inside enterprises. For enterprises that standardized on VMware, a new service mesh interoperatability specification has been announced, with partners including HashiCorp, Pivotal, and Google Cloud.

In this keynote segment, Pere Monclus, the CTO of Networking and Security at VMware, talks about the VMware service mesh specification and how it works with HashiCorp's Consul Connect service mesh. He'll also discuss new support for integration between Consul and VMware NSX Service Mesh (NSX-SM).

Transcript

We saw this morning a discussion with Armon that everything was going multi-cloud, multi-application, multi-service. At the same time, we are seeing from Mitchell the idea that networking is much more than IP address and connectivity of switches and routers

It's evolving toward providing what we call "service communications," and within this new world, what you are seeing is that customers are coming to the industry and essentially demanding, "How do I connect these environments across multiple silos?"

Today, every time I deploy a Kubernetes environment, every time I create a cloud-native app, every time I go to a public cloud, essentially I have a microcosm of soft operational models, security models, identity models, connectivity models. What happens is it's very difficult to eventually operate the whole thing as a cohesive system.

We started working within a group of companies, and we started realizing that we couldn't repeat some of the patterns of the past, the notion of saying, "We have an environment in private cloud, in public cloud, in Kubernetes, and they are isolated, managed by different teams."

We started discussing this notion of, How do we understand what the service is across heterogeneous environments? How do we connect a microservice in one side to, let's say, a VM on the other side? And it was going back to the fundamentals of what connectivity is.

This is the evolution, as we go to service networking, that we were discussing with Mitchell: this notion that it's not anymore about connecting from IP A to IP B, but rather how to understand identity across environments. How do we understand end-to-end connectivity? How do we understand policy? How do we understand service discovery?

For that, we started working in defining, in an open standard with open source with a group of companies, how to exchange information between 2 disparate measures in a way that, from an operations point of view, they could work together.

There is a session today in the afternoon that will go into the details of how Consul Connect federates with a service mesh project that we have at VMware, NSX Service Mesh, and how you see an end-to-end connectivity on those. That's an open framework that we are working on within the community, with participants like Google and other players, that allows you to stretch the notion of this service networking, this service mesh, across multiple environments.

Provided we do that, we achieve these end-to-end service meshes, what we call enterprise-class service mesh. The idea is that now we can discover, monitor, control, and have consistent policies across all the environments that you may have from a service point of view.

Within that, though, when we're talking to our customers, we are seeing that this was potentially not enough. We are very focused on how a service interoperates with another service, but as we go through these layers of communication, as we move from traditional networking to how microservices communicate, the picture is much more complicated.

The authentication question

Now, as we get inside the semantics of the application, what we have is that services are there to provide some useful value to the users that connect to their service, the authentication aspect of, What users connect to what service?

Eventually we end up writing to an object. Within this evolution of networking, service networking, and communications, what we are building at VMware is expanding the meaning of what you connect from, in this case, a service, to something much more broad, like how a user connects to a service, and how this service on behalf of that user writes into where that is stored.

That allows us to spread this mesh across multiple computer environments, multiple clouds, but at the same time extend it to these 3 principles in a way that, when we discover what services we have, we by definition discover what users authenticate to those services, and what objects are being written to, in a way that, when you have the visibility into the SLO that you observe from a microservice, you could say, "What's the experience that the user is seeing from that entity?"

As you go to the control, you could start thinking in terms of, Why are users in Europe writing into objects in the US? Is this a GDPR violation?

The notion of going to the service mesh concept is a fundamental transformation, because now it brings capabilities that before were hidden in multiple layers of infrastructure. Now you can get closer to the business policies of what you intend to do, and use the deeper semantics that service networking has into the application to provide that.

Of course, this is not just about how to create connectivity across cloud and AP, or connectivity across multiple Kubernetes clusters. It’s, How do I extend whatever service mesh concept I may have in the cloud-native wall? How do I extend it into virtual machine wall? How do I extend it into the physical mainframes and bare metals?

To that extent, we are of course integrating with different components of the VMware family and different partners outside on how to make sure that we can communicate the current service networking of the cloud-native wall to the previous one that Mitchell was discussing about load balancers and IP connectivity.

To summarize, we are very excited to be part of this collaboration with HashiCorp, because in this multi-cloud, multi-service transition that we are going through, the only way that we are going to satisfy the requirements of an end-to-end security model and an end-to-end connectivity model, is if we start working, cultivating, and molding these frameworks about how to federate environments to solve end-to-end problems. Thank you.