Service Mesh is a well-known architectural pattern for integrating microservices and migrating to cloud infrastructure. Today, in the cloud-container world, it is quite difficult to do without it. Several open-source service mesh implementations are already available on the market, but their functionality, reliability and security are far from always enough, especially when it comes to the requirements of large financial companies throughout the country. Therefore, we at Sbertech decided to customize Service Mesh and want to talk about what is cool in Service Mesh, what is not very good, and what we are going to do with it.
The popularity of the Service Mesh pattern is growing with the popularity of cloud technologies. It is a dedicated infrastructure layer that simplifies the interaction between various network services. Modern cloud applications consist of hundreds and even thousands of such services, each of which can have thousands of copies.
The interaction between these services and their management is a key task of the Service Mesh. In fact, this is a network model of many proxies, managed centrally and performing a set of very useful functions.
At the proxy level (data plane):
- Assigning and propagating routing and traffic balancing policies
- Distribution of keys, certificates, tokens
- Collection of telemetry, formation of monitoring metrics
- Integration with security and monitoring infrastructure
At the control plane level:
- Applying routing and traffic balancing policies
- Management of repetitions and timeouts, detection of "dead" nodes (circuit breaking), management of failure situations (injecting faults) and ensuring the stability (resilence) of services through other mechanisms
- Call Authentication/Authorization
- Dropping metrics (observability)
The circle of users interested in the development of this technology is very wide - from small startups to large Internet corporations, such as PayPal.
Why do you need Service Mesh in the corporate sector
Using a Service Mesh brings many obvious benefits. First of all, it's just convenient for developers: for writing code emerging technological platform, which greatly simplifies integration into the cloud infrastructure due to the fact that the transport layer is completely isolated from the application logic.
Additionally, Service Mesh simplifies the relationship between suppliers and consumers. Today, it is much easier for API providers and consumers to agree on interfaces and contracts on their own, without involving a special integration intermediary and arbitrator for this - a corporate service bus. This approach significantly affects two indicators. The speed of bringing new functionality to the market (time-to-market) increases, but at the same time the cost of the solution increases, since the integration has to be done independently. The use of Service Mesh by business feature teams helps keep the balance here. As a result, API providers can focus exclusively on the application component of their service and simply publish it in the Service Mesh - the API will immediately become available to all clients, and the integration quality will be production ready and will not require a single line of additional code.
The next advantage is that developer using Service Mesh focuses exclusively on business functionality - on the product, and not on the technological component of their service. For example, you no longer have to think that in a situation where the service will be called over the network, a connection break may occur somewhere. In addition, Service Mesh helps to balance traffic between copies of the same service: if one of the copies "died", then the system will switch all traffic to the remaining live copies.
Service Mesh it is a good basis for building distributed applications, which hides from the client the details of providing calls to its services both from inside and outside. All applications using the Service Mesh are isolated from the network and from each other at the transport level: there is no connection between them. This gives the developer full control over their services.
It should be noted that updating distributed applications in an environment where Service Mesh is used becomes easier. For example, a blue/green deployment where two application environments are available for installation, one of which is not updated and is idle. Rollback to the previous version in case of an unsuccessful release is carried out by a special router, the role of which is perfectly handled by Service Mesh. To test the new version, you can also use canary release β switch to the new version only 10% of traffic or requests from a pilot group of clients. The main traffic goes to the old version, nothing breaks.
Also Service Mesh gives us real-time SLA control. The system of distributed proxies will not allow to overwhelm the service when one of the clients exceeds the quota given to him. If the bandwidth on the API is limited, no one will be able to push it with a large number of transactions: Service Mesh stands in front of the service and does not allow extra traffic. It will simply fight back in the integration layer, and the services themselves will continue to work without noticing it.
If a company wants to reduce the cost of developing integration solutions, Service Mesh also helps: you can switch to its open-source versions from commercial products. Our Enterprise Service Mesh is based on the open-source version of Service Mesh.
Another advantage is availability of a single full-fledged set of integration services. Since all integration is built through this middle layer, we can manage all the integration traffic and communications between applications that form the business core of the company. It is very comfortable.
And finally Service Mesh encourages a company to move to a dynamic infrastructure. Now many are looking towards containerization. Cutting a monolith into microservices, itβs all beautiful to implement - the topic is on the rise. But when you try to put on a new footing a system that has been in production for many years, you immediately encounter a number of problems: itβs not easy to push it all into containers and deploy it on a platform. And the implementation, synchronization, and interaction of these distributed components is another complex topic. How will they communicate with each other? Will there be cascading failures? Service Mesh allows you to solve some of these problems and facilitate migration from the old architecture to the new one due to the fact that you can forget about the network exchange logic.
Why Service Mesh Customization Is Necessary
In our company, hundreds of systems and modules coexist together, and the runtime is very busy. So a simple pattern where one system calls another and gets a response is not enough, because in production we want more. What else do you need from a corporate Service Mesh?
Event handling service
Let's imagine that we need to make real-time event processing - a system that analyzes the client's actions in real time and can immediately make him a relevant offer. To implement this functionality, use architectural pattern called event-driven architecture (EDA). None of the current Service Mesh natively supports such patterns, and this is very important, especially for a bank!
It is rather strange that the "remote call" Remote Procedure Call (RPC) is supported by all versions of Service Mesh, but they are not friends with EDA. Because Service Mesh is a kind of modern distributed integration, and EDA is a very relevant architectural pattern that allows you to do unique things in terms of customer experience.
Our Enterprise Service Mesh should solve this problem. In addition, we want to see in it the implementation of guaranteed delivery, streaming and complex event processing using a variety of filters and templates.
File transfer service
In addition to EDA, it would be nice to be able to transfer files: at Enterprise scale, very often only file integration is possible. In particular, the ETL (Extract, Transform, Load) architectural pattern is used. In it, as a rule, everyone exchanges exclusively files: big data is used, which is inappropriate to shove with separate requests. The ability to natively support file transfer in Enterprise Service Mesh gives you the flexibility your business needs.
Orchestration service
Large organizations almost always have different teams that make different products. For example, in a bank, some teams work with deposits, while others work with loan products, and there are a lot of such cases. These are different people, different teams that make their products, develop their own APIs and provide them to others. And very often there is a need for the composition of these services, as well as the implementation of complex logic for sequentially calling a set of APIs. To solve this problem, a solution is needed in the integration layer, which will simplify all this composite logic (calling several APIs, describing the request route, etc.). This is the orchestration service in the Enterprise Service Mesh.
AI and ML
When microservices communicate through a single integration layer, the Service Mesh naturally knows everything about each service's calls. We collect telemetry: who called whom, when, for how long, how many times, and so on. When there are hundreds of thousands of these services, and billions of calls, then all this accumulates and forms Big Data. This data can be analyzed using AI, machine learning, etc., and then some useful things can be done based on the results of the analysis. It would be appropriate to at least partially transfer control of all this network traffic and application calls integrated into the Service Mesh to artificial intelligence.
API Gateway Service (API Gateway)
Typically, a Service Mesh has proxies and services that communicate with each other within a trusted perimeter. But there are also external partners. The requirements for APIs exposed to this consumer group are much more stringent. We divide this task into two main parts.
- Security. Issues related to ddos, protocol vulnerabilities, applications, operating systems, and so on.
- Scale. When the number of APIs to be given to customers runs into the thousands or even hundreds of thousands, there is a need for some kind of management tool for this set of APIs. You need to constantly monitor the API: whether they work or not, in what status, what traffic is coming, what statistics, etc. The API Gateway should be able to handle this task, making the whole process manageable and secure. Thanks to this component, the Enterprise Service Mesh learns how to easily publish both internal API and external API.
Support service for specific protocols and data formats (AS gateway)
Currently, most Service Mesh solutions can natively work only with HTTP and HTTP2 traffic or in a reduced mode at the level TCP/IPThe Enterprise Service Mesh is introducing many other highly specific data transfer protocols. Some systems may use message brokers, while others are integrated at the database level. If a company has SAP, it can also use its own integration system. All of this works and is an important part of the business.
You can't just say: "Let's abandon the legacy and make new systems that can use the Service Mesh." To make friends with all old systems with new ones (on a microservice architecture), systems that can use Service Mesh will need some kind of adapter, intermediary, gateway. Agree, it would be nice if it came in a box with the service. The AC gateway can just support any integration option. Just imagine, you just install Enterprise Service Mesh and it is already ready to interact with all the protocols you need. For us, this approach is very important.
This is how we present the corporate version of Service Mesh (Enterprise Service Mesh). The described customization solves most of the problems that arise when trying to use ready-made open-source versions of the integration platform. Having appeared only a couple of years ago, the Service Mesh architecture continues to evolve, and we are pleased to be able to contribute to its development. We hope that our experience will be useful to you.
Source: habr.com
