BACKGROUND

Devices can include or use a plurality of software applications to perform a variety of different functions. The applications can be built a single, autonomous unit such that the applications are self-contained and independent from other applications executing on a device. However, to update the applications, changes can impact the entire application or device executing the respective application. For example, a modification to a small section of code can require building and deploying an entirely new version of software for the application.

SUMMARY

The present disclosure is directed towards generating service graphs for canary deployments of microservices. In a microservice architecture, network traffic and client requests can be passed through a series or network of microservices (e.g., call chain) and one or more of the microservice can process the request. The microservices can be modified, upgraded or replaced using canary deployment. In embodiments, a canary version of a microservice can be deployed within a call chain of a plurality of microservices to individually upgrade the respective microservice in the call chain or network independent of the other microservices. The canary version microservices can tag or include an identifier in a header of a request when processing the request to identify that canary version microservice performed the respective transaction. The transactions performed by the microservices in the call chain including both canary version microservices and production version microservices can be monitored and parameters for the transaction can be collected. A service graph can be generated based in part on the identifiers and using the parameters to differentiate between transactions processed by canary version microservices and transactions processed by production version microservices. The service graph can be used to determine and identify issues or problems with the canary version microservices being introduced to the call chain.

In at least one aspect, a method for monitoring multiple versions of microservices is provided. The method can include receiving, by a first microservice of a plurality of microservices forming a first call chain, a request from a client. The first microservice can execute a canary version of the first microservice and one or more subsequent microservices of the first call chain can execute production versions of the one or more subsequent microservices. The method can include including, by the first microservice, into a header portion of the request an identifier indicating the first microservice is the canary version of the first microservice. The method can include providing, by the first microservice to the one or more subsequent microservices of the first call chain, the request with the identifier. The one or more subsequent microservices can include one or more tags in the request to identify that the one or more subsequent microservices are executing the production versions of the one or more subsequent microservices while retaining the identifier with the request as the request is processed by the one or more subsequent microservices forming the first call chain. The method can include generating, by a device intermediary to the plurality of microservices, a service graph identifying transactions processed by the canary version of the first microservice and the production versions of the one or more subsequent microservices.

In embodiments, the method can include deploying, by the device, the first microservice executing the canary version of the first microservice in the first call chain to process a first portion of requests from one or more clients and deploying, by the device, the first microservice executing a production version of the first microservice in a second call chain to process a second portion of requests from the one or more clients. The method can include generating, by the device, the service graph including parameters of the transactions processed by the first call chain including the first microservice executing the canary version of the first microservice and the parameters of the transactions processed by a second call chain including the first microservice executing a production version of the first microservice. The parameters of the transactions can include a response time of the respective microservice performing one or more transactions.

The method can include identifying, by the device using the identifier, one or more transactions performed by the first microservice executing the canary version of the first microservice and one or more transactions performed by the one or more subsequent microservices executing the production versions of the one or more subsequent microservices. The method can include generating, by the device, the service graph to include a first indicator for the one or more transactions performed by the first microservice executing the canary version of the first microservice and a second indicator for the one or more transactions performed by the one or more subsequent microservices executing the production versions of the one or more subsequent microservices. The method can include determining, by the device using the service graph, one or more differences between parameters of the transactions performed by the first microservice executing the canary version of the first microservice and parameters of the transactions performed by the one or more subsequent microservices executing the production versions of the one or more subsequent microservices.

In embodiments, the method can include inserting, by the first microservice, the identifier into at least one of a Hypertext Transfer Protocol (HTTP) header portion of the request or a Hypertext Transfer Protocol Secure (HTTPS) header portion of the request. The method can include generating, by the device, the service graph of the first call chain to identify a failure between the plurality of microservices, a number of times each microservice of the plurality of microservices has been called, and a rate of success of using the plurality of microservices of the first call chain.

In at least one aspect, a system for monitoring multiple versions of microservices is provided. The system can include a device having one or more processors, coupled to memory and intermediary to a plurality of microservices forming a first call chain. The system can include a first microservice of the plurality of microservices executing a canary version of the first microservice and one or more subsequent microservices of the first call chain executing production versions of the one or more subsequent microservices. The first microservice can be configured to receive a request from a client. The first microservice can be configured to include into a header portion of the request an identifier indicating the first microservice is the canary version of the first microservice. The first microservice can be configured to provide, to the one or more subsequent microservices of the first call chain, the request with the identifier. The one or more subsequent microservices can include one or more tags in the request to identify that the one or more subsequent microservices are executing the production versions of the one or more subsequent microservices while retaining the identifier with the request as the request is processed by the one or more subsequent microservices forming the first call chain. The device can be configured to generate a service graph identifying transactions processed by the canary version of the first microservice and the production versions of the one or more subsequent microservices.

In embodiments, the device can be configured to deploy the first microservice executing the canary version of the first microservice in the first call chain to process a first portion of requests from one or more clients and deploy the first microservice executing a production version of the first microservice in a second call chain to process a second portion of requests from the one or more clients. The device can be configured to generate the service graph to include parameters of the transactions processed by the first call chain including the first microservice executing the canary version of the first microservice and the parameters of the transactions processed by a second call chain including the first microservice executing a production version of the first microservice. The parameters of the transactions can include a response time of the respective microservice performing one or more transactions.

The device can be configured to identify, using the identifier, one or more transactions performed by the first microservice executing the canary version of the first microservice and one or more transactions performed by the one or more subsequent microservices executing the production versions of the one or more subsequent microservices. The device can be configured to generate the service graph to include a first indicator for the one or more transactions performed by the first microservice executing the canary version of the first microservice and a second indicator for the one or more transactions performed by the one or more subsequent microservices executing the production versions of the one or more subsequent microservices. The device can be configured to determine, using the service graph, one or more differences between parameters of the transactions performed by the first microservice executing the canary version of the first microservice and parameters of the transactions performed by the one or more subsequent microservices executing the production versions of the one or more subsequent microservices.

In embodiments, the device can be configured to insert the identifier into at least one of a Hypertext Transfer Protocol (HTTP) header portion of the request or a Hypertext Transfer Protocol Secure (HTTPS) header portion of the request. The device can be configured to generate the service graph of the first call chain to identify a failure between the plurality of microservices, a number of times each microservice of the plurality of microservices has been called, and a rate of success of using the plurality of microservices of the first call chain.

In at least one aspect, a non-transitory computer readable medium is provided. The non-transitory computer readable medium can store program instructions for causing one or more processors to receive at a first microservice of a plurality of microservices forming a first call chain, a request from a client. The first microservice can execute a canary version of the first microservice and one or more subsequent microservices of the first call chain can execute production versions of the one or more subsequent microservices. The instructions can cause the one or more processors to include into a header portion of the request an identifier indicating the first microservice is the canary version of the first microservice. The instructions can cause the one or more processors to provide, to the one or more subsequent microservices of the first call chain, the request with the identifier. The one or more subsequent microservices can include one or more tags in the request to identify that the one or more subsequent microservices are executing the production versions of the one or more subsequent microservices while retaining the identifier with the request as the request is processed by the one or more subsequent microservices forming the first call chain. The instructions can cause the one or more processors to generate a service graph identifying transactions processed by the canary version of the first microservice and the production versions of the one or more subsequent microservices.

In embodiments, the instructions can cause the one or more processors to generate the service graph including parameters of the transactions processed by the first call chain including the first microservice executing the canary version of the first microservice and the parameters of the transactions processed by a second call chain including the first microservice executing a production version of the first microservice.

