System and method for self-orchestrated canary release deployment within an API gateway architecture

API gateways are updated utilizing canary release deployment in which a message broker delivers update messages to the API gateways first using a point-to-point messaging model and then a publish-and-subscribe messaging model. All the API gateways are capable of receiving point-to-point messages and publish-and-subscribe messages. First, a canary API gateway receives an update message from a message queue of the message broker and deploys the associated update on the canary API gateway. If deployment of the update is successful, then non-canary API gateways receive the update message from a message topic of the message broker and deploy the associated update on the non-canary API gateways.

BACKGROUND

An application program interface (API) gateway provides an intermediary between an API service and an API consumer that consumes the API service. One of the intermediary roles of an API gateway is to expose the API service to the API consumer and to control the traffic between the API consumer and the API service. Typically, the API service consists of a plurality of APIs, and each API has an endpoint that provides an entry to the API for the API consumer. An API gateway exposes each API endpoint by acting as a proxy for the respective API. An API gateway, or a grouping of API gateways, acts as a facade of endpoints for the API consumer to consume the service offered by each API. A typical consumption by an API consumer is a request to an API followed by a response by the API. The API gateway's facade of the API service enables the API gateway to receive requests from an API consumer for an exposed API, route requests to an appropriate API, route API responses to an appropriate API consumer, enforce security of each request, and perform traffic manipulation such as performing rate limiting on calls to an API.

In a typical API gateway architecture, a plurality of API consumers, such as devices, applications, and websites, are communicatively coupled to a set of API gateways in order to consume API services. The set of API gateways provide a facade for groupings of a plurality of API services, and each of the API services comprise at least one API. Each API gateway provides multitenant capabilities for groupings of API services. Such multitenant capabilities include load balancing strategies to route requests to one of a plurality of identical or similar API services.

The functionality of an API gateway is typically controlled by configuration data. In a traditional API gateway architecture, the configuration data of an API gateway is updated utilizing a release orchestration tool. A traditional release orchestration tool treats each API gateway as a node, and groups of nodes are updated in phases. The first group of nodes is traditionally updated as a canary release, i.e., a limited test release to ensure the update meets a quality standard and is functional within the first group of nodes. The first group of nodes that is traditionally updated by a traditional release orchestration tool allows for the detection of an update failure that, if present, is isolated to the first group of nodes acting as the canary. This canary release process avoids the massive failure that would have occurred if the update had been deployed to all the nodes at once.

However, with a traditional release orchestration tool, a development team that wishes to implement an update to the set of API gateways must wait for the release orchestration tool to implement a first phase canary release of the update. A typical release orchestration tool is a centralized tool operating apart from the set of API gateways, traditionally requiring a manual process to execute the release orchestration tool to make updates to API gateways. Traditionally, even if fifty or more updates were required in a day, such updates would be batch deployed once a day, typically at night, and that daily deployment would be considered fragile due to the release orchestration tool operating as a centralized tool apart from the API gateways. Further, the failures of the deployment of updates is indicative of the manual processing required to monitor a traditional release orchestration tool's deployment, indicating the fragility of a traditional release orchestration tool's operation.

Consequently, there is currently a significant need in the API services arts to provide for a self-orchestrated canary release deployment system and method within an API gateway architecture capable of decentralized deployment of API gateway updates in real-time manner, thereby providing a more efficient and robust API service provider system.

SUMMARY

Embodiments of the present disclosure provide a technical solution to the technical problem of providing an efficient system and method for self-orchestrated canary release deployment within an API gateway architecture.

The disclosed technical solution includes providing a message broker within an API gateway architecture. The message broker first utilizes a point-to-point messaging model to cause the update of a canary API gateway that tests the update. Then, the message broker utilizes a publish-and-subscribe messaging model to cause the update of remaining non-canary API gateways based on the update that was previously deployed by the canary API gateway.

In one embodiment, the message broker receives an update message for an update to a set of API gateways. In one embodiment, the message broker places the update message in a message queue of a message queue module for point-to-point messaging. In one embodiment, each API gateway is configured to be able to initiate a pull of the update message, and the message queue module ensures that only one API gateway receives the update message to become a canary API gateway.

In one embodiment, one of the API gateways is the first to request a pull of the update message from the message queue module, and this API gateway is designated a canary API gateway. In one embodiment, the message queue module of the message broker simultaneously transmits the update message to the canary API gateway and removes the update message from the message queue, so that no other API gateway modules can request a pull of the update message. In one embodiment, the canary API gateway deploys the update referenced in the update message with a deployment module, which tests for a successful deployment. If the deployment of the update to the canary API gateway is determined to be successful, then the canary API gateway transmits the update message to a message topic module of the message broker.

In one embodiment, the message topic module of the message broker provides the update message as a message topic for publish-and-subscribe messaging. In one embodiment, the message topic is available to all of the API gateways excluding the canary API gateway. In one embodiment, the non-canary API gateways are configured to be able to initiate a subscription of the message topic. In one embodiment, the message topic module transmits the message topic to all of the non-canary API gateways that subscribed to the message topic. In one embodiment, each non-canary API gateway that receives the message topic deploys the update referenced in the update message with a respective deployment module.

DETAILED DESCRIPTION

Embodiments will now be discussed with reference to the accompanying figures, which depict one or more exemplary embodiments. Embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein, shown in the figures, and/or described below. Rather, these exemplary embodiments are provided to allow a complete disclosure that conveys the principles of the invention, as set forth in the claims, to those of skill in the art.

Overview

As discussed in more detail below, embodiments of the present disclosure represent a technical solution to the technical problem of effectively and efficiently deploying updates to a plurality of API gateway modules. In one embodiment, the technical solution includes a disclosed message broker module that utilizes a point-to-point messaging model to deliver update message data to an API gateway module acting as a canary API gateway module and utilizes a publish-and-subscribe messaging model to deliver the update message data to API gateway modules acting as non-canary gateway modules.

FIG. 1Ais functional block diagram of a self-orchestrated canary release deployment system10, in accordance with one embodiment. In one embodiment, the message broker module provides an asynchronous messaging service between autonomous environments, systems, applications, modules, and other messaging clients as discussed herein, or as known in the art at the time of filing, or as developed, or becomes available, after the time of filing. In one embodiment, the message broker module provides messaging services between an engineer system and a plurality of API gateway modules18. In one embodiment, the message broker module includes a message queue module and a message topic module. In one embodiment, the message broker module utilizes the Java Message Service (JMS) messaging standard.

In one embodiment, the message queue module of the message broker module implements a point-to-point messaging model in which update message data14is delivered from an engineer system to a single API gateway module18A via the message queue module. In one embodiment, an engineer utilizes an engineer system to deliver update message data14to a destination of message queue data12of the message queue module. In one embodiment, the update message data14is held in the message queue data12until an API gateway module18A initiates a pull of the message queue data12comprising the update message data14. In one embodiment, the message queue module ensures that only one API gateway module18A can initiate a pull of the message queue data12comprising the update message data14. In one embodiment, the message queue module holds the message queue data12comprising the update message data14until a single API gateway module18A initiates a pull of the message queue data. In one embodiment, in response to a single API gateway module18A initiating a pull of the message queue data12comprising the update message data14, the message queue module delivers the update message data14to the pulling API gateway module18A as pulled queue data and removes the update message data14from the message queue data12. In one embodiment, removal of the update message data14from the message queue data12ensures that no other API gateway modules18B and18C through18N can initiate a pull of the message queue data12after the initial pull by the single API gateway module18A, which acts as a canary API gateway module.

In one embodiment, the message topic module of the message broker module implements a publish-and-subscribe messaging model in which update message data14is delivered from a first API gateway module18A acting as a canary API gateway module, which had pulled the update message data14from the message queue module, to a plurality of API gateway modules18B and18C through18N via the message topic module. In one embodiment, a single API gateway module18A acting as a canary API gateway module delivers the update message data14to a destination of message topic data16of the message topic module. In one embodiment, the update message data14is then available to be delivered to any API gateway module18B and18C through18N, i.e., a non-canary API gateway module, that initiates a subscription of the message topic data16comprising the update message data14. In one embodiment, the message topic module ensures that all API gateway modules18B and18C through18N, except the API gateway module18A that had delivered the update message data to the message topic module, can initiate a subscription of the message topic data16comprising the update message data14. In one embodiment, in response to an API gateway module18B and18C through18N initiating a subscription of the message topic data16comprising the update message data14, the message topic module delivers the update message data14to the subscribing API gateway module18B and18C through18N as subscribed topic data. In one embodiment, any number of API gateway modules18B and18C through18N can initiate a subscription of the message topic data16comprising the update message data14.

In one embodiment, when API gateway modules18receive update message data14, whether from the message queue module or from the message topic module, the API gateway modules18deploy an update based on the update message data14. In one embodiment, deployment modules of the API gateway modules18deploy an update. In one embodiment, the update of the API gateway modules18is an update to the metadata of the API gateway modules18. In one embodiment, the update message data14provides a reference to a registry module that includes registry data. In one embodiment, the registry data includes a persistent store of update metadata to be updated to the API gateway modules18. In one embodiment, the update message data14provides a reference to the registry data associated with the respective update metadata to be updated to the API gateway modules18.

As noted above, traditionally the updates to API gateway modules18were conducted by a release orchestration tool. Traditionally, a release orchestration tool executed jobs, and a job would be to update a fleet of API gateway modules18. Traditionally, in order to update the complete fleet of API gateway modules18, the release orchestration tool would be required to maintain the state of each of the API gateway modules18in the fleet, so that the job of performing an update can be accomplished on each of the API gateway modules18in the fleet. Consequently, the traditional release orchestration tool was inefficient because the release orchestration tool required maintenance of the state of each of the API gateway modules18in a fleet to properly perform the job.

To address this long standing technical problem, the disclosed message broker module makes update message data14available to a plurality of API gateway modules18without needing to know the state of each of those API gateway modules18. As discussed herein, the disclosed API gateway modules18are configured to be able to initiate a pull of message queue data12for when the first API gateway module18A is acting as a canary, and to be able to initiate a subscription of message topic data16for when the API gateway modules18B and18C through18N are acting as a non-canary.

As noted above, traditionally the release orchestration tool would require that the state of each of the API gateway modules18be maintained by the release orchestration tool. Traditionally, this requirement led to inefficiencies in implementing additional API gateway modules18into an API service system. The increased time to add API gateway modules18and increased error conditions when incorrect states of the API gateway modules18would be maintained. Such maintenance of states was traditionally required by a release orchestration tool because an update release would need to be staged in phases in which a portion of a fleet of API gateway modules18would be allocated to a phase, all the API gateways modules18of the phase would be brought off-line, the update would be performed on those API gateway modules18, and then the API gateway modules18would be brought back on-line. Traditionally, such phases, with their corresponding taking API gateway modules18off-line, traditionally resulted in a degradation in API service availability.

To address this long standing technical problem, the disclosed message broker module makes update message data14available to a plurality of API gateway modules18without any of the API gateway modules18needing to be taken off-line. As discussed herein, the disclosed API gateway modules18are configured to each be able to initiate a pull of message queue data12for when the API gateway module18A is acting as a canary, and to be able to initiate a subscription of message topic data16for when the API gateway module18B and18C through18N is acting as a non-canary.

As noted above, traditionally a release orchestration tool would stage updates to a fleet of API gateway modules18in phases. For example, a fleet of API gateway modules18may be divided into four groups for four phases, and during each phase, a respective one of the four groups would be unavailable during the phase. Traditionally, due to such unavailability, the phases orchestrated by a release orchestration tool would be done on a periodic basis of a batch of updates, such as once a day. Even though an engineer may have had an update immediately ready to be deployed to the fleet of API gateway modules18, traditionally the engineer's update would not be deployed until the scheduled batch update is launched. Such a delay traditionally caused inefficiencies within an API service system as the updates were delayed in their deployment. To address this long standing technical problem, the disclosed message broker module makes update message data14available to the API gateway modules18on a real-time basis, allowing for each update to be deployed after the message broker module receives update message data14from an engineer system.

As noted above, traditionally a release orchestration tool would designate which API gateway modules18would be designated for which phase. Traditionally, the release orchestration tool determined which API gateway modules18would be updated in the first phase and centrally determined the phase deployment based on a maintenance of API gateway module state. Such central designation of API gateway modules18was prone to error as the record of API gateway module states was traditionally inconsistent, resulting in a fragile deployment of updates and inefficiencies due to increased failure rates of the updates.

To address this long standing technical problem, the disclosed API gateway modules18each determine their own availability to serve either as a canary API gateway module18A or as a non-canary API gateway module of the API gateway modules18B and18C through18N. In one embodiment of the disclosed API gateway modules18, each API gateway module is capable of receiving update message data14either as pulled message queue data12or as subscribed message topic data16in a decentralized fashion. Further, any additional API gateway modules18can be added to the API service system by including with the API gateway modules18the capability of receiving update message data14both as pulled message queue data12and as subscribed message topic data16.

Embodiments of the present disclosure provide highly efficient, effective, and versatile systems and methods for self-orchestrated canary release deployment within an API gateway architecture. However, the disclosed embodiments do not encompass, embody, or preclude other forms of innovation in the area of API service systems.

In addition, the disclosed embodiments of systems and methods for self-orchestrated canary release deployment within an API gateway architecture are not abstract ideas for at least several reasons.

First, the disclosed systems and methods for self-orchestrated canary release deployment within an API gateway architecture are not abstract ideas because they are not merely an idea itself (e.g., can be performed mentally or using pen and paper). For example, it is not possible for the human mind to comprehend and validate all of the possible update messages that need to be transmitted to all of the possible API gateway modules with all of their respective current metadata configurations in relative real-time deployment, even with pen and paper to assist the human mind.

In contrast, the disclosed embodiments receive update message data and first transmit the update message data to an API gateway module indicating, via a point-to-point messaging model, its availability to deploy the update acting as a canary API gateway module, and second transmit the update message data to a plurality of API gateway modules indicating, via a publish-and-submit messaging model, their availability to deploy the update acting as non-canary API gateway modules.

Second, the disclosed systems and methods for self-orchestrated canary release deployment within an API gateway architecture are not abstract ideas because they are not a fundamental economic practice (e.g., are not merely creating a contractual relationship, hedging, mitigating a settlement risk, etc.).

In contrast, the disclosed embodiments provide for updating a plurality of API gateway modules in a real-time manner utilizing a de-centralized process of a point-to-point messaging model and a subscribe-and-publish messaging model. This allows the API gateway modules to receive updates near real-time without having to take an API gateway module off-line, which provides an improved experience for API consumers of the API services. In addition, embodiments of the present disclosure allow for reduced use of processor cycles, memory, bandwidth, and power consumption associated with self-orchestrated canary release deployment within an API gateway architecture, compared to an approach utilizing a release orchestration tool. In one embodiment, the reduced use of memory of the present disclosure is achieved through the absence of a traditional release orchestration tool that required memory to store the states of a number of API gateway modules. In one embodiment, the reduced use of processor cycles of the present disclosure is achieved through the absence of a traditional release orchestration tool that required processor cycles to monitor the states of a number of API gateway modules.

Third, the disclosed systems and methods for self-orchestrated canary release deployment within an API gateway architecture are not abstract ideas because they are not a method of organizing human activity (e.g., managing a game of bingo), but are rather, in one embodiment, tools for enabling engineers to continually deploy updates to a number of API gateway modules to provide a facade to one or more API service modules that provide API services to API consumers.

In addition, using the disclosed embodiments, an API service system is provided that significantly improves the field of update deployment to API gateway modules by enabling near real-time deployment of an update without any API gateway module needing to be taken off-line, according to one embodiment. Therefore, both human and non-human resources are utilized more efficiently.

Fourth, although mathematics may be used in the disclosed systems and methods for self-orchestrated canary release deployment within an API gateway architecture, the disclosed and claimed systems and methods, are not abstract ideas because they are not simply a mathematical relationship/formula.

In contrast, the disclosed embodiments provide for updating a plurality of API gateway modules in a real-time manner utilizing a de-centralized process of a point-to-point messaging model and a subscribe-and-publish messaging model. This results in the tangible effect of the continued functioning, through the API gateway modules, of a complex computing system comprising an API service system. In addition, using the disclosed embodiments, an API service system is provided that increases loyalty to the API services being provided because users of the API consumer systems find the API consumer systems to be more reliable. This results in repeat customers of the API consumer systems, and reduced abandonment of use of applications associated with the API consumer systems, according to one embodiment.

Exemplary Environment

FIG. 1Bis a functional block diagram of a production environment100for self-orchestrated canary release deployment within an API gateway architecture, in accordance with one embodiment. It is to be understood that certain elements ofFIG. 1Bcorrespond to respective elements ofFIG. 1Aand may be used interchangeably when referring toFIGS. 1A and 1B. Referring toFIGS. 1A and 1Btogether, the update message data104ofFIG. 1Bcorresponds to the update message data14ofFIG. 1A, the message queue data132ofFIG. 1Bcorresponds to the message queue data12ofFIG. 1A, the message topic data136ofFIG. 1Bcorresponds to the message topic data16ofFIG. 1A, the first API gateway module141ofFIG. 1Bcorresponds to the first API gateway module18A ofFIG. 1A, the second API gateway module142ofFIG. 1Bcorresponds to the second API gateway module18B ofFIG. 1A, the third API gateway module143corresponds to the third API gateway module18C ofFIG. 1A, and the nth API gateway module144ofFIG. 1Bcorresponds to the nth API gateway module18N ofFIG. 1A. It is to be further understood that the API gateway modules141,142, and143through144depicted as a plurality of API gateway modules140ofFIG. 1Bcollectively correspond to the API gateway modules18ofFIG. 1A.

Referring toFIGS. 1A and 1Btogether, in one embodiment, the production environment100includes a service provider computing environment110, an engineer computing environment102, and a consumer computing environment106. In one embodiment, the computing environments110,102, and106are communicatively coupled to each other with one or more communication channels101. In one embodiment, the communication channels101include one or more physical or virtual networks such as any network discussed herein, and/or as known in the art at the time filing, and/or as becomes available after the time of filing.

According to one embodiment, the service provider computing environment110represents one or more computing systems, such as one or more servers and/or distribution centers, that are configured to receive, execute, and host one or more API service systems for access by one or more consumers of services, according to one embodiment. Furthermore, the service provider computing environment110represents one or more computing systems that are configured to receive, execute, and host one or more data management systems (e.g., applications) for access by one or more users, according to one embodiment. The service provider computing environment110can be a traditional data center computing environment, a virtual asset computing environment (e.g., a cloud computing environment), or a hybrid between a traditional data center computing environment and a virtual asset computing environment, according to various embodiments.

According to one embodiment, the service provider computing environment110includes an API service system120. It is to be understood that the service provider computing environment110may have any number of such systems. It is also to be understood that one or more API service systems120may reside in its/their own computing environment that is separate from the service provider computing environment110. For example, a service provider may host one API service system120on its premises and another API service system120on a third-party's premises or in the cloud.

Although not shown, in one embodiment, the service provider computing environment110includes a data management system. In one specific illustrative example, the data management system is a financial data management system. In one embodiment, the data management system may be a consumer of the API services provided by the API service system120.

Although not shown, in one embodiment, the production environment100includes a user computing environment that includes a user system. In one embodiment, the users of a data management system utilize the user computing environments to interact with the data management system.

In one embodiment, the API service system120includes an API service module122, a plurality of gateway modules141,142, and143through144(collectively140), a registry module125, and a message broker module130. In one embodiment, the API service module122comprises a plurality of APIs that provide respective services. In one embodiment, there are a plurality of API service modules122, and each API service module122comprises a plurality of APIs. In this embodiment, each API service module122may comprise the same plurality of APIs, some of the same plurality of APIs, and/or different pluralities of APIs. In one embodiment, two or more APIs of the API service module122provide services that are related to a data management system. In one embodiment, such two or more APIs of the API service module122form one or more groupings of APIs. Although a single API service module122is depicted as residing within the API service system120, it is to be understood that any number of API service modules122may reside in any number of API service systems120. In one embodiment, each API of the API service module122comprises an endpoint that provides an entry to the API for an API consumer.

In one embodiment, a plurality of API gateway modules140expose each API endpoint of the API service module122by being a proxy for the respective API, thereby creating a facade of endpoints for an API consumer to consume the service offered by each API.FIG. 1Bdepicts a first API gateway module141, a second API gateway module142, and a third API gateway module143through an nth API gateway module144. It is to be understood that such API gateway modules141,142, and143through144are representative of a plurality of API gateway modules140, including the nth API gateway module144representing any number of API gateway modules. Although the API gateway modules140are depicted as residing in the API service system120, it is to be understood that any number of API gateway modules140may reside in any number of API service systems120. Furthermore, any number of API gateway modules140may serve as a facade for any number of API service modules122residing in any number of API service systems120communicatively coupled with the communication channels101. In one embodiment, the API gateway modules140provide a facade of API services of the API service modules122, and the facade enables the API gateway modules140to receive requests from an API consumer for an exposed API of the API service module122, to route requests to an appropriate API of the API service module122, to route API responses from the appropriate API of the API service module122, to enforce security of each request, to perform traffic manipulation such as performing rate limiting on calls to an API of the API service module122, and to perform other API gateway policies as discussed herein, or as known in the art at the time of filing, or as developed, or becomes available, after the time of filing.

In one embodiment, an API consumer, such as a device or application, consumes API services of the API service module122. In one embodiment, the consumer computing environment106includes an API consumer system107. It is to be understood that while only one consumer computing environment106is depicted, any number of consumer computing environments106may be included in the production environment100, for any number of API consumers. It is to be further understood that while only one API consumer system107is depicted, any number of API consumer systems107may be included with any number of consumer computing environments106. In one embodiment, the API consumer system107includes an API consumer module108. It is to be understood that while only one API consumer module108is depicted, any number of API consumer modules108may be included in any number of API consumer systems107.

In one embodiment, an API consumer module108consumes an API service of the API service module122via an API gateway module of the API gateway modules140. In one embodiment, the API consumer module108transmits a request to one of the API gateway modules140utilizing a proxy endpoint of an API, and that one of the API gateway modules140transmits the request to the API service module122. In this embodiment, the API service module122transmits a response to the applicable API gateway module of the API gateway modules140, which further transmits the response back to the API consumer module108.

In one embodiment, the API gateway modules141,142, and143through144include respective metadata171,172, and173through174that include configuration information for the respective API gateway module141,142, and143through144. In one embodiment, the respective metadata171,172, and173through174includes configuration information for the respective one of the API gateway modules140to be a proxy for an API of the API service module122. In one embodiment, the respective metadata171,172, and173through174is required to be updated. In one embodiment, the data for an update is provided by registry data126of the registry module125. In one embodiment, a respective deployment module161,162, and163through164of the API gateway modules140deploys the update of the registry data126to the respective metadata171,172, and173through174.

As a specific illustrative example, an API service module122may reside on a server with a first domain name server (DNS) to which one of the API gateway modules140routes based on the respective metadata171,172, and173through174. In this example, if the server is changed to a second DNS, then an engineer may utilize the engineer system103to update the registry data126to replace the reference to the first DNS with a reference to the second DNS for the applicable API service module122. In this example, after one of the API gateway modules140receives update message data104, whether as message queue data132or message topic data136, the respective deployment module161,162, and163through164updates the respective metadata171,172, and173through174with the second DNS from the registry data126that was referenced by the update message data104. In this example, after the update to the respective metadata171,172, and173through174, the applicable one of the API gateway modules140will route consumer requests to the applicable API service module122based on the second DNS that was updated in the respective metadata171,172, and173through174.

As a further specific illustrative example, an API service module122may utilize a version one of an OAuth protocol, which one of the API gateway modules140enforces when receiving requests from an API consumer module108. In this example, if the API service module122changes its protocol to version two of OAuth, then an engineer may utilize the engineer system103to update the registry data126to replace the reference to version one of the OAuth protocol with a reference to version two of the OAuth protocol for the applicable API service module122. In this example, after one of the API gateway modules140receives update message data104, whether as message queue data132or message topic data136, the respective deployment module161,162, and163through164updates the respective metadata171,172, and173through174with the version two of the OAuth protocol from the registry data126that was referenced by the update message data104. In this example, after the update of the respective metadata171,172, and173through174, the applicable one of the API gateway modules140will enforce version two of the OAuth protocol for consumer requests to the applicable API service module based on the update to the respective metadata171,172, and173through174.

In one embodiment, an engineer utilizes an engineer system103of the engineer computing environment102to provide the registry data126that is utilized by the respective deployment module161,162, and163through164of the API gateway modules140. It is to be understood that while one engineer computing environment102is depicted, there may be any number of engineer computing environments102. It is to be further understood that while only one engineer system103is depicted, there can be any number of engineer systems103included in any number of engineer computing environments102. In one embodiment, after an engineer enables registry data126comprising updated configuration data to be available to the API gateway modules140, the engineer alerts the API gateway modules140with an update message data104via the message broker module130.

In one embodiment, update message data104is transmitted from the engineer system103to a message queue module131of the message broker module130. In one embodiment, the update message data104includes a reference to associated configuration data represented in the registry data126of the registry module125. In one embodiment, the message queue module131operates under a point-to-point messaging model. In one embodiment, the message queue module131receives the update message data104from the engineer system103and stores the update message data104as message queue data132. It is to be understood that any of the API gateway modules141,142, or143through144is capable of initiating a pull of the message queue data132, and the depiction of the first API gateway module141as initiating such a pull is for illustrative purposes. In one embodiment, the update message data104is held in the message queue data132until the first API gateway module141initiates a pull of the message queue data132comprising the update message data104. In one embodiment, the message queue module131prevents any other API gateway module or the API gateway modules142and143through144from initiating a second pull of the message queue data132comprising the update message data104. In one embodiment, the message queue module131accomplishes such prevention by removing the update message data104from the message queue data132. In one embodiment, in response to the first API gateway module141initiating a pull of the message queue data132comprising the update message data104, the message queue module131transmits the message queue data132comprising the update message data104to the first API gateway module141which stores the message queue data132as pulled queue data151comprising the update message data104.

In one embodiment, two or more engineers transmit update message data104from the engineer system103to the message queue module131. For example, a first engineer may implement a first configuration update to the registry data126and transmit first update message data104related to the first configuration update to the message queue module131. In this example, a second engineer may implement a second configuration update to the registry data126and transmit second update message data104related to the second configuration update to the message queue module131. In this example, the message queue module131stores the first update message data104as first message queue data132and stores the second update message data104as second message queue data132. Of the plurality of API gateway modules140, one of them will be the first to initiate a pull of the message queue data132comprising the first update message data104and act as the first API gateway module141, and thereafter the message queue module131prevents all other API gateway modules142and143through144from initiating such a pull in relation to the first update message data104. Similarly in this example, of the plurality of API gateway modules140, one of them will be the first to initiate a pull of the message queue data132comprising the second update message data104and act as the first API gateway module141, and thereafter the message queue module131prevents all other API gateway modules142and143through144from initiating such a pull in relation to the second update message data104. It is to be understood from this example that any API gateway module of the API gateway modules140can be a first API gateway module141by being the first to initiate a pull of message queue data132comprising the update message data104. It is also to be understood from this example that only one API gateway module of the API gateway modules140is permitted by the message queue module131to be the first API gateway module141for any one instance of update message data104.

In one embodiment, a single first API gateway module141receives the message queue data132comprising the update message data104. In one embodiment, the first API gateway module141receives the message queue data132comprising the update message data104, and stores such as pulled queue data151comprising the update message data104. In one embodiment, a first deployment module161of the first API gateway module141deploys the update associated with the update message data104. In one embodiment, the registry data126comprises such an update, and the update message data104is associated with the applicable update of registry data126. In one embodiment, the first deployment module161applies the update to the first metadata171. In one embodiment, an update to the first metadata171is a configuration change to the first API gateway module141.

In this specific illustrative example, the first API gateway module141acts as a canary API gateway module because it is the first API gateway module to deploy the update within the production environment100. In one embodiment, the first deployment module161tests the update of the first metadata171. In one embodiment, the first deployment module161tests that the first metadata171has data integrity. For example, the first metadata171may contain a hash map and the first deployment module161may determine that the keys of the hash map are scoped correctly. In one embodiment, the first deployment module161tests that the first metadata171routes to the API service module122correctly. For example, a smoke test may be performed to determine that a request is properly responded to by the API service module122.

In one embodiment, if a test of an update performed by the first deployment module161fails, then the update is uninstalled from the first API gateway module141, and a failure message is transmitted to the engineer system103via the message broker module130. It is to be understood that an unsuccessful deployment of an update by the first API gateway module141avoids the system-wide introduction of a failed update to other API gateway modules142and143through144. In one embodiment, if a test of an update performed by the first deployment module161succeeds, then the update message data104is transmitted to the other API gateway modules142and143through144via the message broker module130.

In one embodiment, after a successful deployment of an update by the first API gateway module141acting as a canary API gateway module, the first API gateway module141transmits the pulled queue data151comprising the update message data104to the message topic module135of the message broker module130. In one embodiment, the update message data104includes a reference to associated configuration data represented in the registry data126of the registry module125. In one embodiment, the message topic module135operates under a publish-and-subscribe messaging model. In one embodiment, the message topic module135receives the pulled queue data151comprising the update message data104from the first API gateway module141and stores the update message data104as message topic data136. In one embodiment, the message topic data136comprising the update message data104is available to be delivered to any API gateway modules142and143through144that was not a first API gateway module141that had acted as a canary API gateway module with respect to the update message data104.

In one embodiment, a second API gateway module142initiates a subscription of the message topic data136comprising the update message data104. In one embodiment, in response to the second API gateway module142initiating a subscription of the message topic data136comprising the update message data104, the message topic module135delivers the message topic data136comprising the update message data104to the second API gateway module142. In one embodiment, the second API gateway module142receives the message topic data136comprising the update message data104, and stores such as first subscribed topic data152comprising the update message data104. In one embodiment, a second deployment module162of the second API gateway module142deploys the update associated with the update message data104. In one embodiment, the registry data126comprises such an update, and the update message data104is associated with the applicable update of the registry data126. In one embodiment, the second deployment module162applies the update to the second metadata172. In one embodiment, an update to the second metadata172is a configuration change to the second API gateway module142.

In one embodiment, a third API gateway module143initiates a subscription of the message topic data136comprising the update message data104. In one embodiment, in response to the third API gateway module143initiating a subscription of the message topic data136comprising the update message data104, the message topic module135delivers the message topic data136comprising the update message data104to the third API gateway module143. In one embodiment, the third API gateway module143receives the message topic data136comprising the update message data104, and stores such as second subscribed topic data153comprising the update message data104. In one embodiment, a third deployment module163of the third API gateway module143deploys the update associated with the update message data104. In one embodiment, the registry data126comprises such an update, and the update message data104is associated with the applicable update of the registry data126. In one embodiment, the third deployment module163applies the update to the third metadata173. In one embodiment, an update to the third metadata173is a configuration change to the third API gateway module143.

It is to be understood that any API gateway module, including the nth API gateway module144, may initiate a subscription of the message topic data136comprising the update message data104. In one embodiment, an nth API gateway module144initiates a subscription of the message topic data136comprising the update message data104. In one embodiment, in response to the nth API gateway module144initiating a subscription of the message topic data136comprising the update message data104, the message topic module135delivers the message topic data136comprising the update message data104to the nth API gateway module144. In one embodiment, the nth API gateway module144receives the message topic data136comprising the update message data104, and stores such as nth subscribed topic data154comprising the update message data104. In one embodiment, an nth deployment module164of the nth API gateway module144deploys the update associated with the update message data104. In one embodiment, the registry data126comprises such an update, and the update message data104is associated with the applicable update of the registry data126. In one embodiment, the nth deployment module164applies the update to the nth metadata174. In one embodiment, an update to the nth metadata174is a configuration change to the nth API gateway module144.

It is to be understood that, in one embodiment, the first API gateway module141is prevented from initiating a subscription of the message topic data136because it has already deployed the update represented by the update message data104. In one embodiment, the message topic module135associates the first API gateway module141with the message topic data136to indicate that the first API gateway module141had acted as a canary gateway module and is precluded from initiating a subscription of the message topic data comprising the update message data104.

In one embodiment, the message topic module135ensures that all API gateway modules142and143through144, except the first API gateway module141that had delivered the update message data104to the message topic module135, can initiate a subscription of the message topic data136comprising the update message data104. In one embodiment, in response to one of the API gateway modules142and143through144initiating a subscription of the message topic data136comprising the update message data104, the message topic module135delivers the message topic data136comprising the update message data104to the respective subscribing API gateway module of the API gateway modules142and143through144.

In one embodiment, the second API gateway module142stores the message topic data136comprising the update message data104as first subscribed topic data152comprising the update message data104and performs an update of the second metadata172with the second deployment module162. In one embodiment, the third API gateway module143stores the message topic data136comprising the update message data104as second subscribed topic data153comprising the update message data104and performs an update of the third metadata173with the third deployment module163. In one embodiment, the nth API gateway module144stores the message topic data136comprising the update message data104as nth subscribed topic data154comprising the update message data104and performs an update of the nth metadata174with the nth deployment module164. It is to be understood that any number of nth API gateway modules144acting as non-canary gateway modules144may initiate a subscription of the message topic data136comprising the update message data104.

FIG. 2is a functional block diagram of an illustrative API gateway module200for self-orchestrated canary release deployment within an API gateway architecture, in accordance with one embodiment. Referring toFIGS. 1A, 1B, and 2together, the API gateway module241may be stipulated to be one of API gateway modules18A,18B,18C through18N,141,142, and143through144. In one embodiment, the illustrative API gateway module241includes a deployment module261with which updates based on the registry data126can be applied to metadata271.

In one embodiment, the API gateway module241acts as a canary API gateway module and receives message queue data132comprising the update message data104, and stores such as pulled queue data251comprising the update message data104. In this embodiment, the subscribed topic data252is not utilized. It is to be understood thatFIG. 1Bdepicts the first API gateway module141without subscribed topic data because it is acting as a canary API gateway module, nevertheless it is capable of acting as a non-canary as depicted with the API gateway module241.

In one embodiment, the API gateway module241acts as a non-canary API gateway module and receives message topic data136comprising the update message data104, and stores such as subscribed topic data252comprising the update message data104. In this embodiment, the pulled queue data251is not utilized. It is to be understood thatFIG. 1Bdepicts the second API gateway module142and the third API gateway module143through the nth API gateway module144without pulled queue data because it is acting as a non-canary API gateway module, nevertheless they are each capable of acting as a canary as depicted with the API gateway module241.

Exemplary Process

FIGS. 3A and 3Bare flow diagrams of a process300for self-orchestrated canary release deployment within an API gateway architecture, in accordance with one embodiment. Referring toFIGS. 1B, 2, 3A, and 3Btogether, the process300for self-orchestrated canary release deployment within an API gateway architecture begins at ENTER OPERATION301and process flow proceeds to RECEIVE FIRST UPDATE MESSAGE DATA OPERATION303.

In one embodiment, at RECEIVE FIRST UPDATE MESSAGE DATA OPERATION303, the message queue module131of the message broker module130receives first update message data104. In one embodiment, the engineer system103of the engineer computing environment102transmits the first update message data104to the message queue module131. In one embodiment, an engineer utilizes the engineer system103to generate the update message data104. In one embodiment, the engineer system103is utilized by an engineer to add update configuration data to the registry data126of the registry module125. In one embodiment, the first update message data104references the update configuration data of the registry data126. In one embodiment, the first update message data104is a notification that update configuration data is available within the registry data126. In one embodiment, the update configuration data of the registry data126is deployable to at least one API gateway module241. In one embodiment, the deployment module261of the API gateway module241deploys the update configuration data of the registry data126as an update to the metadata271.

In one embodiment, once the message queue module131of the message broker module130receives the first update message data104at RECEIVE FIRST UPDATE MESSAGE DATA OPERATION303, process flow proceeds to STORE MESSAGE QUEUE DATA OPERATION305.

In one embodiment, at STORE MESSAGE QUEUE DATA OPERATION305, the message queue module131of the message broker module130stores the first update message data104from the engineer system103as message queue data132comprising the first update message data104. In one embodiment, the message queue module131provides the message queue data132as a staging area that contains messages, such as update message data104, that have been sent by a sender and are waiting to be read by only one receiver. It is to be understood that the term queue is not meant to limit the receipt of messages to an order in which the messages were sent. In one embodiment, the message queue module131guarantees that each update message data104is delivered to only one receiver, such as the first API gateway module141.

In one embodiment, at INITIATE FIRST PULL OF MESSAGE QUEUE DATA OPERATION307, the first API gateway module141of a plurality of API gateway modules241initiates a first pull of the message queue data132comprising the first update message data104. In one embodiment, the first API gateway module141initiates the first pull from the message queue module131. In one embodiment, the message queue module131conforms to a point-to-point messaging model. In one embodiment, a point-to-point messaging model routes messages from a sender to a single receiver. In one embodiment, a point-to-point messaging model implements the maintenance of a queue of messages, such as the message queue data132comprising the first update message data104. In one embodiment, a single API gateway module241is a receiver of an update message data104. In one embodiment, any API gateway module241is capable of initiating a pull of message queue data132and thus is capable of performing the role of the first API gateway module141as a canary.

In one embodiment, a point-to-point messaging model implements the capability of any number of senders, such as any number of engineer systems103, to be able to send any number of update message data104to the message queue module131, which holds each update message data104until a first API gateway module141initiates a pull of the respective update message data104. In one embodiment, the message queue module131ensures that there is only one first API gateway module141. In one embodiment, the message queue module131retains the message queue data132comprising the first update message data104until a first API gateway module141initiates a first pull of the message queue data132.

In one embodiment, each API gateway module of the plurality of API gateway modules241is configured to be an API proxy of at least one API service module122for at least one API consumer module108. In one embodiment, the first API gateway module141is a canary API gateway module that initiates a first pull before any other API gateway module of the plurality of API gateway modules241. In one embodiment, each API gateway module of the plurality of API gateway modules241is configured to initiate a plurality of pulls of message queue data132from the message queue module131of the message broker module130, wherein the plurality of pulls conforms to a point-to-point messaging model.

In one embodiment, once the first API gateway module141initiate a first pull of the message queue data132comprising the update message data104from the message queue module131at INITIATE FIRST PULL OF MESSAGE QUEUE DATA OPERATION307, process flow proceeds to TRANSMIT MESSAGE QUEUE DATA OPERATION309.

In one embodiment, at TRANSMIT MESSAGE QUEUE DATA OPERATION309, the message queue module131transmits, to the first API gateway module141, the message queue data132comprising the first update message data104. In one embodiment, any API gateway module241can act as a first API gateway module141. In one embodiment, a first API gateway module141is one of a plurality of API gateway modules241that was first of the plurality of API gateway modules241to have initiated a first pull of the message queue data comprising the first update message data104. In one embodiment, the message queue module131ensures that only one API gateway module241is a first API gateway module141for the first update message data104. In this embodiment, the message queue module131ensures that only one API gateway module241is a first API gateway module141for second update message data104, which may or may not be the same first API gateway module141for the first update message data104.

In one embodiment, once the message queue module131transmits the message queue data132comprising the first update message data104to the first API gateway module141at TRANSMIT MESSAGE QUEUE DATA OPERATION309, process flow proceeds to REMOVE FIRST UPDATE MESSAGE OPERATION311.

In one embodiment, at REMOVE FIRST UPDATE MESSAGE OPERATION311, the message queue module131removes the first update message data104from the message queue data132. In one embodiment, the message queue module131removes the first update message data104from the message queue data132before a second API gateway module142can initiate a pull of the message queue data132comprising the first update message data104. In one embodiment, the message queue module131prevents another API gateway module241from initiating a pull of the message queue data132comprising the first update message data104. In one embodiment, after receiving an initiation of a first pull of the message queue data132comprising the first update message data104from the first API gateway module141, the message queue module131ignores any future initiations of a pull of the message queue data132comprising the first update message data104received from other API gateway modules241, such as the second API gateway module142.

In one embodiment, at RECEIVE MESSAGE QUEUE DATA OPERATION313, the first API gateway module141receives the message queue data132comprising the first update message data104.

In one embodiment, once the first API gateway module141receives the message queue data132comprising the first update message data104at RECEIVE MESSAGE QUEUE DATA OPERATION313, process flow proceeds to STORE PULLED QUEUE DATA OPERATION315.

In one embodiment, at STORE PULLED QUEUE DATA OPERATION315, the first API gateway module141stores the message queue data132comprising the first update message data104as pulled queue data151comprising the first update message data104. In one embodiment, the pulled queue data151comprising the first update message data104is made available to the first deployment module161of the first API gateway module141.

In one embodiment, once the first API gateway module141stores the pulled queue data151comprising the update message data104at STORE PULLED QUEUE DATA OPERATION315, process flow proceeds to DEPLOY FIRST UPDATE OPERATION317.

In one embodiment, at DEPLOY FIRST UPDATE OPERATION317, the first deployment module161deploys the first update to the first API gateway module141based on the first update message data104. In one embodiment, the first update is an update to the first metadata171. In one embodiment, the first update message data104is a reference to first registry data126of the registry module125. In one embodiment, the first deployment module161updates the first metadata171utilizing the first registry data126. In one embodiment, the first API gateway module141acts as a canary in its deployment of the first update message data104.

In one embodiment, after the first deployment module161updates the first metadata171, the first deployment module161tests the deployment for a successful deployment. In one embodiment, the first deployment module161tests the first update represented in the first metadata171. In one embodiment, the first deployment module161determines that the first update failed and removes the first update related to the first update message data104from the first metadata171. In one embodiment, the first deployment module161determines that the first update succeeded. In one embodiment, upon the deployment module161determining a successful deployment, the first API gateway module141makes the first update message data104available to other API gateway modules142and143through144that are non-canary API gateway modules.

In one embodiment, the first deployment module161of the first API gateway module141is configured to deploy a first update to the first API gateway module141based on the first update message data104and to determine the successful deployment of the first update based on at least one test of at least one API service module122. In one embodiment, the first deployment module161of the first API gateway module141is configured to retrieve registry data126from a registry module125based on the first update message data104and to deploy the first update based on the registry data126, wherein the first update message data104comprises a reference to the registry data126.

In one embodiment, once the first deployment module161deploys the first update to the first API gateway module141at DEPLOY FIRST UPDATE OPERATION317, process flow proceeds to TRANSMIT PULLED QUEUE DATA OPERATION319.

In one embodiment, at TRANSMIT PULLED QUEUE DATA OPERATION319, the first API gateway module141transmits the pulled queue data151comprising the first update message data104to the message topic module135of the message broker module130. In one embodiment, the first gateway module141transmits the pulled queue data151comprising the first update message data104upon a successful deployment of the first update by the first deployment module161. In one embodiment, upon a determination of a failed deployment of the first update by the first deployment module161, the pulled queue data151comprising the first update message data104is not transmitted to the message topic module135of the message broker module130.

In one embodiment, once the first gateway module141transmits the pulled queue data151comprising the first update message data104to the message topic module135at TRANSMIT PULLED QUEUE DATA OPERATION319, process flow proceeds at TO323OFFIG. 3BOPERATION321.

In one embodiment, once process flow proceeds at TO323OFFIG. 3BOPERATION321ofFIG. 3A, process flow proceeds at FROM321OFFIG. 3AOPERATION323ofFIG. 3B.

In one embodiment, once process flow proceeds at FROM321OFFIG. 3AOPERATION323, process flow proceeds to RECEIVE PULLED QUEUE DATA OPERATION325.

In one embodiment, at RECEIVE PULLED QUEUE DATA OPERATION325, the message topic module135receives the pulled queue data151comprising the first update message data104from the first API gateway module141.

In one embodiment, once the message topic module135receives the pulled queue data151comprising the first update message data104from the first API gateway module141at RECEIVE PULLED QUEUE DATA OPERATION325, process flow proceeds to STORE MESSAGE TOPIC DATA OPERATION327.

In one embodiment, at STORE MESSAGE TOPIC DATA OPERATION327, the message topic module135of the message broker module130stores the first update message data104from the first API gateway module141as message topic data136comprising the first update message data104. In one embodiment, the message topic module135provides a distribution mechanism for publishing messages, such as the update message data104, that are delivered to multiple receivers, such as the second API gateway module142, the third API gateway module143, and the nth API gateway module144.

In one embodiment, at INITIATE FIRST SUBSCRIPTION OF MESSAGE TOPIC DATA OPERATION329, the second API gateway module142initiates a first subscription of the message topic data136comprising the first update message data104from the message topic module135. In one embodiment, the second API gateway module142is one of a plurality of API gateway modules241. In one embodiment, the message topic module135conforms to a publish-and-subscribe messaging model. In one embodiment, a publish-and-subscribe messaging model implements the publishing of messages, such as the update message data104, to any number of receivers, including no receivers, one receiver, or a plurality of receivers, such as the API gateway modules241.

In one embodiment, the publish-and-subscribe messaging model implements the capability of any number of senders, such as any number of first API gateway modules141, to be able to send any number of update message data104to the message topic module135, which holds each update message data104available to any number of other API gateway modules241after the update associated with the respective update message data104has been tested by the respective first API gateway module141. In one embodiment, the first update message data104is stored as a durable message within the message topic data136.

In one embodiment, each API gateway module of the plurality of API gateway modules241is configured to initiate a plurality of subscriptions of message topic data136from the message topic module135of the message broker module130, wherein the plurality of subscriptions conforms to a publish-and-subscribe messaging model. In one embodiment, the message topic data136comprising the first update message data104further comprises a representation that the first API gateway module141transmitted pulled queue data151comprising the first update message data104to the message topic module135of the message broker module130.

In one embodiment, once the second API gateway module142initiates a first subscription of the message topic data136comprising the first update message data104from the message topic module135at INITIATE FIRST SUBSCRIPTION OF MESSAGE TOPIC DATA OPERATION329, process flow proceeds to TRANSMIT MESSAGE TOPIC DATA OPERATION331.

In one embodiment, at TRANSMIT MESSAGE TOPIC DATA OPERATION331, the message topic module135transmits, to the second API gateway module142, the message topic data136comprising the first update message data104. In one embodiment, any API gateway module241can act as a second API gateway module142. In one embodiment, a second API gateway module142is one of a plurality of API gateway modules241that initiated a subscription of the message topic data136comprising the first update message data104. In one embodiment, the message topic module135ensures that the first API gateway module141is not a second API gateway module142with respect to the first update message data104. In this embodiment, the second API gateway module142may be a first API gateway module141with respect to second update message data104, for example, that originated from a second engineer system103.

In one embodiment, once the message topic module135transmits the message topic data136comprising the first update message data104to the second API gateway module142at TRANSMIT MESSAGE TOPIC DATA OPERATION331, process flow proceeds to RECEIVE MESSAGE TOPIC DATA333.

In one embodiment, at RECEIVE MESSAGE TOPIC DATA333, the second API gateway module142receives the message topic data136comprising the first update message data104from the message topic module135.

In one embodiment, once the second API gateway module142receives the message topic data136comprising the first update message data104at RECEIVE MESSAGE TOPIC DATA333, process flow proceeds to STORE FIRST SUBSCRIBED TOPIC DATA OPERATION335.

In one embodiment, at STORE FIRST SUBSCRIBED TOPIC DATA OPERATION335, the second API gateway module142stores the message topic data136comprising the first update message data104as first subscribed topic data152comprising the first update message data104. In one embodiment, the first subscribed topic data152is made available to the second deployment module162of the second API gateway module142.

In one embodiment, once the second API gateway module142stores the first subscribed topic data152comprising the first update message data104at STORE FIRST SUBSCRIBED TOPIC DATA OPERATION335, process flow proceeds to DEPLOY SECOND UPDATE OPERATION337.

In one embodiment, at DEPLOY SECOND UPDATE OPERATION337, the second deployment module162deploys a second update to the second API gateway module142based on the first update message data104. In one embodiment, the second update is an update to the second metadata172. In one embodiment, the first update message data104is a reference to the first registry data126of the registry module125. In one embodiment, the second deployment module162updates the second metadata172utilizing the first registry data126. In one embodiment, the second API gateway module142acts as a non-canary in its deployment of the first update message data104.

In one embodiment, once the second API gateway module142deploys the second update to the second API gateway module142at DEPLOY SECOND UPDATE OPERATION337, process flow proceeds to EXIT OPERATION339.

In one embodiment, at EXIT OPERATION339, the process300for self-orchestrated canary release deployment within an API gateway architecture is exited.

In one embodiment, the process300for self-orchestrated canary release deployment within an API gateway architecture includes a third API gateway module143of the plurality of API gateway modules241that initiates a second subscription, from the message topic module135, of the message topic data136comprising the first update message data104. In one embodiment, the message topic module135transmits, to the third API gateway module143, the message topic data136comprising the first update message data104. In one embodiment, the third API gateway module143receives, from the message topic module135, the message topic data136comprising the first update message data104, stores the message topic data136comprising the first update message data104as second subscribed topic data153comprising the first update message data104, and deploys a third update to the third API gateway module143based on the first update message data104.

In one embodiment, the process300for self-orchestrated canary release deployment within an API gateway architecture further includes the engineer system103transmitting second update message data104to the message broker module130. In one embodiment, the message queue module131of the message broker module130receives the second update message data104and stores the second update message data104as message queue data132comprising the second update message data104. In one embodiment, the second API gateway module142of the plurality of API gateway modules241initiates a second pull, from the message queue module131, of the message queue data132comprising the second update message data104. In one embodiment, the message queue module131transmits, to the second API gateway module142, the message queue data132comprising the second update message data104and removes the second update message data104from the message queue data132. In one embodiment, the second API gateway module142stores the message queue data132comprising the second update message data104as pulled queue data251(shown inFIG. 2) comprising the second update message data104, deploys a third update to the second API gateway module142based on the second update message data104, and, upon a successful deployment of the second update, transmits the pulled queue data251comprising the second update message data104to the message topic module135of the message broker module130.

In one embodiment, the message topic module135stores the pulled queue data251comprising the second update message data104as message topic data136comprising the second update message data104. In one embodiment, the first API gateway module141of the plurality of API gateway modules241initiates a second subscription, from the message topic module135, of the message topic data136comprising the second update message data104. In one embodiment, the message topic module135transmits, to the first API gateway module141, the message topic data136comprising the second update message data104. In one embodiment, the first API gateway module141stores the message topic data136comprising the second update message data104as second subscribed topic data252(shown inFIG. 2) comprising the second update message data104, and deploys a fourth update to the first API gateway module141based on the second update message data104.

In one embodiment, the message broker module130receives, from the engineer system103, update message data104. In one embodiment, the message broker module130stores the update message data104as message queue data132comprising the update message data104. In one embodiment, the message broker module130receives, from the first API gateway module141, an initiation of a pull of the message queue data132comprising the update message data104. In one embodiment, such receiving conforms to a point-to-point messaging model. In one embodiment, the first API gateway module141is a canary API gateway module that initiated the pull before any other API gateway module of the plurality of API gateway modules142and143through144. In one embodiment, the message broker module130prevents another API gateway module142and143through144from pulling the message queue data132comprising the update message data104.

In one embodiment, the message broker module130transmits, to the first API gateway module141, the message queue data132comprising the update message data104. In one embodiment, the message broker module130receives, from the first API gateway module141, the pulled queue data151comprising the update message data104. In one embodiment, the message broker module130stores the pulled queue data151comprising the update message data104as message topic data136comprising the update message data104. In one embodiment, the message broker module130prevents the first API gateway module141from subscribing to the message topic data136comprising the update message data104. In one embodiment, such prevention comprises including with the message topic data136a representation that the first API gateway module141transmitted the pulled queue data151comprising the update message data104to the message topic module135of the message broker module130.

In one embodiment, the message broker module130receives, from at least one of the plurality of API gateway modules142and143through144, an initiation of a subscription of the message topic data136comprising the update message data104. In one embodiment, such receiving conforms to a publish-and-subscribe messaging model. In one embodiment, the message broker module130transmits, to the at least one of the plurality of API gateway modules142and143through144, the message topic data136comprising the update message data104.

In one embodiment, the API gateway module241deploys a first update based on the first update message data104. In one embodiment, such deployment represents a role of a canary API gateway module that initiated the pull before any other API gateway module of the API gateway modules142and143through144. In one embodiment, such deployment comprises retrieving registry data126of a registry module125based on the first update message data104and deploying the first update based on the retrieved registry data126, wherein the first update message data104comprises a reference to the registry data126. In one embodiment, upon a successful deployment of the first update, the API gateway module241transmits the pulled queue data251comprising the first update message data104to the message topic module135of the message broker module130. In one embodiment, a successful deployment of the first update is determined based on at least one test of at least one API service module122.

In one embodiment, the API gateway module241initiates a subscription of the message topic data136comprising second update message data104from the message topic module135. In one embodiment, the API gateway module241receives, from the message topic module135, the message topic data136comprising the second update message data104. In one embodiment, the API gateway module241stores the message topic data136comprising the second update message data104as subscribed topic data252comprising the second update message data104. In one embodiment, the API gateway module241deploys a second update based on the second update message data104. In one embodiment, the API gateway module241receives an API service request from an API consumer module108and routes the service request to an API service module122.

Term Definitions

Various embodiments of systems and methods described herein include one or more computers, which may also be referred to herein as systems, computing systems or processors. As used herein the term computer includes any programmable machine or machines capable of performing arithmetic and/or logical operations. In various embodiments, computers include one or more of processors, memories, data storage devices, and/or other components as discussed herein, and/or as known in the art at the time of filing, and/or as developed after the time of filing. In various embodiments, these components are connected physically or through network or wireless links. In various embodiments, computers include software which directs the operations of the aforementioned components. In various embodiments, the software can thereby transform the aforementioned computers and components into special purpose computers and components.

Herein, computers may also be referred to with terms that are commonly used by those of ordinary skill in the relevant arts, such as servers, PCs, mobile devices, routers, switches, data centers, distributed computers, and other terms. In various embodiments, computers facilitate communications between users and/or other computers, provide databases, perform analysis and/or transformation of data, and/or perform other functions. It will be understood by those of ordinary skill that those terms used herein are interchangeable, and any computer capable of performing the described functions may be used.

In various embodiments, computers may be linked to one another via a network or networks. In various embodiments, a network is any plurality of completely or partially interconnected computers wherein some or all of the computers are able to communicate with one another. It will be understood by those of ordinary skill that connections between computers may be wired in some cases (e.g., via Ethernet, coaxial, optical, or other wired connection) or may be wireless (e.g., via Wi-Fi, WiMax, or other wireless connections). In various embodiments, connections between computers may use any protocols, including connection-oriented protocols such as TCP or connectionless protocols such as UDP. Any connection through which at least two computers may exchange data can be the basis of a network.

Herein, the term “production environment” includes the various components, or assets, used to deploy, implement, access, and use, a given application as that application is intended to be used. In various embodiments, production environments include multiple computers and/or assets that are combined, communicatively coupled, virtually and/or physically connected, and/or associated with one another, to provide the production environment implementing the application.

As used herein, the term “computing environment” includes, but is not limited to, a logical or physical grouping of connected or networked computing systems and/or virtual assets using the same infrastructure and systems such as, but not limited to, hardware systems, software systems, and networking/communications systems. The hardware systems may employ processing logic that includes one or more processors, microprocessors, multi-core processors, and/or Field Programmable Gate Arrays (FPGAs) to execute operations disclosed herein. One or more memory (volatile and/or non-volatile) may be communicatively coupled to the processing logic to store instructions to execute operations and/or store data. Typically, computing environments are either known, “trusted” environments or unknown, “untrusted” environments. Typically, trusted computing environments are those where the assets, infrastructure, communication and networking systems, and security systems associated with the computing systems and/or virtual assets making up the trusted computing environment, are either under the control of, or known to, a party.

In various embodiments, each computing environment includes allocated assets and virtual assets associated with, and controlled or used to create, and/or deploy, and/or operate an application.

Herein, a data management system can be, but is not limited to, any system or application implemented on a computing system, accessed through one or more servers, accessed through a network, accessed through a cloud, and/or provided through any system or by any means, as discussed herein, and/or as known in the art at the time of filing, and/or as developed after the time of filing, that gathers data from one or more sources and/or has the capability to analyze and categorize at least part of the data.

Herein, a financial management system can be, but is not limited to, any data management system implemented on a computing system, accessed through one or more servers, accessed through a network, accessed through a cloud, and/or provided through any system or by any means, as discussed herein, and/or as known in the art at the time of filing, and/or as developed after the time of filing, that gathers financial data, including financial transactional data, from one or more sources and/or has the capability to analyze and categorize at least part of the financial data.

As used herein, the term financial management system includes, but is not limited to the following: computing system implemented, and/or online, and/or web-based, personal and/or business financial data management systems, services, packages, programs, modules, or applications; computing system implemented, and/or online, and/or web-based, personal and/or business tax preparation systems, services, packages, programs, modules, or applications; computing system implemented, and/or online, and/or web-based, personal and/or business accounting and/or invoicing systems, services, packages, programs, modules, or applications; and various other personal and/or business electronic data management systems, services, packages, programs, modules, or applications, whether known at the time of filling or as developed later.

As used herein, the terms “artificial intelligence,” “machine learning,” and “machine learning algorithms” include, but are not limited to, machine learning algorithms for predictive model training operations such as one or more of artificial intelligence operations, regression, logistic regression, decision trees, artificial neural networks, support vector machines, linear regression, nearest neighbor methods, distance based methods, naive Bayes, linear discriminant analysis, k-nearest neighbor algorithm, another query classifier, and any other presently known or later developed predictive model training operations, according to one embodiment.

As used herein, the terms “user,” “client,” “customer,” and “engineer” include, but are not limited to, any party, parties, entity, or entities using, or otherwise interacting with any of the methods or systems discussed herein. For instance, in various embodiments, a user can be, but is not limited to, a person, a commercial entity, an application, a service, or a computing system. For further instance, in various embodiments, an engineer can be, but is not limited to, one or more people or teams of people who administer an API service system, including developing APIs for one or more API service modules.

As used herein, the term “engineer system” includes, but is not limited to, the following: a computing system; a computing device; a computing entity; a server; a workstation; a desktop computing system; a mobile computing system, including, but not limited to, one or more of smart phones, portable devices, and devices worn or carried by a user; or any device, subsystem, or mechanism that includes components that can execute all, or part, of any one of the processes or operations, as discussed herein, or as known in the art at the time of filing, or as developed, or becomes available, after the time of filing.

As used herein, the term “message broker module” includes, but is not limited to, an asynchronous messaging service between autonomous environments, systems, applications, modules, and other messaging clients as discussed herein, or as known in the art at the time of filing, or as developed, or becomes available, after the time of filing. In one embodiment, a message broker module provides messaging services between an engineer system and a plurality of API gateway modules. In one embodiment, a message broker module utilizes the Java Message Service (JMS) messaging standard.

Some portions of the above description present the features of the present invention in terms of algorithms and symbolic representations of operations, or algorithm-like representations, of operations on information/data. These algorithmic and/or algorithm-like descriptions and representations are the means used by those of skill in the art to most effectively and efficiently convey the substance of their work to others of skill in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs and/or computing systems. Furthermore, it has also proven convenient at times to refer to these arrangements of operations as steps or modules or by functional names, without loss of generality.

Unless specifically stated otherwise, as would be apparent from the above discussion, it is appreciated that throughout the above description, discussions utilizing terms such as “obtaining,” “training,” “extracting,” “executing,” “mapping,” “analyzing,” “providing,” “enforcing,” “monitoring,” “generating,” “defining,” “determining,” “calculating,” “transforming,” “correlating,” “normalizing,” “accessing,” “analyzing,” “obtaining,” “identifying,” “associating,” “aggregating,” “initiating,” “collecting,” “creating,” “transferring,” “storing,” “searching,” “comparing,” “providing,” “processing” etc., refer to the action and processes of a computing system or similar electronic device that manipulates and operates on data represented as physical (electronic) quantities within the computing system memories, resisters, caches or other information storage, transmission or display devices.

Certain aspects of the present invention include process steps or operations and instructions described herein an algorithmic and/or algorithmic-like form. It should be noted that the process steps and/or operations and instructions of the present invention can be embodied in software, firmware, and/or hardware, and when embodied in software, can be downloaded to reside on and be operated from different platforms used by real time network operating systems.

The present invention also relates to an apparatus or system for performing the operations described herein. This apparatus or system may be specifically constructed for the required purposes by a computer program stored via a computer program product as defined herein that can be accessed by a computing system or other device to transform the computing system or other device into a specifically and specially programmed computing system or another device.

Those of skill in the art will readily recognize that the algorithms and operations presented herein are not inherently related to any particular computing system, computer architecture, computer or industry standard, or any other specific apparatus. It may prove convenient/efficient to construct or transform one or more specialized apparatuses to perform the required operations described herein. The required structure for a variety of these systems will be apparent to those of skill in the art, along with equivalent variations. In addition, the present invention is not described with reference to any particular programming language and it is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references to a specific language or languages are provided for illustrative purposes only and for enablement of the contemplated best mode of the invention at the time of filing.

In addition, the operations shown in the figures are identified using a particular nomenclature for ease of description and understanding, but other nomenclature is often used in the art to identify equivalent operations.