Service Mesh landing path

When deciding to introduce Service Mesh, the specific path of Service Mesh landing should be considered.The first is whether the current stage of the business already supports containerization and Kubernetes.If the business is currently running on Kubernetes, because Istio has good support for Kubernetes, Service Mesh migration will be very smooth; if the business is not currently running on Kubernetes containers, because Istio, the most powerful service mesh field, has good support for Kubernetes.There are certain dependencies, so it may not be possible to use Istio directly. Even if Istio is customized and modified to relieve the dependence on Kubernetes, it will cost a lot.At this time, there are usually two paths to choose from.

1. In a non-Kubernetes environment, connect to Sidecar first

If there is no way to quickly containerize the business and there is an urgent need to introduce Service Mesh, you can connect to Sidecar first to meet the current pain points of the business.As for the evolution direction after accessing Sidecar, it depends on whether there is a Kubernetes containerization plan in the future business planning. If so, it is recommended to carry out containerization transformation first, and then evolve from Sidecar to Istio.

Istio is not well supported in non-Kubernetes environments, and it is a lot of work to customize Istio to support non-Kubernetes environments unless there is a very strong demand and very powerfulIt is generally not recommended to do this, especially for some small and medium-sized companies.If you must implement Service Mesh in a non-Kubernetes environment, you can use Envoy on the data plane, and the control plane is developed according to the XDS protocol, which is also very flexible and easy to control.

Second, first perform Kubernetes containerization transformation, and then access Istio

For teams with Kubernetes containerization requirements, Istio can be accessed after Kubernetes containerization is completed. Istio utilizes the powerful infrastructure capabilities of Kubernetes in many aspects, so onlyOnly under Kubernetes can Istio play its best role and reduce the complexity of operation and maintenance.

For Istio, current performance is indeed a key factor that blocks the large-scale implementation of Service Mesh. The purpose of introducing Istio is to solve the pain point requirements. The most valuable parts of Istio are Envoy and Pilot, which together complete the configuration management of request routing and forwarding, as well as the actual forwarding.

The Mixer architecture design looks good, but the business does not actually use the Mixer components too much, and does not have such high requirements for scalability and flexibility.For performance considerations, Mixer-related functions can be put into Envoy, and only the most streamlined and necessary checking and telemetry statistics logic is implemented.

Istio security needs to be flexibly selected according to the specific situation of the business.For example, our business is placed in the private cloud of the self-built computer room. For the east-west communication within the Istio-oriented microservices, there is no need to consider too many security issues in the intranet environment, so the security part can be cut directly.; Of course, if you deploy Service Mesh services in the public cloud, you need to pay more attention to the security part.

From the point of view of solving pain points and comprehensively considering performance, we can focus on the core values ​​provided by Istio first, and cut out the parts that do not need much attention at present.In addition, due to scalability considerations, the overall performance of the Istio architecture will be affected to a certain extent. If your business only runs on a specific platform, such as Kubernetes, you can customize and optimize Istio according to the specific platform.