<\/a><\/noindex>
On the proxy level (data plane):<\/i><\/p>\n\nAssignment and distribution of routing and traffic balancing policies\n<\/li>\n Distribution of keys, certificates, and tokens\n<\/li>\n Telemetry collection, formation of monitoring metrics\n<\/li>\n Integration with security and monitoring infrastructure\n<\/li>\n<\/ul>\n\nOn the control plane level:<\/i><\/p>\n\nApplication of routing and traffic balancing policies\n<\/li>\n Management of retries and timeouts, detection of 'dead' nodes (circuit breaking), management of failure scenarios (injecting faults), and ensuring resilience of services through other mechanisms\n<\/li>\n Authentication\/authorization of calls\n<\/li>\n Metric discarding (observability)\n<\/li>\n<\/ul>\n\nThe circle of users interested in developing this technology is very wide \u2014 from small startups to large internet corporations, such as PayPal.<\/p>\n
What is the purpose of Service Mesh in the corporate sector?<\/h2>\n \nUsing Service Mesh brings many obvious benefits. First and foremost, it is simply convenient for developers: for writing code a technological platform appears<\/i>, which significantly simplifies integration into cloud infrastructure by ensuring that the transport layer is completely isolated from the application logic.<\/p>\n
Additionally, Service Mesh simplifies the relationships between providers and consumers.<\/i> Today, API providers and consumers can negotiate interfaces and contracts much more easily, without the need for a special integration intermediary or arbiter \u2013 a corporate service bus. This approach has a significant impact on two metrics. The time to market for new features is reduced, but the cost of solutions increases, as integration must be done independently. Using a Service Mesh allows business functionality development teams to maintain a balance. As a result, API providers can focus solely on the application aspect of their service and simply publish it in the Service Mesh\u2014APIs will immediately become available to all clients, with integration quality being production-ready and requiring no additional lines of code.<\/p>\n
The next advantage is that the developer, using Service Mesh, focuses solely on business functionality<\/i> \u2014 on product details rather than the technological aspect of their service. For instance, there\u2019s no longer a need to worry about the possibility of a connection drop in scenarios where the service is called over a network. Furthermore, Service Mesh helps balance traffic between instances of the same service: if one instance goes down, the system routes all traffic to the remaining active instances. <\/p>\n
Service Mesh <\/i>\u2014 this provides a solid foundation for creating distributed applications<\/i>, which abstracts away from the client the details involved in making calls to its services from both inside and outside. All applications that use Service Mesh are isolated on a transport level from both the network and from each other: there is no connection between them. Meanwhile, the developer gains full control over their services.<\/p>\n
It\u2019s worth noting that updating distributed applications in an environment that uses Service Mesh becomes simpler.<\/i> For example, blue\/green deployment, where two application environments are available for installation, one of which is not updated and is on standby. Rollback to a previous version in case of an unsuccessful release is managed by a special router, which Service Mesh handles perfectly.. <\/i>A canary release can also be used for testing a new version. This means switching to the new version for only 10% of the traffic or requests from a pilot group of customers. The main traffic goes to the old version, so nothing breaks. <\/i>Service Mesh provides us with real-time SLA control.<\/p>\n
Also The distributed proxy system will prevent the service from crashing when a customer exceeds their allocated quota. If API throughput is limited, no one can DDoS it with a large number of transactions: Service Mesh stands in front of the service and prevents excess traffic. It will simply get repelled at the integration layer, while the services continue to operate without noticing it.<\/i>If a company wants to reduce costs for developing integration solutions, Service Mesh also comes to the rescue:<\/p>\n
with its open-source version, one can transition from commercial products. Our Enterprise Service Mesh is based on the open-source version of Service Mesh.<\/i>Another advantage is the availability of a comprehensive set of integration services. <\/p>\n
Since all integration is built through this intermediary layer, we can manage all integration traffic and relationships between applications that form the business core of the company. This is very convenient. Service Mesh encourages companies to transition to dynamic infrastructure.<\/i>Many are now looking towards containerization. Splitting a monolith into microservices and implementing it beautifully is a rising trend. However, when you try to convert to new rails a system that has been in production for many years, you immediately encounter a number of problems: it's not easy to shove everything into containers and deploy on the platform. The deployment, synchronization, and interaction of these distributed components is another complex subject. How will they communicate with each other? Will there be cascading failures? Service Mesh helps to solve some of these problems and facilitate migration from the old architecture to the new by allowing you to forget about the logic of network exchange.<\/p>\n
And finally Service Mesh encourages companies to migrate to dynamic infrastructure.<\/i> Currently, many are looking towards containerization. Splitting the monolith into microservices and implementing it beautifully is a trending topic. However, when you try to transition a system that has been in production for many years to new frameworks, you will immediately face a series of challenges: fitting everything into containers and deploying on the platform is not easy. Implementation, synchronization, and interaction of these distributed components is another extremely complex issue. How will they communicate with each other? Will there be cascading failures? Service Mesh helps resolve some of these issues and eases the migration from old architecture to new by allowing you to forget about the logic of network exchange.<\/p>\nWhy is Service Mesh customization needed?<\/h2>\n
\nOur company has hundreds of systems and modules coexisting, and the runtime is heavily loaded. Therefore, a simple pattern where one system calls another and receives a response is not enough because in production we want more. What else is needed from an enterprise Service Mesh? <\/p>\n
Event processing service<\/h3>\n \nImagine we need to implement real-time event processing \u2014 a system that analyzes customer actions in real-time and can immediately make a relevant offer. To achieve this functionality, we use an architectural pattern called event-driven architecture (EDA).<\/i>None of the current Service Mesh implementations natively support such patterns, and this is very important, especially for banks!<\/p>\n
It\u2019s quite strange that Remote Procedure Call (RPC) is supported by all versions of Service Mesh, while they are not compatible with EDA. This is because Service Mesh is similar to modern distributed integration, while EDA is a highly relevant architectural pattern that allows for unique client experience enhancements.<\/p>\n
Our Enterprise Service Mesh should address this issue. Additionally, we want to see the implementation of guaranteed delivery, streaming, and comprehensive event processing using various filters and templates.<\/p>\n
File transfer service<\/h3>\n \nBesides EDA, it would be beneficial to have the capability to transfer files: in enterprise settings, file-based integration is often the only option. Specifically, the Extract, Transform, Load (ETL) architectural pattern is used. In it, all parties typically exchange files exclusively: large datasets are utilized that are impractical to handle with individual requests. The native support for file transfer in Enterprise Service Mesh provides the business with the necessary flexibility.<\/p>\n
Orchestration service<\/h3>\n \nIn large organizations, there are almost always different teams working on different products. For instance, in a bank, some teams focus on deposits while others work on credit products, and there are many such cases. These are different people and different teams creating their own products, developing their APIs, and providing them to others. Often, there arises a need to compose these services and implement complex logic for sequential API calls. To address this challenge, a solution is required at the integration layer that simplifies this composite logic (calling multiple APIs, describing the request routes, etc.). This is what orchestration service in an Enterprise Service Mesh is all about.<\/p>\n
AI and ML<\/h3>\n \nWhen microservices communicate through a unified integration layer, the Service Mesh naturally knows everything about the calls of each service. 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, all this data accumulates and forms Big Data. This data can be analyzed using AI, machine learning, etc., and then useful insights can be derived from the analysis results. It would be appropriate to at least partially delegate the control of all this network traffic and application calls integrated into the Service Mesh to artificial intelligence.<\/p>\n
API Gateway Service<\/h3>\n \nTypically, a Service Mesh contains proxies and services that interact with each other within a trusted perimeter. However, there are also external parties involved. The requirements for the APIs provided to this group of consumers are much more stringent. We divide this task into two main parts. <\/p>\n
\nSecurity<\/i>Issues related to DDoS, protocol vulnerabilities, applications, operating systems, and so on. \n<\/li>\nScales<\/i>When the number of APIs that need to be provided to clients reaches thousands or even hundreds of thousands, there is a necessity for some kind of management tool for this set of APIs. It's essential to constantly monitor the APIs: whether they are operational, their status, the traffic, statistics, etc. The API Gateway must handle this task, making the entire process manageable and secure. Thanks to this component, the Enterprise Service Mesh learns to publish both internal APIs and external ones without unnecessary complexity.\n<\/li>\n<\/ul>\n <\/p>\n
A service for supporting specific protocols and data formats (AS gateway)<\/h3>\n \nAt present, most Service Mesh solutions can natively work only with HTTP and HTTP2 traffic or in a limited mode at the TCP\/IP level. The Enterprise Service Mesh has many other quite specific data transfer protocols. Some systems may use message brokers, while others are integrated at the database level. If a company has SAP, it may also use its own integration system. Moreover, all of this works and is an important part of the business.<\/p>\n
You cannot simply say: 'Let's abandon legacy systems and create new ones that can utilize Service Mesh.' To bridge all the old systems with the new ones (built on microservices architecture), systems that can use Service Mesh will need an adapter, intermediary, or gateway. Just imagine if it came packaged with the service. The AS gateway can support any integration option. Just think, you simply install the Enterprise Service Mesh, and it is already ready to interact with all the protocols you need. This approach is very important to us.<\/p>\n
This is how we envision the corporate version of Service Mesh (Enterprise Service Mesh). The described customization addresses most issues arising when attempting to use off-the-shelf open-source versions of the integration platform. Emerging only a couple of years ago, the Service Mesh architecture continues to evolve, and we are glad that we can contribute to its development. We hope our experience will be useful to you.<\/i>habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"Service Mesh \u2014 \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u043d\u044b\u0439 \u043f\u0430\u0442\u0442\u0435\u0440\u043d \u0434\u043b\u044f \u0438\u043d\u0442\u0435\u0433\u0440\u0430\u0446\u0438\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0438 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u043d\u0430 \u043e\u0431\u043b\u0430\u0447\u043d\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0432 \u043e\u0431\u043b\u0430\u0447\u043d\u043e-\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043d\u043e\u043c \u043c\u0438\u0440\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c \u0431\u0435\u0437 \u043d\u0435\u0433\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u043e. \u041d\u0430 \u0440\u044b\u043d\u043a\u0435 \u0443\u0436\u0435 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e open-source \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0439 service mesh, \u043d\u043e \u0438\u0445 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0441\u0442\u0438, \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0434\u0430\u043b\u0435\u043a\u043e \u043d\u0435 \u0432\u0441\u0435\u0433\u0434\u0430 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0438\u0434\u0435\u0442 \u043e \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u0445 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0439 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0430 \u0432\u0441\u0435\u0439 \u0441\u0442\u0440\u0430\u043d\u044b. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26549,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35388","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Why](\"\/wp-content\/uploads\/2019\/06\/90b0df34323399c96548f86b6bd16522.jpg\")