Visualizing API invocation flows in containerized environments

An approach to generating end-to-end visualizations of invocations from coarse granular application programming interface (API) requests within a containerized environment may be presented. A coarse-granular API request may be intercepted. The coarse-granular API request may receive a unique identifier, which will be assigned to all invocations associated with the coarse-granular API request. Any invocations associated with the coarse-granular API within the containerized environment may be monitored. Detected invocations resulting from the coarse-granular API request may be annotated with a sequence number and the unique ID of the associated coarse-granular API request. An invocation flow for the coarse-granular API request may be generated based on the unique ID, relationship between the invocations and microservices, and the sequence number of the invocations.

BACKGROUND OF THE INVENTION

The present invention relates generally to containerized computing environments, more specifically, to visualizing end-to-end coarse-granular application programming interface (“API”) invocations across a containerized environment.

In cloud native solutions, business functionalities are implemented as microservices in containerized environments and exposed to consumers through coarse-granular APIs. When a coarse-granular API is invoked, it can invoke multiple microservices deployed across multiple containers, groups of application containers (i.e. PODs), or virtual clusters within a cluster of nodes delivering the functionality. Existing container monitoring approaches through container orchestration system API servers, object-state-metrics and node explorers can provide metrics such as health, input/output (I/O), network and memory usage of various containerized objects like deployments, nodes and PODS.

SUMMARY

According to one embodiment of the present invention, a computer-implemented method for visualizing end-to-end flow of microservice invocations from a coarse-granular application programming interface (“API”) within a containerized environment is disclosed. The computer-implemented method includes intercepting the coarse-granular API request at an ingress module within the containerized environment. The computer-implemented method further includes annotating the coarse granular API request with a unique identifier (“ID”). The computer-implemented method further includes monitoring one or more invocations resulting from the coarse granular API request. The computer-implemented method further includes annotating one or more functions within one or more microservices invoked by the coarse-granular API request with a respective sequence number. The computer-implemented method further includes generating an invocation flow for the coarse-granular API request based on the unique ID associated with the coarse granular API request and the respective sequence number associated with the one or more functions within the one or more microservices.

According to another embodiment of the present invention, a computer program product for visualizing end-to-end flow of microservice invocations from a coarse-granular application programming interface (“API”) within a containerized environment is disclosed. The computer program product includes one or more computer readable storage media and program instructions stored on the one or more computer readable storage media. The program instructions include instructions to intercept the coarse-granular API request at in ingress within the containerized environment. The program instructions further include instructions to annotate the coarse granular API request with a unique identifier. The program instructions further include instructions to monitor one or more invocations resulting from the coarse granular API request. The program instructions further include instructions to annotate one or more functions within one or more microservices invoked by the coarse-granular API request with a respective sequence number. The program instructions further include instructions to generate an invocation flow for the coarse-granular API request based on the unique ID associated with the coarse granular API request and the respective sequence number associated with the one or more functions within the one or more microservices.

According to another embodiment of the present invention, a computer system for visualizing end-to-end flow of microservice invocations from a coarse-granular application programming interface (“API”) within a containerized environment is disclosed. The computer system includes one or more computer processors, one or more computer readable storage media, and program instructions stored on the computer readable storage media for execution by at least one of the one or more processors. The program instructions include instructions to intercept the coarse-granular API request at an ingress within the containerized environment. The program instructions further include instructions to annotate the coarse granular API request with a unique identifier. The program instructions further include instructions to monitor one or more invocations resulting from the coarse granular API request. The program instructions further include instructions to annotate one or more functions within one or more microservices invoked by the coarse-granular API request with a respective sequence number. The program instructions further include instructions to generate an invocation flow for the coarse-granular API request based on the unique ID associated with the coarse granular API request and the respective sequence number associated with the one or more functions within the one or more microservices.

The above summary is not intended to describe each illustrated embodiment of every implementation of the present disclosure.

DETAILED DESCRIPTION

The embodiments depicted and described herein recognize the benefits of visualizing the end-to-end flow of microservice invocations from coarse granular application programing interfaces (‘API”) to one or more microservices invoked and the functions invoked within the one or more microservices within a container environment (e.g., Docker®). Additionally, some embodiments appreciate collecting key metrics, for example, response time, network latency at multiple environment levels, individual microservices, and the functions within the microservice invoked by the coarse-granular API.

In an embodiment of the present invention, an interceptor application on an ephemeral layer may sit at specific points within a container environment and work in tandem or be part of a container orchestration program (e.g., Kubernetes®, Docker® Swarm). The ephemeral layer may detect coarse-granular API requests to microservices within the container environment and annotate the request and all functions resulting from the request in a hierarchical manner (e.g., sequentially). The functions may include any cascading functions at secondary or tertiary microservices to the initial request being received at the initial microservice. The annotations of the functions may be stored within a state database or key-value store, such as etcd. Upon a determination that the coarse-granular API request has reached completion, a visualization module can generate an end-to-end flow visualization of the coarse-granular API request within the container environment.

Additionally, in some embodiments, the flow of microservice invocations are intercepted at different abstraction layers within a cloud based container system. The flow of microservice invocations can be stored within the container system state database. The tracked flow of microservice invocations and associated metrics can be monitored and tracked in a hierarchy format, which describe the sequence and relationship between microservice invocations.

In an embodiment, the tracked flow of microservice invocations can persist for every coarse granular API request within the container state database. The tracked flow of microservice invocations can include runtime aspects of containerized solutions and dependencies associated with the microservices requested by the coarse-granular API. The persistent data can be utilized to generate a visualization for the coarse-granular API request.

In an embodiment of the invention, interceptors at different levels within a containerized orchestration system, such as Kubernetes, can detect and monitor coarse-granular APIs. Coarse-Granular APIs requests can be received outside the node cluster through an ingress controller. The request of the coarse-granular API will be tracked via an interceptor at the ingress controller. The interceptor tracks every request of the API and captures the flow of invocations in a hierarchical data structure (e.g., JSON/YAML format). Each request of the API will be annotated with a unique identifier (“ID”) (e.g., incremental integer sequence starting from 1, and every request to function within a microservice will be annotated with a decimal sequence starting from the parent sequence number).

In describing embodiments in detail with reference to the figures, it should be noted that references in the specification to “an embodiment,” “other embodiments,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, describing a particular feature, structure or characteristic in connection with an embodiment, one skilled in the art has the knowledge to affect such feature, structure or characteristic in connection with other embodiments whether or not explicitly described.

FIG.1is a functional block diagram depicting, generally, end-to-end coarse-granular application programming interface invocation visualization environment100. End-to-end coarse granular application programming interface invocation visualization environment100comprises primary node110and secondary node120operational on server102. As used herein, a primary node/secondary node relationship shall mean an asymmetric communication or control where the primary node (e.g., primary node110) controls one or more other devices (e.g., secondary node120) or processes running on one or more other devices. Also present in end-to-end coarse-granular application programming interface invocation visualization environment100is client computer150and network140. Network140can support communications between the server102and client computer150.

As shown inFIG.1, the following computer modules are operational on primary node110: API server112, interceptor B114, and visualizer118. Also located on primary node110is container system state database116. The following computer modules are operational on secondary node120: ingress module122, interceptor A124, service A126, service B128, service C130, and interceptor C132.

Server102and client computer150can be a standalone computing device, a management server, a web server, a mobile computing device, or any other electronic device or computing system capable of receiving, sending, and processing data. In other embodiments, server102and client computer150can represent a server computing system utilizing multiple computers as a server system. It should be noted, while one server and one client computer are shown inFIG.1, end-to-end coarse granular application programming interface invocation visualization environment100can have any number of servers and client computers (e.g. 1, 2, n . . . n+1). In another embodiment, server102and client computer150can be a laptop computer, a tablet computer, a netbook computer, a personal computer, a desktop computer, or any programmable electronic device capable of communicating with other computing devices (not shown) within an environment for end-to-end coarse granular application programming interface invocation visualization environment100via a network, such as network140.

In another embodiment, server102and client computer150represent a computing system utilizing clustered computers and components (e.g., database server computers, application server computers, etc.) that can act as a single pool of seamless resources when accessed within end-to-end coarse granular application programming interface invocation visualization environment100. Server102and client150can include internal and external hardware components, as depicted, and described in further detail with respect toFIG.3.

Primary node110can be a container node within a containerized environment. Operational on primary node110are API server112, interceptor B114, and visualizer118. Also located on primary node110is system state database116. Primary node110can be configured to control and manage secondary node120within a container orchestration system (e.g., Kubernetes® or Docker Swarm®). For example, primary node110can manage load balancing between multiple secondary nodes120and assign incoming requests for service functions based on available resources or latency needs.

While one primary node110is shown inFIG.1, multiple primary nodes110can be present within end-to-end coarse granular application programming interface invocation visualization environment100. Multiple primary nodes110can be distributed among multiple servers. In an embodiment, multiple primary nodes110are preferred because it allows for redundancy if a primary node fails.

API server112is a computer module operational on primary node110. API server112exposes the container orchestration components within end-to-end coarse granular application programming interface invocation visualization environment100to a client API. For example, if a client API is a coarse-granular API that makes multiple request for service invocations within the container environment. In an embodiment, API server112can be the front end tool that allows for a user to interact with the container orchestration system. It should be noted, multiple instances of API server112can be operational on primary node110. The multiple instances of API server112can scale depending on the volume of client traffic and balance the traffic between the multiple instances.

In another embodiment, API server112validates and configures data for the API objects which include pods, services, replication controllers, and others. The API server112services REST operations and provides the front end to the cluster's shared state through which all other components interact.

Interceptor B114, interceptor A124, and interceptor C132are computer modules that can detect traffic across secondary node120associated with a coarse-granular API request. In additional embodiments, interceptor B114can monitor traffic associated with a coarse granular API request across multiple secondary nodes. It should be noted interceptor B114, interceptor A124, and interceptor C132can be part of a single computer module that can be operational on primary node110or operate independently of each other and collaborate to update metrics and key-value pairs within container system state database116. For example, interceptor B114can be a principal module, which can be operational on primary node110. Interceptor A124and interceptor C132can be controlled by interceptor B. InFIG.1, interceptor B114, interceptor A124, and interceptor C132are shown in contact with their respective modules for simplicity and ease of explanation. Interceptor A124can be associated with ingress module122(described in more detail below). Interceptor C132can be associated with service A126, service B128and service C130(described in more detail below).

In an embodiment, interceptor A124can detect incoming API requests at ingress module122. The API request can be a coarse-granular API request, which is a single request that causes multiple function invocations from service A126, service B128and/or service C130. Interceptor A124can assign a unique ID to a detected coarse granular API request. For example, a user can interact with an API via client computer150(e.g., through a web browser or application portal). Client computer150can transmit a coarse granular API request via network140to server102. Ingress module122can receive the coarse granular API request. Ingress module122can act as a gateway which verifies and authenticates the coarse granular API request. Upon ingress module122authentication of a coarse-granular API request, interceptor A124can annotate the API request with a unique ID and store the unique ID and coarse granular API request in system state database116. In another embodiment, interceptor B114can inject runtime sequence data into the header of the incoming coarse-granular API request. Further, interceptor B114can annotate which node receives the coarse-granular API request and update the information in container system state database116.

In an embodiment, interceptor C132is in connection with service A126, service B128, and service C130. Interceptor C132can be configured to identify function invocations within any of the services and determine if the invocation is due to a coarse-granular API request (e.g., via the unique identifier assigned by interceptor B114embedded within the header of the coarse-granular API request). If the invocation is due to a coarse-granular API request, interceptor C132can assign a sequence number to the invoked function and save metrics associated with the microservice invocation. For example, multiple services may be initially invoked by a coarse-granular API. Service A126may initialize one function, while service B128calls to service C130that has not been utilized with the initial request. Interceptor C132could detect the invoked function assigning the initialized function within service A126as “A.01” within the sequence, and the call made to service C130by service B128as “A.02”. A response to Service B's call to service C could be annotated as “A.03”.

Interceptor A124can monitor and/or track incoming functions across one or more secondary nodes120. In an embodiment, coarse-granular API requests received at ingress module122can be sent to API server112on primary node110. The purpose of primary node110is to ensure efficient utilization of resources across the container environment. Any actions taken by API server112can be intercepted and noted by interceptor B114. For example, if a microservice function associated with a coarse-granular API on a node invokes a second microservice function and API server assigns the function to a different secondary node, interceptor B will extract the function request to the second node from the header request associated with the reassignment of resources for the secondary node and for the second microservice.

In an embodiment, interceptor C132can track communications between services within different function calls within a containerized application on secondary node120. For example, a first microservice invocation on a secondary node120may cause a microservice function invocation. API server112can balance the resource utilization among secondary nodes by assigning the microservice function to a secondary node with more available resources or better latency to client computer150. Further, interceptor C132can extract the coarse-granular API request unique ID associated with the microservice function invocation from the header of the assignment from API server112. Interceptor132can store the assignment to the new secondary node within system state database116.

Visualizer118is a computer program that can generate various end-to-end visualizations of the invoked microservice functions associated with a coarse-granular API request. The visualization generation may be based on the sequential or metadata captured by interceptor A124, interceptor B114and interceptor C132. Further, the basis of the visualization can be in chart, graph, or Merkle tree format. In an embodiment, visualizer118can utilize metadata stored within system state database116to generate an end-to-end visualization of the coarse-granular API request. Further, the generated visualization can be sent to client computer and presented on a graphical user interface for a user (e.g., developers, devops, etc. . . . ).

Also shown inFIG.1are service A126, service B128, and service C130operational on secondary node120. A service is a named endpoint where requests from a coarse-granular API are sent. A service does not perform any work, but instead requests sent to a service are sent to a workload to perform the actual work to process the service's request. A service can route to more than one workload, and a workload can process requests for one or more services. While only service A126, service B128and service C130are shown inFIG.1, any number of services can be present within end-to-end coarse granular application programming interface invocation visualization environment100.

In an embodiment, service A126, service B128, and service C130can be microservices. Microservices allow for the breakdown of complex applications into simple independent processes, allowing for a de-coupled system to be produced. The microservices may be executed in containers to create containerized applications in a containerized computing service platform (i.e., platform as a service cloud computing). Additionally, service A126, service B128, and service C130may contain workloads. A workload can be a “pod”. A pod may refer to a group of one or more containers that are deployed together on the same node. Workloads perform the work within a microservice. For example, a workload may process Hypertext Transport Protocol (HTTP) requests and return HTTP responses.

In an embodiment, applications (not shown) can also be located on service A126, service B128and service C130. An application is made up of workloads that have an “app” label applied to them (the app name is the value of the app label). Apps can be versioned by another label called “version”. If a workload has a label of “app=details” with another label “version=v1”, then this workload is a “Versioned app” whose name is “details v1”.

Network140can be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and can include wired, wireless, or fiber optic connections. In general, network140can be any combination of connections and protocols that will support communications between server102, and client computer150.

FIG.2is a flowchart, generally designated200, depicting operational steps of generating an end-to-end visualization of a coarse-granular API request. At step202, interceptor A124can detect a coarse-granular API request from client computer150via ingress module122at secondary node120. At step204, annotate the coarse-granular API request with a unique ID via interceptor A124. In an embodiment, interceptor A124can annotate the coarse-granular API request with a unique ID. At step206, interceptor B114can monitor invocations across secondary node120resulting from the coarse-granular API request. At step208, interceptor C132can annotate a function on service A126, service B128, and/or service C130with a sequential or hierarchy identifier and store the annotation within system state database116. At step210, visualizer118can generate an end-to-end visualization of the invocations associated with a coarse-granular API request in the containerized environment utilizing the metadata and annotations stored within system state database116.

FIG.3depicts computer system10, an example computer system representative of a dynamically switching user interface computer10. Computer system10includes communications fabric12, which provides communications between computer processor(s)14, memory16, persistent storage18, network adaptor28, and input/output (I/O) interface(s)26. Communications fabric12can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, communications fabric12can be implemented with one or more buses.

Computer system10includes processors14, cache22, memory16, persistent storage18, network adaptor28, input/output (I/O) interface(s)26and communications fabric12. Communications fabric12provides communications between cache22, memory16, persistent storage18, network adaptor28, and input/output (I/O) interface(s)26. Communications fabric12can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, communications fabric12can be implemented with one or more buses or a crossbar switch.

Memory16and persistent storage18are computer readable storage media. In this embodiment, memory16includes random access memory20(RAM). In general, memory16can include any suitable volatile or non-volatile computer readable storage media. Cache22is a fast memory that enhances the performance of processors14by holding recently accessed data, and data near recently accessed data, from memory16. As will be further depicted and described below, memory16may include at least one of program module24that is configured to carry out the functions of embodiments of the invention.

The program/utility, having at least one program module24, may be stored in memory16by way of example, and not limiting, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program module24generally carries out the functions and/or methodologies of embodiments of the invention, as described herein.

Program instructions and data used to practice embodiments of the present invention may be stored in persistent storage18and in memory16for execution by one or more of the respective processors14via cache22. In an embodiment, persistent storage18includes a magnetic hard disk drive. Alternatively, or in addition to a magnetic hard disk drive, persistent storage18can include a solid state hard drive, a semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer readable storage media that is capable of storing program instructions or digital information.

The media used by persistent storage18may also be removable. For example, a removable hard drive may be used for persistent storage18. 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 storage18.

Network adaptor28, in these examples, provides for communications with other data processing systems or devices. In these examples, network adaptor28includes one or more network interface cards. Network adaptor28may provide communications through the use of either or both physical and wireless communications links. Program instructions and data used to practice embodiments of the present invention may be downloaded to persistent storage18through network adaptor28.

I/O interface(s)26allows for input and output of data with other devices that may be connected to each computer system. For example, I/O interface26may provide a connection to external devices30such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices30can also include portable computer readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to practice embodiments of the present invention can be stored on such portable computer readable storage media and can be loaded onto persistent storage18via I/O interface(s)26. I/O interface(s)26also connect to display32.

Display32provides a mechanism to display data to a user and may be, for example, a computer monitor or virtual graphical user interface.

FIG.5is a block diagram depicting a set of functional abstraction model layers provided by cloud computing environment50depicted inFIG.4in accordance with at least one embodiment of the present invention. It should be understood in advance that the components, layers, and functions shown inFIG.5are intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided: