As the number of microservices we need to govern increases, we must begin to address the complexity of communication between services, and the emergence of Service Mesh as an infrastructure layer provides secure, fast, and reliable communication between services in the form of transparent proxies.

What are the issues we need to consider before implementing Service Mesh?

Is the team ready for Service Mesh?

The implementation, use and maintenance of any new technology or tool comes with a learning cost, and we need to fully understand and prepare to ensure that the investment is meaningful. For example, if we manage a distributed application with a large number of different inter-service Service invocations, then Service Mesh is worth a try.

What are the current problems?

What are the problems encountered so far? What is the big pain point of managing distributed applications? Is it observability, service dependency, or security? If the answer is yes, then the Service Mesh will help.

What platforms need to be supported?

Where does the application run? In addition to the container management platform, do we need to connect the Service gateway Service we are interested in to other services that are not in the Service Mesh?

How about the observable line of the service now?

The most easily realized benefit of a Service Mesh is visibility into Service communications, which is important to most enterprise IT, but one that is easily overlooked.

What Service Mesh features are already implemented?

How to use the Service Mesh also needs to be considered. Usually, we already have some solution, such as solving load balancing problems and so on. How does an existing solution integrate with the Service Mesh, or discard the existing solution and replace it with a new one?

How does the team divide their work?

Is the development team willing to manage the broker configuration themselves? Or unified management by the operation and maintenance team? We should ensure that the division of labor after implementing the Service Mesh is efficient and meaningful.

Centralized or distributed?

Depending on the size and complexity of the deployment, does the team prefer host-based agent pooling, or is it concerned about the potential complexity of the Sidecar pattern under the Service Mesh? What factors influence our decision making?

What kind of support is the team looking for?

Does open source community support meet team needs? How much tolerance is there for rapidly iterating product features and standards? Do you need commercial support? These considerations are important in production.

The above points are just a primer, for different organizations, the situation is certainly different.

To learn more about the Service Mesh solution and obtain open source and commercial support, visit the Rainbond website and contact the Good Rain Engineers.

About Rainbond

Rainbond is an application-centered open source PaaS, independently developed by Good Rain based on container technologies such as Docker and Kubernetes. It can be used as an application delivery platform, DevOps platform, automatic operation and maintenance platform and industry cloud platform in public or private cloud environment. Or as an enterprise-level hybrid cloud multi-cloud management tool, Kubernetes container management tool or Service Mesh microservices architecture governance tool.

  • Rainbond Project website
  • Try Rainbond public cloud
    • Register or use the Demo account and password to log in to rainbond- Demo /rainbond- Demo
  • Github
  • Yards cloud
  • The document
  • Wechat group: Add wechat “Zqg5258423” and accept invitations to join the group