patternMinor
What is a "mesh"?
Viewed 0 times
meshwhatstackoverflow
Problem
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?
Solution
The concept of service discovery works like this:
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:
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.
- 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.
- 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:
- 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.
- The client starts up and tells its local mesh agent that it needs a database
- 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.
Context
StackExchange DevOps Q#5374, answer score: 6
Revisions (0)
No revisions yet.