CC BY
79
COMPARATIVE ANALYSIS OF THE REST AND GRPC USED IN THE MONITORING SYSTEM OF COMMUNICATION NETWORK VIRTUALIZED INFRASTRUCTURE
DOI: 10.36724/2072-8735-2023-17-4-50-55
Igor G. Buzhin,
MTUCI, Moscow, Russia, i.g.buzhin@mtuci.ru Aleksey Yu. Derevyankin,
MTUCI, Moscow, Russia, alexeyderevyankin@yahoo.com Veronika M. Antonova,
MTUCI, Moscow, Russia, v.m.antonova@mtuci.ru Aleksey P. Perevalov,
MTUCI, Moscow, Russia, a.p.perevalov@mtuci.ru Yuriy B. Mironov,
MTUCI, Moscow, Russia, i.b.mironov@mtuci.ru
Manuscript received 16 March 2023; Accepted 14 April 2023
Keywords: microservice architecture, gRPC, REST, comparison, streaming
The analysis of papers related to data transmission in the microservice architecture is made. A monolithic networking architecture typically refers to a large computing network with a single software code base in which all service tasks are combined. To change this architecture, it is necessary to update the entire stack through a single code base and create an updated version of the interface on the service side. This approach makes it difficult to handle updates and increases the time for launching new services. A microservice application consists of many interacting services that can be freely updated, replaced or moved around, which makes it fundamentally different from the monolithic approach. A table with the comparison of the gRPC framework and the REST architectural style according to several criteria is given; it shows similarities and differences of the technologies considered. The results are presented as histograms illustrating the difference between the gRPC and REST in the number of requests when small and big data are transferred. The difference in latency while using the gRPC for different transfer types is shown.
Для цитирования:
Бужин И.Г., Деревянкин А.Ю., Антонова В.М., Перевалов А.П., Миронов Ю.Б. Сравнительный анализ REST и gRPC, используемых в системе мониторинга виртуализированной инфраструктуры коммуникационной сети // T-Comm: Телекоммуникации и транспорт. 2023. Том 17. №4. С. 50-55.
For citation:
Buzhin I.G., Derevyankin A.Yu., Antonova V.M., Perevalov A.P., Mironov Yu.B. (2023) Comparative Analysis of the REST and gRPC Used in the Monitoring System of Communication Network Virtualized Infrastructure. T-Comm, vol. 17, no.4, pр. 50-55. (in Russian)
Introduction
The development of Next Generation Mobile Networks, the Internet of Things and cloud services has led to a shift from monolithic to microservice architectures. A monolithic networking architecture typically refers to a large computing network with a single software code base in which all service tasks are combined. To change this architecture, it is necessary to update the entire stack through a single code base and create an updated version of the interface on the service side. This approach makes it difficult to handle updates and increases the time for launching new services. A microservice application consists of many interacting services that can be freely updated, replaced or moved around, which makes it fundamentally different from the monolithic approach.
Due to the fact that computing virtual networks are constantly evolving, there is an increase in the requirements for network parameters. Such requirements may include: types of nodes and their technical complexity, the cost of development and the amount of equipment, the bandwidth of communication channels, etc. In order to get a high-performance computing network with high bandwidth, when developing such a network, it is necessary to choose between tools for its construction and network infrastructure development.
A huge need for the introduction of software-configurable networks (SDN, Software-Defined Network) into computer communication networks arose due to the need to improve the efficiency of managing network elements. Software-configurable networks are data transmission networks in which the network management layer is separated from the data transmission layer and implemented programmatically by separate elements. Thanks to SDN technology, it has become possible to create flexible elements of network infrastructure, so the introduction of this approach into a computer network gives an advantage over networks in which it does not exist. When we use traditional network architectures, it is necessary to allocate a huge amount of money for the purchase of physical network devices. In the case of using SDN technology, it is possible to replace elements of the computer network with software.
The main reasons for the shift are complexity and scalability of the application. Overloading the architecture of a monolithic application with additional components greatly limits the ability to enhance the applied solution. Moreover, if one component of a monolithic applicationfails, the entire system may fail [1].
Each service has its own functionality of the application in use. A microservice may have the function of processing data generated by other microservice, in this case both services must describe communication interfaces. One of the popular architectural styles of microservice interaction is the REST technology. Its detailed specifications are given in [2]:
scalability of component interaction fault tolerance security
generalization of the interfaces easy to upgrade.
RESTful services are characterized by HTTP methods using the protocol described in RFC2616 [7]. Developers usually apply GET and POST methods. There are also such widely used methods as PUT, DELETE, PATCH, OPTIONS, although HTTP can have any other method [3].
The REST supports several types of data serialization for transmission, e.g. JSON, XML, form-data. However, the most popular is JSON. The main reason for using this format is its simplicity and lightweight design. If compared to XML, JSON is easier to read since it does not contain numerous constructors and repeating components, thus it makes communication through the REST API faster and more efficient than for example through SOAP, which is based solely on XML [4].
However, for a number of purposes there is a technology that can be used to transfer data in a microservice architecture more efficiently. That is data transfer using the Remote Procedure Call (RPC) protocol.
The control system is an important part of the computer network, the tasks of which include maintaining the availability of nodes, initializing the network interaction configuration and administration, as well as analyzing the technical condition of devices and network connections. All the described tasks relate to components for telemetry and network configuration.
Network monitoring is usually understood as the constant collection of data on the functioning of a computer network to perform such functions as: searching for slow, faulty or, conversely, underloaded systems, as well as the main consumers of network resources, fulfilling SLA parameters (service level agreements) and the quality of the service provided (for example, on-demand delivery of audio, video or other content, delays in connecting distributed and integrated systems). Along with the technical aspects listed above, monitoring is also understood as the supervision of the operation of the network, in the sense of monitoring compliance with access policies, information exchange and routing. The collected data may reflect different aspects of the network functioning, depending on the purpose and objectives of monitoring. Both meanings of the term monitoring proposed above are close to each other and rely on the same technologies for collecting and analyzing information.
Telemetry determines the possibilities of observability. Observability should be understood as a property of the system that characterizes the fundamental possibility of determining the state of the system by its output parameters. At the same time, a system is observable if there is a one-to-one correspondence between the measured output parameters and the state parameters of the system.
The observability of a computer network includes three methods: collection and processing of parameters (metrics), logging of network events, and tracing of network devices. The process of collecting metrics consists in the accumulation of system parameters for the purpose of subsequent visualization of the processed data. Parameters are collected from intermediate or terminal devices (nodes) of the network. To generate a message with metrics and its subsequent transmission to the telemetry system, the device is supplemented by an agent. Services, additional containers, additions to the device firmware, etc. can perform the functions of an agent. The network node sends metrics to the agent using the established protocol at regular intervals. The agent processes the metrics and sends generated messages with metrics to the telemetry system.
Thus, a comparative analysis of the REST and gRPC technologies, an experimental comparison of time delays in REST and gRPC operation, and recommendations for the use of the REST and gRPC in monitoring systems for communication network vir-tualized infrastructure should be made.
Comparative Analysis of the REST and gRPC
At present, the most popular RPC framework is the gRPC [8]. The gRPC is a relatively new open-source RPC framework, its functionality was developed by Google staff. The gRPC provides high performance and secure connectivity between services, and supports different types of data streaming. High performance and transmission speed is ensured by the Protocol Buffers serialization protocol (protobuf) and by the HTTP/2 protocol used for data transmission [4].
The paradigm used by the gRPC framework is based on the utilization of the remote procedure call protocol. As opposed to the REST, RPC employs a function call between client and server but not an HTTP call. The client calls a remote procedure which is implemented on the server side. Having received the call from the client the server, in turn, carries out the called function and transmits the result to the client. In [5], the operating principle of the protocol is described.
The gRPC technology allows four types of transmission to be identified [6]:
1. Unary calls where the client sends a request to the server and receives one response back.
2. Server-side streaming calls where the client sends a request to the server and gets a stream to read a sequence of messages back. The client reads from the returned stream until there are no more messages from the server side.
3. Client-side streaming calls. With this type of transmission the client sends a stream of messages to the server, and a server, in turn, receives all the messages and returns its response as one message to the client.
4. Bidirectional (duplex) streaming calls where both sides send a stream of messages. The streams operate independently, so clients and servers can read and write in whatever order they like.
Using the RPC protocol for inter-service communication brings some advantages to any transmission system. One of the main advantages is abstracting the developer from many mechanisms related to network communication. The developer can instead focus on the functionality issues of the application being developed. In [4] provides some advantages of gRPC framework application:
1. Strong data serialization using the protobuf protocol. Protobuf allow defining messages consisting of the basic data types such as integer, string, or boolean, as well as more complex messages with multiple nested structures inside. It enables to define own enumerations or messages and use them as a reference in other messages. Strong serialization involves raising an exception by the library if the message is missing the required field.
2. The application of the HTTP/2 protocol for data transmission. This protocol is described in RFC 7540 [9]. The principal change between this version and the previous ones is that HTTP/2 is a binary-based protocol. Several logical streams are formed when the connection between devices is set up. Each stream consists of a number of messages. Lastly, each message is comprised of a set of small binary frames. Each frame contains a special identifier that canbe used to alternate these frames during transmission and collect them at the other end. HTTP/2 supports asynchronous request processing - request and responses can be processed in parallel without blocking other messages, therefore messages in the queue do not wait for others to be processed. This process is also referred to as multiplexing. Together, the parallel streams
form a single constant TCP connection thereby reducing the waste of memory and processing power. Figure 1 shows the difference in request handling for the HTTP 1.1 and HTTP 2 versions of the protocol.
Fig. 1. Timing diagrams of request processing for the HTTP 1.1 and HTTP 2
3. The support of channel security mechanisms. The gRPC supports a variety of authentication techniques:
• The SSL/TLS can be used for the server authentication and encryption of the channel between the client and the server.
• Authentication based on JWT-tokens. The tokens are transmitted as metadata credentials over the channel protected by means ofthe SSL/TLS.
• The support of Application Layer Transport Security (or ALTS). This authentication transport encryption system is used in case services are running on Google cloud platform (GCP).
These authentication techniques are suitable for both internal service-to-service interaction and external API.
4. Transmitted data compression. The HTTP/2 employs HPACK compression that reduces the size of the transmitted frame header. The HTTP/1.1 utilizes gzip for data compression, and the message header is sent as a simple text without being compressed. The HPACK specification compares header metadata fields to previously transmitted header fields and compresses the header according to static and dynamic tables, which define the modifiability of one or another field.
5. Providing high performance. By means of protobuf serialization, HTTP/2 transmission protocol, HPACK compression, stream multiplexing, the gRPC provides the high performance. If compared to the REST, the gRPC can transmit and receive data much faster. Specific comparison results will be shown further in the paper.
6. Easy code generation for developing an API application. The gRPC provides tools for generating code for both the client and server sides according to proto files using the protoc utility. The service supports different programming languages, including Golang, C++, Java, Ruby, Python and more. The generated code provides functionality to set message parameters, marshaling/un-marshaling of messages, as well as to set up the connection between the client and the server. Moreover, the REST has tools for RESTful API description such as Swagger, Mashape, Apiary.
Table 1 below compares the technologies according to the criteria given above.
Table 1
Comparison ofthe gRPC and REST
"\Technology Criteria gRPC REST
Data serialization (basic) Protobuf JSON/XML
Data transmission protocol HTTP/2, asynchronous frame transmission HTTP/1.1
Safety tools Supports SSL/TLS for connection security, various authentication and authorization mechanisms. In addition, security tools developed by Google are supported Supports SSL/TLS for connection security, various authentication and authorization mechanisms. A wide range of options for establishing a secure connection link.
Transmitted data compression HPACK, supports header compression GZIP, header compression is not available
Performance Faster than the REST when transferring massive data. If compared to the REST, it has insignificant performance advantage when low pay-load is conveyed. Slower than the gRPC when transferring massive data. If compared to the gRPC, it has insignificant performance advantage when low pay-load is conveyed.
Code generation tools Has built-in code generation tools. In most cases, system implementation is more complex and time-consuming. Built-in code generation tools are not available. Swagger, Mashape, Apiary and more can be used. Many objectives can be achieved much more easily and quickly than using the gRPC.
Each application (client-side) ran in a docker container and transmitted the payload to an agent (server-side) using the pre-de-termined technology. The agent, in turn, took measurements and broadcast them to the monitoring tools as metrics. The conjunction of Grafana and Prometheus were used as the metrics monitoring and visualisation tools. For the docker container orchestration tools, a Kubernetes cluster was deployed by means of the local cluster startup tool called kind. The resulting data were analyzed and presented in graphs and histograms using gnuplot software. Figure 2 shows a sample diagram of the deployed cluster employed for taking test measurements.
The table shows that despite the higher performance and capacity of the gRPC, it is the REST technology that is preferable to be used for a certain number of tasks. The principal reasons for using the REST are its wide acceptance, support, and simplicity. However, a continuous stream of massive data is an example where a system implemented with the gRPC is more appropriate.
Experimental Comparison of Time Delays for the REST and gRPC in the Monitoring System of Communication Network Virtualized Infrastructure
In order to compare the gRPC and REST technologies, test measurements of the technologies were carried out during payload transfer. The measurements were made on a computing machine with the following parameters:
• CPU: Intel(R) Core (TM) i5-10300H CPU @ 2.50GHz 2.50 GHz
RAM: 16 GB
OS version: Ubuntu 20.04.5 LTS, amd64 Golang version: 1.19.4 gRPC: 1.51.0 protobuf: vl.28.0.
Fig. 2. A diagram ofthe test cluster stand
Goland was used as a programming language for developing the applications. The principal advantages of this programming language are its simplicity, speed and proper support with standard libraries.
The size of small data transmitted as payload can be considered negligible, while massive data were transferred with some optional payload of 437 kB added to them. This choice of the data size is not random but is due to the restriction imposed on the size of the data field in the gRPC. To measure the number of connections, an appropriate software counter has been defined. After each connection was completed, the counter was incremented by one. The time library built into the Go programming language was used to measure the latency of each connection.
Figure 3 shows the result of the experiment during which small and large data are conveyed between the client and the server. If small size information is transmitted as the payload, the amount of the data transmitted is slightly higher with the gRPC. In some cases the technologies can set up an equal number of connections.
When massive data are transferred, the number of calls increases by about 6 times. During the experiment, unary calls were used as a type of transmission. The comparison of the REST to different types of transmission in the gRPC is given further in the article.
As mentioned above, the gRPC has 4 types of transmission: unary calls, server/client stream calls and duplex stream calls. Figure 4 demonstrates the results of comparing the different gRPC transmission types to the REST. When checked, the latency of the server and client procedure calls appeared to be similar, therefore these types are merged into a single result. It is also worth considering that the call is regarded as completed when the side setting up the connection completes it.
Fig. 3. Comparison ofthe number ofcompleted connections between the application and the agent while transmitting small and big data in 60 seconds
Fig. 4. Results of comparing the different gRPC transmission types to the REST (of 3 types of transmission) while transferring low and high payload
The results given above show that for small data transfers, there is a difference in delay between the REST's HTTP call and the gRPC's unary call, but after some REST API optimization it is possible to achieve closer values. In the case of streaming small data transfers, the latency is reduced for the two types of transfers. This fact can be explained as follows: in streaming, data is partitioned and transmitted asynchronously. When massive data are transmitted, the gRPC has the performance advantage of about 5 times higher for unary calls and about 7-8 times higher for streaming. It is worth noting that for bidirectional streaming, the payload of 437 kB was transmitted in both directions.
Conclusion
Thus, the comparison of data transmission technologies in the gRPC and REST microservice architecture allows us to infer that HTTP call techniques should be combined with remote procedure calls to build systems for transferring information
between services. Despite the growing popularity of the gRPC technology for data transfer, it is worth evaluating both its advantages and disadvantages, since this affects the quality of the developed system and the final resources consumption required for the system development.
Objectives necessitating high-performance transmission of massive data are recommended to be achieved by using one of the gRPC types of transferring. For implementing small data transmission systems or for implementing complex transmission systems, it is worth using the fully developed REST API.
References
1. Malichenko S. The Problem of Switching from Monolithic to Microservice Architectures. Euroasian Scientific Journal, no.5, 2022, pp. 1-13.
2. Fielding R.T. Architectural Styles and the Design of Network-based Software Architectures. Dissertation, University of California, Irvine, 2000.
3. Cheglakov A. Web-service composition based on REST architecture. International scientific journal "Innovation Science", no.12-2, ISSN 24106070, 2016, pp. 118-120.
4. Michal Stefanic. Developing the guidelines for migration from RESTful microservices to gRPC. Masaryk University, Faculty of Informatics, Brno, 2021, pp.1-81.
5. The official site of Microsoft. RPC Operation. Available at: https://learn.microsoft.com/ru-ru/windows/win32/rpc/how-rpc-works (Accessed December 15, 2022).
6. The official site of gRPC. Introduction to gRPC. Available at: https://grpc.io/docs/what-is-grpc/introduction/ (Accessed December 15, 2022).
7. Fielding R. etal. RFC2616: Hypertext Transfer Protocol. HTTP/1.1. 1999.
8. Pourhabibi A. et al. Cerebros: Evading the RPC tax in datacenters.jM-CRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture. 2021, pp. 407-420.
9. Kosek M., Shreedhar T., Bajpai V. Beyond quic vl: A first look at recent transport layer IETF standardization efforts. IEEE Communications Magazine. 2021. Vol. 59. No. 4, pp. 24-29.
10. Buzhin I.G., Antonova V.M., Gaifutdinov E.A., Mironov Yu.B. (2022) Methodology for a comprehensive assessment of the telecommunication services quality of transport networks using SDN/NFV technologies. T-Comm, vol. 16, no.12, pp. 40-45.
11. Vilalta R. et al. GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels. 45th European Conference on Optical Communication (ECOC 2019). IET, 2019, pp. 1-4.
12. Vilalta R. et al. Telemetry-enabled cloud-native transport SDN controller for real-time monitoring of optical transponders using gNMI. 2020 European Conference on Optical Communications (ECOC). IEEE, 2020, pp. 1-4.
13. Sgambelluri A. et al. Open source implementation ofOpenConfig telemetry-enabled NETCONF agent. 2019 21st International Conference on Transparent Optical Networks (ICTON). IEEE,2019,pp. 1-4.
14. Lui N., Hill J. H. A generalized approach to real-time, non-intrusive instrumentation and monitoring of standards-based distributed middleware. Journal of Systems Architecture.202l.Vol. 117,pp. 102-181.
15. Munoz R. et al. Dynamic Reconfiguration of WDM Virtual Network Topology over SDM Networks for Spatial Channel Failure Recovery with gRPC Telemetry. 2022 Optical Fiber Communications Conference and Exhibition (OFC). IEEE, 2022, pp. 1-3.
16. Indrasiri K., Kuruppu D. gRPC: up and running: building cloud native applications with Go and Java for Docker and Kubernetes. O'Reilly Media, 2020.
17. Moseva M.S. (2022) About methods for collecting and analyzing traffic flow characteristics. T-Comm. Vol. 16, no.2, pp. 29-38.
18. Antonova V.M., Malikova E.E., Panov A.E., Spichek I.V., Malikov A.Y. Implementation of IoT technology for data monitoring via cloud services. T-Comm, 2021. Vol. 15, no.2, pp. 46-53.
19. Albab K. D. et al. SwitchV: automated SDN switch validation with P4 models. Proceedings of the ACM SIGCOMM 2022 Conference. 2022, pp. 365-379.
20. El Kholy M., El Fatatry A. Framework for interaction between databases and microservice architecture. IT Professional. 2019. Vol. 21. No. 5, pp. 57-63.
21. Vilalta R. et al. GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels.45th European Conference on Optical Communication (ECOC 2019). IET, 2019, pp. 1-4.
СРАВНИТЕЛЬНЫЙ АНАЛИЗ REST И GRPC, ИСПОЛЬЗУЕМЫХ В СИСТЕМЕ МОНИТОРИНГА ВИРТУАЛИЗИРОВАННОЙ ИНФРАСТРУКТУРЫ КОММУНИКАЦИОННОЙ СЕТИ
Бужин Игорь Геннадьевич, МТУСИ, Москва, Россия, i.g.buzhin@mtuci.ru Деревянкин Алексей Юрьевич, МТУСИ, Москва, Россия, alexeyderevyankin@yahoo.com Антонова Вероника Михайловна, МТУСИ, Москва, Россия, v.m.antonova@mtuci.ru Перевалов Алексей Павлович, МТУСИ, Москва, Россия, a.p.perevalov@mtuci.ru Миронов Юрий Борисович, МТУСИ, Москва, Россия, i.b.mironov@mtuci.ru
Аннотация
Реализация концепции цифровой экономики Российской Федерации сопровождается возрастанием объемов и расширением функциональных возможностей предоставляемых сервисов, повышением требований к информационной безопасности информации, что, в свою очередь, влечет за собой усложнение механизмов управления систем и сетей связи. В связи с этим появилась необходимость отделения функции управления от функции передачи данных телекоммуникационного оборудования, что является основой технологии SDN/NFV. Несмотря на рост популярности технологии gRPC для передачи данных стоит оценивать, как достоинства, так и его недостатки, так как от этого зависит качество разработанной системы и итоговый расход ресурсов на разработку системы. Для достижения поставленной цели были решены следующие задачи: 1. Проанализированы работы, затрагивающие тему передачи информации в микросервисной архитектуре; 2. Приведена таблица сравнения фреймворка gRPC и архитектурного стиля REST по нескольким критериям, показывающая сходства и различия анализируемых технологий; 3. Приведены результаты в виде гистограмм, показывающих разницу gRPC и REST по количеству запросов при передаче малых и больших данных; 4. Показана разница в задержке с использованием gRPC при разных типах передач. Разработанная методика может быть полезной для проведения исследовательских работ и на этапе проектирования сетей связи.
Ключевые слова: микросервисная архитектура, gRPC, REST, сравнение, потоковая передача. Литература
1. Маличенко С. Проблемы перехода от монооитной к мультисервисной архитектуре // Euroasian Scientific Journal, № .5, 2022. С. 1-13.
2. Fielding R.T. Architectural Styles and the Design of Network-based Software Architectures // Dissertation, University of California, Irvine, 2000.
3. Чеглаков А. Композиция WEB-сервисов на основе архитектуры REST // International scientific journal "Innovation Science", № 12-2, ISSN 24106070, 2016. С. 118-120.
4. Michal Stefanic. Developing the guidelines for migration from RESTful microservices to gRPC // Masaryk University, Faculty of Informatics, Brno, 2021, pp.1-81.
5. The official site of Microsoft. RPC Operation. Available at: https://learn.microsoft.com/ru-ru/windows/win32/rpc/how-rpc-works (Accessed December 15, 2022).
6. The official site of gRPC. Introduction to gRPC. Available at: https://grpc.io/docs/what-is-grpc/introduction/ (Accessed December 15, 2022).
7. Fielding R. et al. RFC26I6: Hypertext Transfer Protocol--HTTP/I.l. 1999.
8. Pourhabibi A. et al. Cerebros: Evading the RPC tax in datacenters //MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture. 2021, pp. 407-420.
9. Kosek M., Shreedhar T., Bajpai V. Beyond quic vl: A first look at recent transport layer ietf standardization efforts // IEEE Communications Magazine. 2021. Vol. 59. -No. 4, pp. 24-29.
10. Buzhin I.G., Antonova V.M., Gaifutdinov E.A., Mironov Yu.B. (2022) Methodology for a comprehensive assessment of the telecommunication services quality of transport networks using SDN/NFV technologies // T-Comm: Телекоммуникации и транспорт. Т. 16, № 12. С. 40-45.
11. Vilalta R. et al. GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels //45th European Conference on Optical Communication (ECOC 2019). IET, 2019, pp. 1-4.
12. Vilalta R. et al. Telemetry-enabled cloud-native transport SDN controller for real-time monitoring of optical transponders using gNMI // 2020 European Conference on Optical Communications (ECOC). IEEE, 2020, pp. 1-4.
13. Sgambelluri A. et al. Open source implementation of OpenConfig telemetry-enabled NETCONF agent // 2019 21st International Conference on Transparent Optical Networks (ICTON). IEEE, 2019, pp. 1-4.
14. Lui N., Hill J. H. A generalized approach to real-time, non-intrusive instrumentation and monitoring of standards-based distributed middleware // Journal of Systems Architecture. 2021. Т. 117, pp. 102-181.
15. Munoz R. et al. Dynamic Reconfiguration of WDM Virtual Network Topology over SDM Networks for Spatial Channel Failure Recovery with gRPC Telemetry // 2022 Optical Fiber Communications Conference and Exhibition (OFC). IEEE, 2022, pp. 1-3.
16. Indrasiri K., Kuruppu D. gRPC: up and running: building cloud native applications with Go and Java for Docker and Kubernetes. O'Reilly Media, 2020.
17. Moseva M.S. About methods for collecting and analyzing traffic flow characteristics. T-Comm: Телекоммуникации и транспорт, 2022. Т. 16. №2. С. 29-38.
18. Antonova V.M., Malikova E.E., Panov A.E., Spichek I.V., Malikov A.Y. Implementation of IoT technology for data monitoring via cloud services. T-Comm: Телекоммуникации и транспорт. 2021. №2. С. 46-53.
19. Albab K. D. et al. SwitchV: automated SDN switch validation with P4 models // Proceedings of the ACM SIGCOMM 2022 Conference. 2022. С. 365379.
20. El Kholy M., El Fatatry A. Framework for interaction between databases and microservice architecture // IT Professional. 2019. Т. 21. №. 5. С. 57-63.
21. Vilalta R. et al. GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels // 45th European Conference on Optical Communication (ECOC 2019). IET, 2019. С. 1-4.
