<p>The concept of <em>service discovery</em> works like this:</p>

<ol>
<li>When a server, such as a database, starts up, it contacts a central registry and says <em>Hi, I am a database, and these are my connection details</em>.</li>
<li>Then when a client starts up, it contacts the registry and says <em>Hi, I need a database</em> and the registry replies <em>Here are the connection details</em> and the client connects to the database directly.</li>
</ol>

<p>The only config anyone needs is the location of the registry. The concept of <em>mesh</em> applies a layer of abstraction to this. Every host runs an agent of the mesh, there is no central registry. Now the scenario looks like this:</p>

<ol>
<li>The database server starts up and tells its local mesh agent that it is ready. That local agent then replicates this information around the mesh. Agents are in continual communication with each other.</li>
<li>The client starts up and tells its local mesh agent that it needs a database</li>
<li>The client then connects <em>to its local mesh agent</em> which forwards the traffic to the mesh agent on the database server, which simply sees a local connection. Neither the client nor the server are really aware of each other, just of their local connections.</li>
</ol>

<p>The advantages are decentralisation and scalability - you could add a new database server for example and let the mesh transparently handle routing and load balancing. There is no central registry to worry about. In our scenario of one client and one server that doesn't matter so much but if you go wild and have 10,000 microservices then it becomes very relevant. </p>

<p>The disadvantage is one of "all your eggs in one basket", the mesh itself must be more robust etc than making a traditional connection, which has been proven to work for 30 years. It can also be difficult to use traditional troubleshooting tools such as tracing connections, because the mesh is something of a "black box", it can be difficult to reason about all the connections as all the traffic on your network now will be inside the mesh, e.g. you can't just look for connections on port X and know that's the database. </p>

CC BY-SA 4.0
2018-11-08T07:16:48.887Z
2018-11-09T07:58:31.057Z
2018-11-09T07:58:31.057Z
Gaius
<p>The metaphor of "mesh" is "many interconnected things". We might describe TCP/IP as a "mesh technology" as it is the technology that connects many things and performs useful services like resending lost packets and adapting to changes in available bandwidth. </p>

<p>Modern "service mesh" technologies let you write basic code then wrap it in something readymade that plugs-in discovery (locating. resources), mutual TSL, protocol upgrade (newest HTTP or better), applies security policies, fault tolerance (such as retry on error), load shedding, circuit breakers, distributed tracing (header setting and traffic sampling), advanced load balancing, and much more.</p>

<p>Imagine that the internet only had UDP protocol. You can send a packet but you didn't know it got there. You might in your application have to write a bunch of code to detect lost messages and request a resend. You might write a library to do that. You might compile all your apps against such libraries written in different languages (PHP, Java, C, Perl, ...). That would be terrible. You would want someone to invent TCP/IP that just does it for you. Then you can write simple code that "just connects and sends" and the "TCP/IP service mesh" will do its magic and make sure that the data gets <code>A-&gt;B</code> as fast as possible dealing with dropped messages and varying bandwidth conditions. </p>

<p>Today developers writing microservices are having to use libraries for discovery, mutual TSL, protocol upgrade (older HTTP over newer HTTP or better), security policy, fault tolerance, load shedding, circuit breakers, distributing tracking, advanced load balancing, ... That's terrible, right? Shouldn't we just be able to deploy some new technology that sits between <code>A</code> and <code>B</code> and ensures that all the traffic <code>A-&gt;B</code> had all those features? You need a Service Mesh. </p>

<p>In the kubernetes world things such <a href="https://linkerd.io" rel="nofollow noreferrer">Linkerd</a> and <a href="https://www.envoyproxy.io" rel="nofollow noreferrer">Envoy</a> provide the base technologies. They are smart proxies. You don't go <code>A-&gt;B</code> you go <code>A-&gt;P=&gt;P-&gt;B</code> where <code>-&gt;</code> are local connection. A service has a data plane (move the data) provided by the smart proxies and an administration control plane (apply the desired policies by pushing configuration out to the smart proxies). </p>

<p>With Linkerd you run it as a demon set (one per container host). With Envoy it's small enough to deploy it as a sidecar container. So you keep the "local dumb connections" within the VM host. All traffic between VM hosts is smart proxy traffic with all the new features you want applied by policy. </p>

<p>Discovery (locating resources) is something a service mesh does. All containers just connect to a smart local proxy. The smart proxy looks at the header of the connection to see the logical name of the service you are connecting to. It then uses its own dynamic configuration distributed across its control plane to decide what physical location to proxy the traffic towards. What is more interesting is all the very smart things it can do to the traffic that it sends over the wire. These are additional technical services. All the interconnections are a mesh. The advanced services are applied to traffic in the mesh. It is therefore a Service Mesh.  </p>

<p>If you want to look at something in this space look at <a href="https://istio.io/docs/concepts/what-is-istio/" rel="nofollow noreferrer">istio.io</a></p>

CC BY-SA 4.0
2018-11-11T21:58:28.757Z
2020-01-15T23:14:57.293Z
2020-01-15T23:14:57.293Z
simbo1905
<p>In this context and cloud computing, I read about "service mesh" and/or "serverless mesh" but I don't fully understand what it is. Can you explain?</p>

<terminology><microservices><cloud>
What is a "mesh"?
Niklas Rosencrantz
# What is a "mesh"?

(Asked by: username_0 on 2018-11-08)

In this context and cloud computing, I read about "service mesh" and/or "serverless mesh" but I don't fully understand what it is. Can you explain?

**Tags:** terminology, microservices, cloud


---

## 2 answers

### Answer by username_2 on 2018-11-11. Score: 4 | Accepted answer

The metaphor of "mesh" is "many interconnected things". We might describe TCP/IP as a "mesh technology" as it is the technology that connects many things and performs useful services like resending lost packets and adapting to changes in available bandwidth.

Modern "service mesh" technologies let you write basic code then wrap it in something readymade that plugs-in discovery (locating. resources), mutual TSL, protocol upgrade (newest HTTP or better), applies security policies, fault tolerance (such as retry on error), load shedding, circuit breakers, distributed tracing (header setting and traffic sampling), advanced load balancing, and much more.

Imagine that the internet only had UDP protocol. You can send a packet but you didn't know it got there. You might in your application have to write a bunch of code to detect lost messages and request a resend. You might write a library to do that. You might compile all your apps against such libraries written in different languages (PHP, Java, C, Perl, ...). That would be terrible. You would want someone to invent TCP/IP that just does it for you. Then you can write simple code that "just connects and sends" and the "TCP/IP service mesh" will do its magic and make sure that the data gets `A->B` as fast as possible dealing with dropped messages and varying bandwidth conditions.

Today developers writing microservices are having to use libraries for discovery, mutual TSL, protocol upgrade (older HTTP over newer HTTP or better), security policy, fault tolerance, load shedding, circuit breakers, distributing tracking, advanced load balancing, ... That's terrible, right? Shouldn't we just be able to deploy some new technology that sits between `A` and `B` and ensures that all the traffic `A->B` had all those features? You need a Service Mesh.

In the kubernetes world things such [Linkerd](https://linkerd.io) and [Envoy](https://www.envoyproxy.io) provide the base technologies. They are smart proxies. You don't go `A->B` you go `A->P=>P->B` where `->` are local connection. A service has a data plane (move the data) provided by the smart proxies and an administration control plane (apply the desired policies by pushing configuration out to the smart proxies).

With Linkerd you run it as a demon set (one per container host). With Envoy it's small enough to deploy it as a sidecar container. So you keep the "local dumb connections" within the VM host. All traffic between VM hosts is smart proxy traffic with all the new features you want applied by policy.

Discovery (locating resources) is something a service mesh does. All containers just connect to a smart local proxy. The smart proxy looks at the header of the connection to see the logical name of the service you are connecting to. It then uses its own dynamic configuration distributed across its control plane to decide what physical location to proxy the traffic towards. What is more interesting is all the very smart things it can do to the traffic that it sends over the wire. These are additional technical services. All the interconnections are a mesh. The advanced services are applied to traffic in the mesh. It is therefore a Service Mesh.

If you want to look at something in this space look at [istio.io](https://istio.io/docs/concepts/what-is-istio/)


---

### Answer by username_1 on 2018-11-08. Score: 6

The concept of *service discovery* works like this:

1. When a server, such as a database, starts up, it contacts a central registry and says *Hi, I am a database, and these are my connection details*.
2. Then when a client starts up, it contacts the registry and says *Hi, I need a database* and the registry replies *Here are the connection details* and the client connects to the database directly.

The only config anyone needs is the location of the registry. The concept of *mesh* applies a layer of abstraction to this. Every host runs an agent of the mesh, there is no central registry. Now the scenario looks like this:

1. The database server starts up and tells its local mesh agent that it is ready. That local agent then replicates this information around the mesh. Agents are in continual communication with each other.
2. The client starts up and tells its local mesh agent that it needs a database
3. The client then connects *to its local mesh agent* which forwards the traffic to the mesh agent on the database server, which simply sees a local connection. Neither the client nor the server are really aware of each other, just of their local connections.

The advantages are decentralisation and scalability - you could add a new database server for example and let the mesh transparently handle routing and load balancing. There is no central registry to worry about. In our scenario of one client and one server that doesn't matter so much but if you go wild and have 10,000 microservices then it becomes very relevant.

The disadvantage is one of "all your eggs in one basket", the mesh itself must be more robust etc than making a traditional connection, which has been proven to work for 30 years. It can also be difficult to use traditional troubleshooting tools such as tracing connections, because the mesh is something of a "black box", it can be difficult to reason about all the connections as all the traffic on your network now will be inside the mesh, e.g. you can't just look for connections on port X and know that's the database.


---

