layout: post
title: "What Can Service Mesh Learn from SDN?" subtitle: "" excerpt: "" author: "赵化冰" date: 2019-11-23 description: "what is the relationship between Service Mesh and SDN — Is Service Mesh the next generation of SDN? What can Service Mesh learn from the experience of SDN? I’d like to share some of my own opinions in this article." image: "https://upload.wikimedia.org/wikipedia/commons/f/f0/%CE%91%CE%B8%CE%B1%CE%BC%CE%B1%CE%BD%CE%B9%CE%BA%CE%AC_%CE%8C%CF%81%CE%B7_%CF%85%CF%80%CF%8C_%CF%84%CE%BF_%CF%86%CF%89%CF%82_%CF%84%CE%BF%CF%85_%CE%A6%CE%B5%CE%B3%CE%B3%CE%B1%CF%81%CE%B9%CE%BF%CF%8D_-_%CE%A3%CF%84%CE%AC%CE%B8%CE%B7%CF%82_%CE%9A%CE%BF%CF%85%CF%84%CF%83%CE%B9%CE%B1%CF%8D%CF%84%CE%B7%CF%82.jpg" published: true tags:
- Service Mesh
- Istio
- SDN
Service Mesh is yet another emerging fancy tech word in the field of microservices recently. If you have a telecommunication or networking background, you may have already noticed that Service Mesh and SDN (Software Defined Network) look similar. Both of them use a software layer to manage and control the network infrastructure, and they also share the same architecture, which consists of a control plane and a data plane.
So what is the relationship between Service Mesh and SDN — Is Service Mesh the next generation of SDN? What can Service Mesh learn from the experience of SDN? I’d like to share some of my own opinions in this article.
First, let’s look into a little bit of the history of networks and how SDN is invented. A traditional network is a distributed, decentralized architecture. Each switch or router has its embedded control plane and this embedded control plane decides how to route the traffic on its own. They do coordinate with each other via some routing protocols, but there is no central management point responsible for the end to end route decisions.
The advantage of this architecture is that it is highly fault-tolerant. If a part of the network fails, the entire network can also work with little or even no interruption of the application traffic, because oftentimes the devices can avoid the failed path and find another alternative route by themselves.
{{< figure src="/img/2019-11-23-what-can-service-mesh-learn-from-sdn-english/network-devices.png" caption="Decentralized Traditional Network">}}
This decentralized architecture works well with the HTTP based web applications, which is mainly some web page with pictures and texts and users don’t care much about a small delay when loading the page. But with the explosive growth of the Internet, new kinds of web applications emerged, and they have different demands for the network. For example, video calls can tolerate minor signal loss but require very little latency, while online games require a very stable and fast network but may not need much bandwidth. The traditional network is just not flexible enough to match these demands:
SDN is intended to address these issues of traditional networks. The architecture of SDN is shown as below:
{{< figure src="/img/2019-10-26-what-can-service-mesh-learn-from-sdn/sdn.png" caption="SDN Architecture">}}
As you can see from the figure, SDN is a layered architecture:
Standard interfaces are used between different layers of SDN:
In a microservice system, remote calls are used for inter-service communication. The communication logic such as service discovery, load balancing, Circuit breaker, etc., is normally a code library and compiled into the service binary.
{{< figure src="/img/2019-11-23-what-can-service-mesh-learn-from-sdn-english/microservice.png" caption="Microservices Communication">}}
Looks quite familiar, right? This microservice system has similar problems to a traditional network:
From the above analysis, we can see that SDN and Service Mesh are introduced to solve similar problems. So, you might be wondering: Is Service Mesh the next generation of SDN?
OK, I think it’s yes, and no. Yes because they are all based on the same concept of separated control plane and data plane, no because they work on different OSI network layers. SDN mainly works on the L1 to L4, whereas service Mesh focuses on the L7 layer and above.
{{< figure src="/img/2019-10-26-what-can-service-mesh-learn-from-sdn/sdn-vs-service-mesh.jpg" caption="Comparison between SDN and Service Mesh">}}
As I mentioned before, Service Mesh uses an SDN like architecture to solve the microservice communication problems. {{< figure src="/img/2019-10-26-what-can-service-mesh-learn-from-sdn/service-mesh.jpg" caption="Service Mesh Architecture">}}
Almost all of the popular Service Mesh projects on the table are implemented like this, includingIstio,Linkerd,Kuma,etc.
In this architecture, the data plane takes the role of the white-box switch in SDN. At present, the envoy is the most popular data plane implementation, so Envoy’s xDS v2 interface is used as the de-facto data plane protocol.
Most of the innovation and competition happens on the control plane. As an attempt to algin various control plane implementations, Microsoft initiated the SMI (Service Mesh Interface) control plane interface. SMI has also been supported by some other service mesh players such as Linkerd, Consul connect and Gloo, but interestingly, as one of the most important Service Mesh projects, Istio has not yet expressed its opinion. Due to the fact of lacking a unified control plane interface, there are not many innovations in the application layer now.
The SDN control plane can manage various devices, no matter it’s a hardware white box or a software vSwitch. This is an important inspiration for Service Mesh. Can we use Service Mesh control plane to manage hardware devices as well?
There is an experiment of F5 BIG-IP and Istio integration. Some services in Service Mesh need to access data in a legacy database system, which is in another network. To protect the database, an F5 BIG-IP is placed in front of the database as an edge proxy:
This experiment proves that hardware devices can be integrated with service mesh to deliver a valuable business solution. But in this case, we have to manually configure the F5 BIG IP side, including opening the ports for the DB, configuring TLS certificates, setting authentication and access policies, etc. Imagine that if we could just use the Service Mesh control plane to send the needed configuration to the F5 device, the service provisioning process would be profoundly simplified. {{< figure src="/img/2019-10-26-what-can-service-mesh-learn-from-sdn/hardware-sidecar.jpg" caption="F5 BIG-IP Managed by Service Mesh Control Plane">}}
Just like SDN, Service Mesh can also expose its capabilities through a programmable API interface to the application layer. At present, Service Mesh is still in its infancy and there are not many innovations in the application layer, but from the history of SDN, we can see that there is a big room for us to fill in the application layer of Service Mesh.
Below is an example of Service Mesh applications: Service subscription and SLA management：
{{< figure src="/img/2019-10-26-what-can-service-mesh-learn-from-sdn/user-ubscription.jpg" caption="Service Mesh application: service subscription and SLA management">}}
It’s just a very simple example of Service Mesh applications. Leveraging the basic capabilities provided by the service Mesh control plane, including security policy, mesh topology, and request metrics, we can create a large number of value-added services, such as canary deployment, Chaos testing, service monitoring system, etc.
Both SDN and Service Mesh are invented to solve similar problems, but they aim at different network layers. Service Mesh is not the next generation of SDN, but Service Mesh can learn from the experience of SDN and evolve in the following directions: