INTELLIGENT SERVICE MESH DATA COMPRESSION

Intelligent compression of data through a service mesh depending on size and frequency of existing service-to-service communications, relative workloads of the individual microservices, and time of day when large amounts of aggregate network traffic is expected to occur. Compression is enabled on a selective basis, based on user profiles, the size of data being transmitted and/or compression is applied broadly for all data being routed when aggregated amounts of network traffic exceeds threshold levels at particular times of day. Friendly Neighbor Compression Protocol enables data routing through trusted microservices of the service mesh having the same or similar standard and/or security requirements as the microservices of the microservice chain. When computing resources of microservice chains are limited or scarce, service mesh routes data from the microservice chain to trusted microservices for data compression, then re-routes the compressed data to the next microservice of the microservice chain.

BACKGROUND

The present disclosure relates generally to the field of microservice architecture, and more specifically to service meshes, communication between microservices and intelligent compression of data routed through microservice chains by the service mesh.

A service mesh provides a way to control how different parts of an application share data with one another. The service mesh is a dedicated infrastructure layer built right into an application. This visible infrastructure layer can document how well different parts of an application interact with one another, making it easier to optimize communication and avoid downtime as an application grows and changes over time. Each part of the application is called a “service,” and the services rely on other services to complete transactions, tasks or other functions requested by users. Modern applications are often broken down into this microservice architecture, whereby a network of services each perform a specific business function. In order to execute its function, one service might need to request data from several other services. The service mesh routes requests from one service to the next, optimizing how all the moving parts of the network of microservices work together. For cloud-native applications built in a microservices architecture, a service mesh is a way to comprise many discrete services into a functional application. The service mesh takes the logic governing service-to-service communication out of individual services and abstracts it to a layer of infrastructure. A microservices architecture lets developers make changes to an application's services without the need for a full redeploy. Unlike application development in other architectures, individual microservices can be built by small teams with the flexibility to choose their own tools and coding languages. Microservices are built independently, communicate with each other, and can individually fail without escalating into an application-wide outage.

SUMMARY

Embodiments of the present disclosure relate to a computer-implemented method, an associated computer system and computer program products for intelligently compressing data routed through a service mesh using a Friendly Neighbor Compression protocol. The computer-implemented method comprises collecting, by the service mesh, service mesh metrics into a database that is tracking microservices of the service mesh being used for each call, and a size of data sent between microservices of one or more microservice chains, for each user profile submitting application programming interface (API) calls to the service mesh; performing, by the service mesh, a resource trend analysis of a first microservice chain using the database to identify resource availability of the microservices within the first microservice chain configured to compress data being routed by the service mesh in response to an incoming API call; predicting, by the service mesh, resource constraints of a first microservice within the first microservice chain based on the resource trend analysis; searching, by the service mesh, for a second microservice that resides outside of the first microservice chain, wherein the second microservice is within a same network or namespace as the first microservice chain, and the second microservice has freely available resources to compress the data routed by the service mesh in response to the incoming API call; and routing, by the service mesh, uncompressed data of the incoming API call through the first microservice to the second microservice.

Embodiments of the present disclosure also relate to a computer-implemented method, an associated computer system and computer program products for intelligently compressing data routed through a service mesh based on type of usage, user profile specific routing and/or aggregated network traffic during periods of time. The computer-implemented method comprising collecting, by the service mesh, service mesh metrics into a database that is tracking microservices of the service mesh being used for each application programming interface (API) call, size of data sent between microservices of one or more microservice chains for each user profile submitting API calls to the service mesh, and a period of time each API call is performed by the service mesh routing data through the microservices of the service mesh; configuring, by the service mesh, a threshold for compressing data routed between microservices of the service mesh, wherein the threshold is configured as a function of historical metrics of the database for each user profile and each microservice of the service mesh; receiving, by the service mesh, an API call requesting transmission of data to a microservice of the service mesh via a microservice chain; identifying, by the service mesh, whether the transmission of the data to the microservice via the microservice chain triggers the threshold for compressing data; upon triggering the threshold for compressing data, compressing, by the service mesh, the data at a first microservice of the microservice chain; and routing, by the service mesh, data compressed by the first microservice of the microservice chain to a second microservice of the microservice chain.

DETAILED DESCRIPTION

Overview

As computing environments delivering computing services to customers transition from legacy architectures to a microservice architecture, many new challenges have arisen because of the changes in how services are delivered to customers. Large amounts of datasets and learning data are transferred between the many different services of the cloud-based environments. When the amount of data being transferred between services reach certain sizes, compression can be implemented to help reduce and/or minimize bloating on the network. In currently available microservice architectures, microservices can communicate through a service mesh comprising a plurality of microservices conducting service-to-service communication. However, as the service mesh experiences large dataset transmission or frequent dataset transmission, that may be re-occurring between microservices of the network, compression of the data is applied indiscriminately across all services. Current service mesh networks do no not apply the compression intelligently based on the users, expected network traffic and/or availability of resources using alternative data routing rules. The one-size fits all compression approach can result in a problem wherein compression may be occurring where compressing the data may not be necessary. For example, compression of data may be applied to all microservices the same, including the application of compression where data is sent using highly trafficked microservices, microservices with less traffic, microservices with less available resources and microservices with plenty of spare computing resources.

Embodiments of the present disclosure recognize that the need for data compression for service-to-service communications within a service mesh may vary based on a plurality of factors. For example, usage by individual users or user profiles, usage patterns, the time of day and the overall aggregate amount of network traffic. Compression of data within the service mesh may vary depending on the size and frequency of existing service-to-service communications being requested by users, the relative workloads of the individual services, and the times of day when high network traffic is expected to occur. Embodiments of the present disclosure may leverage cognitive computing and analysis of historical service mesh metrics collected by the service mesh to intelligently apply compression on a selective basis, as needed. Selective applications of data compression may be applied based on the user profile transmitting data, the aggregated amount of network traffic when requests are predicted to be made, the time of day and the workloads being run by the services of the service mesh.

In some situations, a Friendly Neighbor Compression Protocol may be enabled by the service mesh and/or service mesh control plane. Friendly Neighbor Compression protocols route data through trusted services of the service mesh within the same network and namespace as a microservice chain being invoked. These trusted services may be microservices and/or proxies having the same, similar and/or equivalent standards and/or security requirements as the services within the microservice chain requested to receive the data being sent. Trusted services intercalated into the microservice chain may be under-utilized services that have available computing resources to assist with compression of data on behalf of the microservice chain. The trusted service may receive the uncompressed data being routed by the service mesh from a microservice or a proxy of the microservice within the microservice chain, compress the data, and route the compressed data through the service mesh to the next microservice or proxy of the microservice chain, reducing the overall computing resource requirements of the microservice chain, while taking advantage of the underutilized computing resources of the trusted services to perform data compression.

Computing System

FIG.1Aillustrates a block diagram describing an embodiment of a computing system100, which may be a simplified example of a computing device (i.e., a physical bare metal system and/or a virtual system) capable of performing the computing operations described herein. Computing system100may be representative of the one or more computing systems or devices implemented in accordance with the embodiments of the present disclosure and further described below in detail. It should be appreciated thatFIG.1Aprovides only an illustration of one implementation of a computing system100and does not imply any limitations regarding the environments in which different embodiments may be implemented. In general, the components illustrated inFIG.1Amay be representative of any electronic device, either physical or virtualized, capable of executing machine-readable program instructions.

AlthoughFIG.1Ashows one example of a computing system100, a computing system100may take many different forms, including bare metal computer systems, virtualized computer systems, container-oriented architecture, microservice-oriented architecture, etc. For example, computing system100can take the form of real or virtualized systems, including but not limited to desktop computer systems, laptops, notebooks, tablets, servers, client devices, network devices, network terminals, thin clients, thick clients, kiosks, mobile communication devices (e.g., smartphones), multiprocessor systems, microprocessor-based systems, minicomputer systems, mainframe computer systems, smart devices, and/or Internet of Things (IoT) devices. The computing systems100can operate in a local computing environment, networked computing environment, a containerized computing environment comprising one or more pods or clusters of containers, and/or a distributed cloud computing environment, which can include any of the systems or devices described herein and/or additional computing devices or systems known or used by a person of ordinary skill in the art.

Computing system100may include communications fabric112, which can provide for electronic communications among one or more processor(s)103, memory105, persistent storage106, cache107, communications unit111, and one or more input/output (I/O) interface(s)115. Communications fabric112can be implemented with any architecture designed for passing data and/or controlling information between processor(s)103(such as microprocessors, CPUs, and network processors, etc.), memory105, external devices117, and any other hardware components within a computing system100. For example, communications fabric112can be implemented as one or more buses, such as an address bus or data bus.

Memory105and persistent storage106may be computer-readable storage media. Embodiments of memory105may include random access memory (RAM) and/or cache107memory. In general, memory105can include any suitable volatile or non-volatile computer-readable storage media and may comprise firmware or other software programmed into the memory105. Program(s)114, application(s), processes, services, and installed components thereof, described herein, may be stored in memory105and/or persistent storage106for execution and/or access by one or more of the respective processor(s)103of the computing system100.

Persistent storage106may include a plurality of magnetic hard disk drives, solid-state hard drives, semiconductor storage devices, read-only memories (ROM), erasable programmable read-only memories (EPROM), flash memories, or any other computer-readable storage media that is capable of storing program instructions or digital information. Embodiments of the media used by persistent storage106can also be removable. For example, a removable hard drive can be used for persistent storage106. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer-readable storage medium that is also part of persistent storage106.

Communications unit111provides for the facilitation of electronic communications between computing systems100. For example, between one or more computer systems or devices via a communication network. In the exemplary embodiment, communications unit111may include network adapters or interfaces such as a TCP/IP adapter cards, wireless interface cards, or other wired or wireless communication links. Communication networks can comprise, for example, copper wires, optical fibers, wireless transmission, routers, load balancers, firewalls, switches, gateway computers, edge servers, and/or other network hardware which may be part of, or connect to, nodes of the communication networks including devices, host systems, terminals or other network computer systems. Software and data used to practice embodiments of the present disclosure can be downloaded to the computing systems100operating in a network environment through communications unit111(e.g., via the Internet, a local area network, or other wide area networks). From communications unit111, the software and the data of program(s)114or application(s) can be loaded into persistent storage116.

One or more I/O interfaces115may allow for input and output of data with other devices that may be connected to computing system100. For example, I/O interface115can provide a connection to one or more external devices117such as one or more smart devices, IoT devices, recording systems such as camera systems or sensor device(s), input devices such as a keyboard, computer mouse, touch screen, virtual keyboard, touchpad, pointing device, or other human interface devices. External devices117can also include portable computer-readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. I/O interface115may connect to human-readable display118. Human-readable display118provides a mechanism to display data to a user and can be, for example, computer monitors or screens. For example, by displaying data as part of a graphical user interface (GUI). Human-readable display118can also be an incorporated display and may function as a touch screen, such as a built-in display of a tablet computer.

FIG.1Bprovides an extension of the computing system100environment shown inFIG.1Ato illustrate that the methods described herein can be performed on a wide variety of computing systems that operate in a networked environment. Types of computing systems100may range from small handheld devices, such as handheld computer/mobile telephone110to large mainframe systems, such as mainframe computer170. Examples of handheld computer110include personal digital assistants (PDAs), personal entertainment devices, such as Moving Picture Experts Group Layer-3 Audio (MP3) players, portable televisions, and compact disc players. Other examples of information handling systems include pen, or tablet computer120, laptop or notebook computer130, workstation140, personal computer system150, and server160. Other types of information handling systems that are not individually shown inFIG.1Bare represented by information handling system180.

Many of the computing systems can include nonvolatile data stores, such as hard drives and/or nonvolatile memory. The embodiment of the information handling system shown inFIG.1Bincludes separate nonvolatile data stores (more specifically, server160utilizes nonvolatile data store165, mainframe computer170utilizes nonvolatile data store175, and information handling system180utilizes nonvolatile data store185). The nonvolatile data store can be a component that is external to the various computing systems or can be internal to one of the computing systems. In addition, removable nonvolatile storage device145can be shared among two or more computing systems using various techniques, such as connecting the removable nonvolatile storage device145to a USB port or other connector of the computing systems. In some embodiments, the network of computing systems100may utilize clustered computing and components acting as a single pool of seamless resources when accessed through network250by one or more computing systems. For example, such embodiments can be used in a datacenter, cloud computing network, storage area network (SAN), and network-attached storage (NAS) applications.

As shown, the various computing systems100can be networked together using computer network250. Types of computer network250that can be used to interconnect the various information handling systems include Local Area Networks (LANs), Wireless Local Area Networks (WLANs), home area network (HAN), wide area network (WAN), backbone networks (BBN), peer to peer networks (P2P), campus networks, enterprise networks, the Internet, single tenant or multi-tenant cloud computing networks, the Public Switched Telephone Network (PSTN), and any other network or network topology known by a person skilled in the art to interconnect computing systems100.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Referring to the drawings,FIG.3is an illustrative example of a cloud computing environment300. As shown, cloud computing environment300includes a cloud network350comprising one or more cloud computing nodes310with which end user device(s)305a-305n(referred to generally herein as end user device(s)305) or client devices, may be used by cloud consumers to access one or more software products, services, applications, and/or workloads provided by cloud service providers or tenants of the cloud network350. Examples of the user device(s)305are depicted and may include devices such as a desktop computer, laptop computer305a, smartphone305bor cellular telephone, tablet computers305cand smart devices such as a smartwatch305nand smart glasses. Nodes310may communicate with one another and may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment300to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of end user devices shown inFIG.3are intended to be illustrative only and that computing nodes310of cloud computing environment300can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now toFIG.4, a set of functional abstraction layers provided by cloud computing environment300is shown. It should be understood in advance that the components, layers, and functions shown inFIG.4are intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

Hardware and software layer460includes hardware and software components. Examples of hardware components include mainframes461; RISC (Reduced Instruction Set Computer) architecture-based servers462; servers463; blade servers464; storage devices465; and networks and networking components466. In some embodiments, software components include network application server software467and database software468.

Virtualization layer470provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers471; virtual storage472; virtual networks473, including virtual private networks; virtual applications and operating systems474; and virtual clients475.

Management layer480may provide the functions described below. Resource provisioning481provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment300. Metering and pricing482provide cost tracking as resources are utilized within the cloud computing environment300, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal483provides access to the cloud computing environment300for consumers and system administrators. Service level management484provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment485provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.

Workloads layer490provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include software development and lifecycle management491, data analytics processing492, multi-cloud management493, transaction processing494; database management495and application UI201for one or more application(s)203.

System for Implementing a Service Mesh with Intelligent Data Compression

The instant features, structures, or characteristics as described throughout this specification may be combined or removed in any suitable manner in one or more embodiments. For example, the usage of the phrases “example embodiments,” “some embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment. Accordingly, appearances of the phrases “example embodiments,” “in some embodiments,” “in other embodiments,” or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Further, in the Figures, any connection between elements can permit one-way and/or two-way communication even if the depicted connection is a one-way or two-way arrow. Also, any device depicted in the drawings can be a different device. For example, if a mobile device is shown sending information, a wired device could also be used to send the information.

Referring to the drawings,FIG.2depicts an embodiment of a computing environment200illustrating a microservice architecture that can be executed on one or more computing systems100and variations thereof. As illustrated in the embodiment of the computing environment200depicted inFIG.2, a plurality of planes (or layers) of the environment are placed in communication with one another. As depicted, the computing environment200includes (but is not limited to) an application plane or layer comprising one or more application(s)203, a control plane207and a data plane209.

Embodiments of the application layer may be the layer of the network comprising one or more application(s)203and/or services that may make requests for network functions from the control plane207and/or data plane209. The combination of the control plane207and the data plane209make up the service mesh211. Users accessing the applications203of the application layer may input the requests for services and/or functions of the network by interacting with a user interface (UI) of the application203. For example, the application UI201shown inFIG.2. End user devices or client devices may request the services or functions from the planes of the service mesh211by inputting or transmitting requests via the application UI201to the service mesh control plane205of the network and/or to one or more microservices215a-215n(generally referred to herein as microservices215or services215). Embodiments of the application UI201may be part a mobile application, web application, SaaS application, etc. For example, mobile applications may be inputting requests and routing data through the service mesh211by transmitting an API call to an API gateway of the network. In other examples, clients may be using a command line interface (CLI) to input commands to the service mesh211of the data plane209and/or the service mesh control plane205, and/or a web-based UI transmitting an HTTP request via a web browser.

In some embodiments, the application203accessing and inputting commands into the computing environment200may be a control plane UI being accessed by one or more administrators of the microservices215. Administrators of the service mesh211may be able to obtain an overview of applications203running on the service mesh211, including a view of applications on each cluster, create or modify computing resources of the service mesh211; deploy instances213a-213nof services215which may be instantiated as part of a pod, container or cluster; scale service mesh211deployments; instances213of service215; restart pods or containers and/or deploy new applications or services215.

Embodiments of the control plane207of the service mesh211, may configure the data plane209based on a declared or desired state of the service mesh211. The control plane207may be the portion or part of a network responsible for controlling how data packets are forwarded from a first location of the network to a destination of the network, and the route the data will take to arrive at the destination. A control plane207may be responsible for creating a routing table, routing rules, and implementing various protocols to identify the network paths that may be used by the network. The control plane207can store the network paths to the routing table. Examples of protocols used for creating routing tables may include Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and/or Intermediate System to Intermediate System (IS-IS).

Embodiments of the service mesh control plane205, may provide rules, policies and/or configurations enacted for each of the running data planes209of a service mesh211. The service mesh control plane205provide policy and configuration for all of the running data planes209in a service mesh211but does not touch any packets or requests transmitted by the users. Embodiments of the service mesh control plane205may turn all the data planes209into a distributed system. The service mesh211may be initially configured by a human administrator interacting with the service mesh control plane205via a UI to control the distributed system of the service mesh211. For example, the administrator may interact with the service mesh control plane205through a web portal, CLI or some other interface. Through the UI, the operator or administrator may access global system configurations for the service mesh211, including but not limited to, deployment control, authentication and authorization settings, route table specifications, and load balancer settings such as timeouts, retries, circuit breakers, etc.

Embodiments of the service mesh control plane205, may further include additional components that configure the service mesh211. For example, in some embodiments, the service mesh control plane205may further configure a workload scheduler, service discovery and sidecar proxy configuration APIs. The services215of the service mesh may run on infrastructure via a scheduling system (e.g., Kubernetes®), and the workload scheduler may be responsible for bootstrapping a service215along with a sidecar or proxy217a-217n(referred to generally herein as proxy217). As the workload scheduler starts and stops instances213of the services215, the service discovery component may report the state of services and may be the process responsible for automatically finding instances213of services215to fulfill queries and requests. Embodiments of sidecar proxy configuration APIs may describe the configuration of the proxy217mediating inbound and outbound communication to the service215attached to the proxy217. During configuration of the proxies217, all proxies217may be programmed in the service mesh211with configuration settings that allow the proxy to reach every instance213and/or service215in the service mesh211. Moreover, the sidecar proxy configuration APIs may configure the proxy to accept traffic on all ports associated with a service215. Furthermore, through the sidecar proxy configuration APIs, the service mesh control plane205may fine tune the set of ports, and protocols that a proxy217may accept when forwarding traffic to and from an instance213or service215. Additionally, through the sidecar proxy configuration APIs, the service mesh control plane205may restrict a set of services215that a proxy217may reach when forwarding outbound traffic from a service215or instance213.

Embodiments of the service mesh control plane205may organize instances213(such as one or more pods, containers or clusters), services215, and/or proxies217into one or more networks or namespaces. The service mesh control plane205may enroll a set of namespaces to a service mesh211and upon enrolling a namespace, the service mesh control plane205may enable monitoring of resources within the namespace, including the monitoring of any applications deployed as pods, services215or other types of instances213, and traffic policies. Enrolling a namespace also optionally allows for metrics to be collected for resources in the given namespace and for instances213of pods or services215within the namespace to be automatically injected with proxy217containers.

Referring now to the data plane209, embodiments of the data plane209may be responsible for touching every packet of data and/or request of the service mesh211. In other words, the data plane209of the service mesh211may be responsible for conditionally translating, forwarding, and observing every network packet that flows to and from the instances213and services215of the service mesh211. As illustrated in the exemplary embodiment, the data plane209may comprise a plurality of instances213such as one or more clusters, pods, or containers which may be running a service215within the instance213. Embodiments of each service215may be co-located within an instance213, with a sidecar network proxy217. For example, as shown inFIG.2, service215ais co-located with proxy217awithin instance213a; service215bis co-located with proxy217bwithin instance213b; service215cis co-located with proxy217cwithin instance213c; service215dis co-located with proxy217dwithin instance213d; and the last service215nis co-located with proxy217nwithin instance213nof the data plane209. All network traffic (e.g., HTTP, REST, gRPC, Redis, etc.) from individual services215may flow via the local proxy217to a destination routed by the service215, in accordance with the routing rules and policies of the service mesh211. Since the data flows from the services215to the co-located proxy217and a second proxy217to finally reach a second service215, the services215may not be aware of the network of services at large that may form the data plane209. Instead, the services215themselves may only be aware of their local proxy217.

Embodiments of the proxies217may be responsible for performing tasks associated with service discovery, health checking, routing, load balancing, authentication/authorization, and observability. Service discovery tasks may include discovery of upstream and/or backend services215and instances213that are available on the data plane209of the service mesh211. Health checking tasks may include determining whether upstream services215or instances213returned by service discovery are healthy and ready to accept network traffic. Health checking may include both active health checking and/or passive health checking. Routing tasks include directing requests to a proper instance213, cluster, pod or container of a service215. For example, a REST request for a local instance213of a service215, a proxy217tasked with sending an outbound communication to the next service215of a microservice chain knows where to send the communication based on the routing rules and configurations. Authentication and authorization tasks of the proxy217may include the proxy217performing cryptographic attestation of incoming requests to determine if the request being invoked by a user is valid and allowable. For example, the user sending the requested call is authenticated the proxy217using Mutual Transport Layer Security (mTLS) or another mechanism of authentication, and if the user is allowed to invoke the requested endpoint service of the service mesh211, the proxy217may route the request to the next service215along the microservice chain. Otherwise, the proxy217can return an unauthenticated response to a user that is not authorized to invoke a particular call function or a user that is not authenticated by the service mesh211.

Embodiments of the proxies217may perform one or more observability tasks of the service mesh211. The observability tasks may include, for each request, the collection of detailed metrics of the service mesh211, including statistics, logging, and generation of distributed tracing data that may allow operators and administrators of the service mesh211to understand the distributed traffic flow of the service mesh211. Embodiments of the service mesh211may keep track of all possible services215being invoked by users. Embodiments of the service mesh211may track the invoked services215on a per user basis and store the data associated with the user's invoked services215to profiles associated with the users (i.e., user profiles). Over time, the service mesh211may build a heuristics database comprising metrics collected by the service mesh211via the proxy217, as requests are made and fulfilled for users. In the exemplary embodiment ofFIG.2, the heuristics database collecting metrics of the service mesh211may be referred to as service mesh metrics database219(referred to herein onFIG.2as service mesh metrics DB219).

Proxies217of the service mesh211may collect and store a plurality of different metrics to the service mesh metrics DB219over time, along with user profiles associated with the metrics being collected. For example the types of metrics being collected by the service mesh211may include the size of data being sent between services215of a microservice chain, on a per user profile basis; the size of data being sent by each user profile and the time of day the data is being sent; the amount of data being sent for each microservice chain within the service mesh211for all users and may further detail the data being sent to each microservice chain based on the time of day. In some embodiments of the service mesh211, the service mesh211may further record metrics to the service mesh metrics DB219detailing the aggregate amount of network traffic during a day or a period of time, the expected amounts of network traffic within the service mesh211during the day or a period of time, and network traffic attributed to each user profile per day or over a period of time. For example, service mesh211may record the number of requests submitted by each user profile and/or the total number of requests submitted for each microservice chain of the service mesh211.

Embodiments of the service mesh211may utilize the metrics collected by the service mesh metrics DB219to configure and apply intelligent compression to the data being sent through the service mesh211to one or more services215of a microservice chain in order to fulfill user requests. Intelligent compression by the service mesh211may be implemented in a variety of different ways. Each of the categories of intelligent compression may be implemented alone or in combination with one or more other types of intelligent compression. Examples of the types of intelligent compression that may be configured and utilized by the service mesh211, may include intelligent compression implemented selectively on a per user profile basis, based on the type of usage by each user and the amount of data sent by users associated with the user's profile; intelligent compression based on the time of day that one or more users are submitting requests and/or the expected aggregate amount of traffic on the network; and/or Friendly Neighbor Compression protocol, whereby proxies217or services215that may have free computing resources but may otherwise be outside of the microservice chain being invoked by a request, may perform data compression instead of a more overly utilized proxy217or service215within the microservice chain being invoked.

Intelligent compression by service mesh211may be triggered to selectively apply data compression based on the user profile initiating a request for a service215being routed by the service mesh211, the amount of data being routed through the microservices chain and/or the amount of data historically known or expected to be routed through the microservice chain by the user profile. Embodiments of the service mesh control plane205may configure a threshold level of data being routed and/or frequency of data being routed by each user profile. The threshold may be configured based on the collected metrics of each user profile as stored by the service mesh metrics DB219. The service mesh211may set the threshold level for triggering the selective compression of the user profile. For example, based on the collected metrics, the configured threshold may be set based on anticipated amount of data being sent by user profiles via a microservice chain for each API call, the total aggregate amounts of data known to be transmitted via a microservice chain in a day by each user profile, etc. User profiles being tracked by the metrics of the service mesh211that send an amount of data over the configured thresholds, such as an amount of data in a single request over a configured threshold and/or over a configured threshold of an aggregate amount of data within a specified time frame, may be compressed by the proxy217of the services215of the microservice chain being invoked by the API call, while separate user profiles still operating under the configured threshold may not have data compressed for the same API call.

FIG.5depicts an example of intelligent compression by the service mesh211which is selectively applies compression to requests by specific user profiles, while selectively choosing not to apply compression for a second user profile based on historical metrics collected for each user profile stored within the service mesh metrics DB219. As shown inFIG.5, a first user501may regularly submit a first API call507avia a client device503through an API gateway505for a microservice M4. As shown, the microservice chain for invoking the microservice M4is routed through the proxies P1, P2, and P3of microservice M1, M2, M3before ultimately being sent to proxy P4delivering the data to microservice M4. The first user501may regularly submit 1 mb of data or more with each API call507a. Likewise, a second user502may invoke a same API call507bto the API gateway505via client device504. The second user may regularly submit 1 kb of data for each API Call507bvia the microservice chain routing the data to M4via the proxies P6to P7to P4of microservices M6, M7and M4respectively.

Based on the historical analysis of the transactions being regularly sent by the different users in this example, metrics may be known to the service mesh211for each user and the service mesh may set a threshold accordingly. For instance, a threshold of less than 1 mb of data may be the configured by the service mesh control plane205and an amount of data exceeding 999 kb may be compressed before reaching the endpoint of the microservice chain (M4in this example). Knowing that based on historical metrics, user501submits requests at 1 mb or above using the microservice chain M1to M2to M3to M4, the service mesh211may intelligently enable compression at proxy P3of microservice M3, causing proxy P3to compress the 1 mb of data before being routed by the service mesh211to M4. Moreover, knowing, based on the historical metrics collected by the service mesh211, that the second user502regularly sends 1 kb of data using the microservice chain M6to M7to M4, a size of data below a configured threshold, the service mesh211may not enable compression at either M6, M7or proxies thereof, allowing the uncompressed 1 kb of data to be routed through the service mesh211, arriving at microservice M4as uncompressed data.

In some embodiments of the service mesh211, intelligent compression by service mesh211may be triggered to broadly enable compression for all services215and proxies217of the service thereof, sending data to a particular microservice based on expected aggregated traffic of the network. Based on analysis of the metrics collected by the service mesh metrics DB219, the service mesh211may identify, based on historical requests and patterns of data being routed through the service mesh211, the times of day and/or periods of time wherein there may be higher amounts of aggregate traffic to one or more services215of the service mesh211. A time frame may be established by the service mesh211, wherein data being transmitted during periods of time experiencing heavy amounts of network traffic through the service mesh211can be compressed for all users of the service mesh211. For example, if there is a period of time in the morning, mid-day, afternoon, evening, etc., where the amount of aggregate network traffic is predicted to exceed a configured threshold established by one or more policies or rules of the service mesh control plane205, compression may be enabled for the period of time when the expected heightened levels of traffic are predicted. For instance, where higher levels of traffic above the configured threshold are being routed to services215of the service mesh211between 8 am to 10 am, the service mesh211may enable compression to occur for all requests submitted between 8 am and 10 am, regardless of the user profile submitting the request. Outside of the 8 am to 10 am period of time, data may be routed through the service mesh uncompressed, and/or selectively compressed using another intelligent compression protocol described herein, such as based on user profile activity or the overall size of the data being sent.

FIG.6AandFIG.6Bdepict an example embodiment of intelligently applying data compression broadly to the services215of the service mesh211, based on the amount of network traffic predicted to be routed to the services215and/or proxies217thereof within a service mesh211. The predictions of network traffic routed through service mesh211may be based on historical metrics collected by the service mesh211and periods of time identified by the service mesh211where historically, the size or amount of data being routed through the service mesh211is above a configured threshold, compression is enabled for all network traffic being routed through the service mesh. The threshold level can be configured manually by an administrator of the service mesh211, or automatically based on an analysis of the collected metrics and the available computing resources needed to process the historical levels of data being routed through the service mesh throughout a period of time, in the aggregate and/or at one or more times having high volumes of network traffic.

As shown inFIG.6A, a first user501historically submits a first API call507ato an API gateway505via client device503to the service mesh. The API call507aroutes 500 kb of data per minute through the microservice chain to microservice M4. As shown, the data is routed through the proxies P1to P2to P3to P4of a microservice chain comprising M1, M2, M3and M4respectively. During the period of time shown inFIG.6A, the total amount of data being sent every minute over the service mesh does not arise above a configured threshold level of data (e.g., less than 1 mb of data), and thus, when the service mesh is predicted to route an amount of data below the configured threshold level, the 500 kb of data being routed to microservice M4is routed as uncompressed data as depicted inFIG.6A.

FIG.6Bof this example, depicts a period of time, wherein the service mesh historically identifies, based on collected metrics, wherein network traffic may arise above a configured threshold (i.e., a threshold of 1 mb or higher in this instance). As API call507asends 500 kb of data every minute, there is a period of time during the day when API call507b, submitted by second user502via client device504, is historically expected to submit 500 kb per day through proxies P6to P7to P4of a microservice chain comprising M6, M7and M4. Embodiments of the service mesh may use the collected metrics of the service mesh to predict a time frame user502may route the additional 500 kb of data through the service mesh, overlapping in time with the 500 kb/min being sent by user501. For example, if user502is typically known to route the 500 kb of data through the service mesh between 4:30 pm to 5 pm, causing a total aggregate of network traffic of 1 mb to be routed through the service mesh simultaneously to microservice M4and 1 mb of data is above the configured threshold, then all data being routed through the service mesh to microservice M4may be compressed between the time frame of 4:30 pm to 5 pm. As shown, each of the proxies (i.e., P7and P3) responsible for routing data to the proxy P4of the endpoint microservice M4, may compress the data during the period of time compression is enabled by the service mesh (i.e., 4:30 pm to 5 pm in this example). Moreover, after 5 pm, following the period of time the service mesh expects the heightened level of aggregate network traffic to subside, compression of data by proxies P3and P7may be disabled, thus continuing to allow data to be routed to M4again in an uncompressed manner.

In some embodiments of the service mesh211, the service mesh211may intelligently outsource compression of the data being routed through a microservice chain to a trusted neighboring proxy217or microservice215that is outside of the microservice chain using a Friendly Neighbor Compression protocol (FNCP). The FNCP allows a service mesh211to find microservices and proxies outside of the microservice chain, but within the same network or namespace, that are being underutilized or may have plenty of freely available resources to perform compression. Intelligently outsourcing compression to an underutilized neighboring service215or proxy217, frees up resources within the microservice chain, allowing the microservice chain to route more data and reduce the possibility that resources may become unavailable, resulting in errors or the inability to process additional requests that may be submitted by users. When the FNCP is engaged, and a microservice chain is identified as needing to invest resources into performing compressions of data, the service mesh211may conduct a resource trend analysis. As part of the resource trend analysis, the service mesh211may track resource usage, such as memory graphs and CPU graphs to identify trends and/or patterns of usage and make predictions based on the trends whether or not high levels of resources or more resources than provisioned to the microservice chain will be needed to be consumed over time to meet demand by users.

Based upon the trend analysis, the service mesh211may seek out trusted services215or proxies217outside of the microservice chain (to assist with performing compressions of data. For example, when the trend analysis predicts high levels of resource consumption of the microservice chain, maxing out resource use and/or the trend indicates that higher levels of resources may be needed over time than may be provisioned to the services215of the microservice chain. As part of the FNCP, the service mesh211may query a free neighbor database221(referred to herein onFIG.2as free neighbor DB221) tracking each of the neighboring services215and/or proxies217thereof in the namespace or network of microservices. The free neighbor DB221may also track the security and compliance standards of the neighboring services215and proxies217thereof. Allowing the service mesh211to select neighboring services and proxies to be integrated into the microservice chain in need of assistance that have the same (i.e., matching), similar or equivalent security and compliance standards. Moreover, metrics tracked by the service mesh metrics DB219and analysis tools for analyzing metrics of the neighboring services215and proxies217may be in communication with or integrated with the free neighbor DB221, allowing the service mesh211to accurately predict which neighboring microservices and associated proxies may have freely available resources or may be underutilized at the present time of need by the service mesh211. For example, a neighboring service215and proxy217may only run services late at night and are otherwise unused during the day when a microservice chain is deployed. During the daytime, the neighboring service and proxy may be considered available and underutilized and thus deployed by the service mesh211using FNCP to perform compression of data on behalf of the microservice chain during the day. Likewise, where the same neighboring service215and proxy217are utilized in the evening or overnight based on the collected metrics of the service mesh211, the neighboring service may be unavailable to assist under the FNCP. Therefore, when implementing FNCP to find an underutilized neighboring service215and proxy in the evening or overnight, the service mesh211will not try to deploy the same neighboring service, but rather may find a different neighboring service that is underutilized or has free resources in the evening or overnight to assist the microservice chain with data compression.

The deployment of FNCP may require the service mesh to change or update rules with the service mesh control plane205. Once a neighboring service and/or proxy is identified from the free neighbor DB that has available resources for performing data compression, and is confirmed by the service mesh211(e.g. the service mesh control plane205) as having similar security and compliance standards as the other services in the microservice chain, the service mesh control plane205may add or update rules for routing inbound and outbound traffic of the microservice chain through the neighboring service being deployed. The service mesh211will put in place rules that will route data through a part of the microservice chain to the neighboring service and rules for members of the microservice chain to accept traffic coming from the neighboring service and treating the incoming traffic of the neighboring service the same as traffic coming from other members of the microservice chain invoked by the user's request.

FIGS.7A and7Billustrate an example of a microservice chain routing data to microservice M5using the microservice chain alone, as shown inFIG.7A, and using FNCP to employ a neighboring microservice M6and the associated proxy P6to perform data compression, as shown inFIG.7B. As first shown inFIG.7A, a user501submits an API call507to the API gateway505via the client device503. The API call507routes the data to microservice M5using a microservice chain M1to M4to M5, whereby the data is routed through proxies P1to P4to P5respectively. The proxy P1of the microservice chain compresses the data and routes the compressed data along the rest of the microservice chain.

In this example shown inFIG.7A, the microservice M1may need to send compressed data to M4every minute. Upon performing an analysis trend, the service mesh211may find that the CPU and memory usage for M1is too high and consuming too many resources. Microservice M1may hit a capacity for resources within 30 minutes. The service mesh211may query the free neighbor DB221to find an underutilized microservice outside of the service chain being invoked by user501. For instance, microservice M6may only be processing data once per day, and otherwise may be sitting idle otherwise. Using FNCP, the service mesh211can check the security and compliance standards of microservice M6via the service mesh control plane205, as shown along route701ofFIG.7B. If the security and compliance standards of microservice M6are the same, similar and/or equivalent to microservice M1, the service mesh control plane205can add or alter rules of the service mesh211, wherein microservice M1routes uncompressed data to microservice M6's proxy P6, instead of proxy P4. Proxy P6will now perform compression of the data and route the compressed data back along the microservice chain to proxy P4as shown inFIG.7B. The rules of the service mesh211are additionally altered or updated such that proxy P4accepts the compressed data from proxy P6, in the same manner as proxy P4would have accepted the compressed data from Proxy P1during the course of events ofFIG.7A. Proxy P4routes the data along the rest of the microservice chain to proxy P5and ultimately to the endpoint microservice M5.

Method for Implementing a Service Mesh with Intelligent Data Compression

The drawings ofFIGS.8-10Brepresent embodiments of methods for implementing a service mesh with intelligent data compression, as described in accordance withFIGS.2-7Babove, using one or more computing systems defined generically by computing system100ofFIGS.1A-1B; and more specifically by the embodiments of specialized computer systems depicted inFIGS.2-7Band as described herein. A person skilled in the art should recognize that the steps of the method described inFIGS.8-10Bmay be performed in a different order than presented and may not require all the steps described herein to be performed.

FIG.8may refer to a method800for implementing a service mesh with intelligent data compression based on the type of usage and user profile to selectively compress data for particular user profiles sending requests or calls routed through the service mesh211. The embodiment of the method800may begin at step801. During step801, the service mesh211collects metrics tracking and describing the use of the service mesh211over time. The metrics can include for each user profile sending a request, the data size being sent, time of day requests are sent and/or processed, the microservice chain invoked to complete the request, the number of requests for each user profile and the total number of requests for each microservice chain, and any other type of metrics that can be collected, stored and logged by a service mesh211. In step803, the service mesh211may build a heuristics database over time compiling the collected service mesh metrics into a service mesh metrics DB219.

In step805, the service mesh control plane205may configure rules, policies and a threshold level for data compression for data being routed through the service mesh211. The service mesh control plane205may implement a threshold level for data compression on a per user profile basis, wherein data compression can be customized to each individual user profile known to use and consume resources of the service mesh211. The threshold levels established in one or more rules or policies by the service mesh control plane205may be based on user profile metrics historically collected and stored by the service mesh metrics DB219.

In step806, an incoming request for microservices is received by the service mesh211. For example, the incoming request for services may be in the form of an API call transmitted to the service mesh211by a user application. In step807, the service mesh211may examine the incoming request for microservices received in step806. The service mesh211may consult rules and policies for the service mesh211and determine using historical analysis whether or not compression is needed to fulfill the request, based on the user profile associated with the request, historical use per user profile, type of use and the data size recorded by the service mesh metrics DB219. In step809, based on the analysis of the incoming request, a determination is made by the service mesh211whether the request exceeds a configured threshold. For example, the user profile regularly routes large amounts of data through a microservice chain above a threshold size, compression may be applied based on service mesh rules and policies for user profile. If the request does not exceed a configured threshold for compressing the data, the method800proceeds to step811, wherein the uncompressed data is routed through the microservices chain of the service mesh211as requested.

Alternatively, in a scenario where the service mesh211determines that the incoming request for microservices exceeds a configured threshold level associated with the service mesh rules, policies and/or user profile, the method may proceed to step813, wherein the service mesh compresses the data and routes the compressed data through the microservice chain of the service mesh as requested by the user. In step815, the request for microservices is completed as requested by the user application. Any data that may have been requested from the microservice may be returned to the user, and metrics for completing the request by the microservice chain can be recorded to the service mesh metrics DB219.

FIG.9may refer to a method900for implementing a service mesh with intelligent data compression based on aggregate network traffic being routed through the service mesh211and varying enablement of compression based on the time of day or periods of time with high amounts of network traffic. In step901, the service mesh211collects various metrics over time describing tracking the use and statistics of the service mesh211as the service mesh211functions to fulfill requests. For example, the service mesh211may collect metrics describing data size, time of day, the microservice chains invoked by requests, and/or aggregate network traffic at one or more points in time during the day. In step903, the service mesh211may build or update a heuristics database such as a service mesh metrics DB219over time using the metrics collected by the service mesh211. The service mesh211may collect metrics for each user requested microservice chain invoked to complete a request.

In step905, the service mesh211may determine whether or not a time frame for compressing requests sent through the service mesh211in view of known or predicted levels of aggregate network traffic exceeding a configured threshold level. If the service mesh211determines that a time frame for compressing data routed through the service mesh is not needed or has already been configure and doesn't need to be updated further, the method900may proceed to step909. Conversely where the service mesh211determines that a time frame for compressing data routed through the service mesh211should be configured and/or updated, the method may proceed to step907. During step907, the service mesh211configures and/or updates a time frame for enabling compression on the network for all requests being routed through microservice chains of the service mesh211. The compression time frame may be identified based on the historical patterns of metrics collected by the service mesh describing the aggregate amount of traffic routed through the service mesh211and the time of day when requests are routed through the service mesh211. The service mesh211identifies one or more periods of time where the aggregate amount of network traffic is predicted to exceed a configured threshold and establishes a period of time wherein requests arriving within one or more of the periods of time will send data through the service mesh211by compressing the data.

In step909, the service mesh211receives an incoming request as an API call from one or more user applications. In step911, the time of receiving the request is compared against one or more compression time frames. If the incoming request is not sent within an established compression time frame, the method900may proceed to step913, wherein the data routed through the service mesh211is routed along the prescribed microservice chain as uncompressed data. Conversely, if the incoming request in step909is received by the service mesh211within a time frame established by the service mesh211to be a compression time frame, for example due to predicted high levels of aggregated network traffic, the method may proceed to step915. In step915of method900, the service mesh211compresses the data and routes the data through the microservice chain of the service mesh, as requested by the user via the incoming API call or other type of request. In step917, the request for microservices is completed along with any data to be returned to the user application as part of fulfilling the request.

FIGS.10A-10Bmay refer to a method1000for implementing a service mesh with intelligent data compression using FNCP to find trusted, neighboring microservices within the same network or namespace that are outside of a microservice chain being invoked, but may be underutilized or have freely available resources able to provide data compression on behalf of the microservice chain being invoked. The method1000may begin at step1001. During step1001, the service mesh collects metrics tracking and/or describing the use of the service mesh, including statistics, logging, data size of transactions, the time-of-day requests occur, the microservice chains being invoked, aggregate network traffic, etc. In step1003, the metrics collected by the service mesh211over time may be used to build or update a heuristics database, such as service mesh metrics DB219.

In step1005, an incoming request for microservices is received by the service mesh211. For example, as an API call from a user application requesting to invoke a first microservice chain to fulfill the request. In step1007, the service mesh211performs a resource trend analysis for the first microservice chain being invoked. Resource graphs describing memory, processing power and other computing resources consumed for routing, processing and/or compressing data being routed through the service mesh211may be generated using collected metrics made available by the service mesh metrics DB219. Using the resource graphs and data describing consumption of resources by the services215of the microservices chain being invoked by the request, the service mesh may analyze and predict whether or not resources may be constrained or unavailable over time, to perform compression of data by the services215within the first microservice chain being invoked.

In step1009, a determination is made whether fulfilling the request by compressing the data being routed through the first microservice chain would result in computing resources being constrained or unavailable over time to perform the requests and/or future requests. If compressing the data being routed through the first microservice chain would not cause a significantly negative impact the resources of the service mesh211, the method1000may proceed to step1027, whereby the service mesh211proceeds to route the data through the first microservices chain by compressing the data at the first microservice or proxy thereof. Likewise, where performing data compression by one or more services215within the microservice chain being invoked would constrain, limit or overutilize resources, the method may proceed to step1011.

In step1011, the service mesh211may query the free neighbor DB221for a nearest available friendly neighboring microservice and proxy thereof within the same network or namespace, having available resources to help compress data on behalf of the first microservice chain. In step1013, a determination is made whether or not a free neighboring microservice is found. If there is not a free neighboring microservice that has available resources and/or is underutilized at the time of the request, the method1000may proceed to step1027. Conversely, if a free neighboring microservice is found within the free neighbor DB221that meets the criteria for compressing data on behalf of the first microservice chain, the method may proceed to step1015. In step1015, a query is sent to the service mesh control plane205to check whether or not the free neighboring microservice identified in step1011-1013is configured with the same, substantially similar or equivalent security and compliance standards as the microservices within the first microservice chain. In step1017, a determination is made whether the same, similar or equivalent standards are found for the free neighboring microservice. If the security and compliance standards are not satisfactory, the method1000may return to step1011and try to find another free neighboring microservice to assist with data compression. Likewise, if the free neighboring microservice is compliant with the security and compliance standards of the microservices within the first microservice chain, the method may proceed to step1019.

In step1019, the service mesh control plane205adds and/or revises network rules for routing data. The new or revised network rules may permit the routing of data via a second microservice chain, said microservice chain comprising the first microservice chain plus the free neighboring microservice identified by the free neighbor DB221, wherein the microservices within the first microservice chain may route and/or accept data from the free neighboring microservice as if it were a member of the first microservice chain. In step1021, the service mesh routes the uncompressed data from the first microservice of the microservice chain to the proxy of the free neighboring microservice having the free resources available to perform compression. In step1023, the freely available microservice residing outside of the first microservice chain compresses the data and in step1025, the service mesh211routes the compressed data from the free neighboring microservice (or proxy thereof) to the next microservice within the microservices chain. In step1029, the request for microservices is complete and any requested data that may be required to be returned to the user application is sent to the user application.