FAQ

How to Choose the Right Control Plane & Data Plane for Your Service Mesh

The control plane needs scalability and reliability, and the data plane should run with low overhead.

Speakers

  • Jake Lundberg
    Jake LundbergField CTO, HashiCorp

Transcript

For people that are new to the service mesh, these concepts can be a little bit confusing, but you can boil them down to very easy analogies.

For people who are (American) football players or any kind of other sports players, for instance, you can think of the control plane as the coaching staff. On a football team, the control plane is maybe the head coach and your offensive coaches and your defensive coaches, whereas the players themselves are like the data plane. The control plane is the set of instructions that decide how the service mesh operates, and the data plane is the components that execute whatever it is that the control plane has.

Better scalability

Some very important features behind the control plane are around scalability, being able to make sure that it's not part of the data plane. Consul uses something called the "gossip protocol" in order to allow data to be transmitted off to your end-user systems and also allows you to do some caching on the end-user agents such that there isn't constant traffic back and forth between the data plane and the control plane.

Back to the coaching analogy, if we were to have a head coach who gives you a set of plays, once that play has been given to the players, it's up to them to execute those things without getting constant interaction with the coaching staff that's on the sidelines. Once that set of instructions is given, they go off and execute that in any way that we have it. And if you're using a product like Consul, it's touchdowns all the way.

Some really good qualities of a control plane are scalability—being able to scale both inside of your datacenter and across your datacenters to very easily talk to your control plane—and reliability, the ability to help your data plane cache data, so that there isn't constant communication between that.

And better resilience

And then combining the control plane with the data plane is quite resilient. We typically see people using a proxy mechanism like Envoy, for instance, which is very flexible in terms of how you can take a set of instructions from Consul and then go off and do proxy mechanisms, do mTLS termination, and also making sure that any of the intentions that were given by the control plane are there to help increase the security of data communications between those things.

Low overhead

Lastly, the data plane should be very low overhead to run, such that it doesn't get in the way of your transmissions of all your actors or your applications that are acting, because it's literally proxying all the traffic for everything that you have inside of your environment.

Why is Consul such a great solution for both the control plane and the data plane that we have inside of a service mesh? The set of instructions that you're going to be given from your control plane has the ability to deliver the sets of instructions both reliably through something like the gossip protocol as well as through a quicker manner by allowing things to cache inside the agents and only allow things to update when there are some kind of changes.

And the second is focusing on the data plane objects that we have. We have the ability to flexibly use any kind of proxy mechanisms, both the in-house proxy as well as something like an Envoy to allow those things to have very low overhead, secure transactions between the various endpoints, and to reliably move that traffic between your endpoints as well.

More resources like this one

  • 3/15/2023
  • Case Study

Using Consul Dataplane on Kubernetes to implement service mesh at an Adfinis client

  • 1/20/2023
  • FAQ

Introduction to Zero Trust Security

  • 1/4/2023
  • Presentation

A New Architecture for Simplified Service Mesh Deployments in Consul

  • 12/31/2022
  • Presentation

Canary Deployments with Consul Service Mesh on K8s