Systems and methods for failure detection with orchestration layer

A system and method in accordance with examples may include systems and methods for detecting failure of microservice applications in communication with an orchestration layer of a microservice-architecture. The system may include memory and an orchestration layer including one or more processors coupled to the memory. The one or more processors may be configured to connect the orchestration layer to a plurality of microservice applications that are each associated with a respective dataset. The one or more processors may be configured to validate, responsive to the connection of each of the microservice applications, the microservice applications by performing a first test and a second test. The one or more processors may be configured to deploy, responsive to the validation of the microservice applications, the microservice applications to execute a plurality of workflow actions.

FIELD OF THE DISCLOSURE

The present disclosure relates to systems and methods to detect the failure of microservice applications in communication with an orchestration layer.

BACKGROUND OF THE DISCLOSURE

Microservices are used for a variety of devices (e.g. mobile and desktop devices) and are frequently used in many fields associated with a variety of users (e.g. customers, partners, employees, etc.).

Current solutions for failure detection of microservice applications expend a great amount of processing resources and time only to find out that, after deployment of the applications, a system is not working for a particular functionality associated with a microservice application because its underlying services are unavailable to operate.

These and other drawbacks exist.

SUMMARY OF THE DISCLOSURE

Various embodiments of the present disclosure provide systems and methods to detect the failure of microservice applications in communication with an orchestration layer of a microservice-architecture. In one example, a system may include memory and an orchestration layer including one or more processors coupled to the memory. The one or more processors may be configured to connect the orchestration layer to a plurality of microservice applications that are each associated with a respective dataset. The one or more processors may be configured to validate, responsive to the connection of each of the plurality of microservice applications, the plurality of microservice applications by performing a first test and a second test. The one or more processors may be configured to deploy, responsive to the validation of the plurality of microservice applications, the plurality of microservice applications to execute a plurality of workflow actions.

In an example, a method may include establishing, by one or more processors coupled to memory, an orchestration layer. The method may include receiving, at the orchestration layer, a respective dataset from each of a plurality of microservice applications. The method may include validating, by the one or more processors and based on receiving the respective dataset, the plurality of microservice applications by executing a first test prior to executing a second test. The method may include deploying, by the one or more processors and based on validating the plurality of microservice applications, the plurality of microservice applications to execute a plurality of workflow actions.

In an example, a computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to create an orchestration engine. Further, the computer-readable medium storing instructions that, when executed by the one or more processors, cause the one or more processors to establish connectivity between the orchestration layer and a plurality of microservice applications that are each associated with a corresponding dataset that is at least partially overlapping with other datasets. Also, the computer-readable medium storing instructions that, when executed by the one or more processors, cause the one or more processors to certify, based on the establishment of connectivity with the plurality of microservice applications, the plurality of microservice applications by conducting a plurality of tests. Moreover, the computer-readable medium storing instructions that, when executed by the one or more processors, cause the one or more processors to deploy, based on the certification of plurality of microservice applications, the plurality of microservice applications to execute a plurality of workflow actions.

DETAILED DESCRIPTION

The following description is intended to convey a thorough understanding of the embodiments described by providing a number of specific exemplary embodiments and details involving systems and methods to detect the failure of microservice applications in communication with an orchestration layer or engine. It should be appreciated, however, that the present disclosure is not limited to these specific embodiments and details, which are exemplary only. It is further understood that one possessing ordinary skill in the art, in light of known systems and methods, would appreciate the use of the invention for its intended purposes and benefits in various embodiments, depending on specific design and other needs.

According to the various examples of the present disclosure, systems and methods use the technical capabilities to detect failure of microservice applications in communication with an orchestration layer of a microservice-architecture. In some examples, the system may be configured to remain operational through a mock service application despite the failure detection of at least one microservice application, as discussed below. Deploying microservice applications is a processing extensive process and is not worthwhile if, after deployment of the applications, the expected behavior of the applications is not working which necessitates unnecessary and timely debugging processes. Unlike conventional systems in which a check is conducted after deployment of applications, the systems and methods disclosed herein conduct checks as a post-implementation step, or a pre-deployment step; that is, performing validation of the microservice applications after they have begun implementation for connectivity, or performing validation of the microservice applications prior to their deployment. In this manner, processing time is avoided in conducting debugging processes (which may range, for example, from about thirty minutes to over four hours) after deployment of the applications to determine whether it is, for example, in working condition and/or available to serve. As further explained herein, this specific process may be referred to as a fail fast pattern which may be utilized when development and deployment of applications is fast-paced and frequent deployments are required in a given time frame, such as in a single day. Through the mock service application, the system may be configured to simulate other systems which may have not been developed or otherwise not be available.

FIG. 1illustrates a system100detect the failure of microservice applications in communication with an orchestration layer according to an example of the present disclosure. As further discussed below, system100may include client device110, orchestration layer120, application programming interface (API) gateway130, microservice applications140,150,160,170, and spring integration framework180. AlthoughFIG. 1illustrates four microservice applications140,150,160,170, system100may include any number of microservice applications.

Client device110, (also referred to as end node110), may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to: e.g., a computer device, or communications device including, e.g., a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an Internet browser, or other device. Client device110also may be a mobile device. For example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS operating system, any device running Google's Android® operating system, including for example, Google's wearable device, Google Glass, any device running Microsoft's Windows® Mobile operating system, and/or any other smartphone or like wearable mobile device.

In various examples according to the present disclosure, client device110may be understood in the context of an auto loan and vehicle purchase platform. The one or more network-enabled computers of system100may execute one or more software applications that uses one or more microservice applications140,150,160,170and may also enable, for example, network communications with one or more components of system100and transmit and/or receive data. For example, data that is configured to be transmitted and/or received may include one or more of vehicle identification number, mileage information, vehicle information, identity of the dealer, dealer reviews and/or dealer ratings, serviceability of the dealer, loan terms, credit check applications, pre-approval forms, loan financing, and/or any combination thereof. As discussed below, microservice applications140,150,160,170may each be a part of one or more cloud containers (not shown), may be coupled to one or more servers and/or databases (not shown) associated with an auto loan and vehicle purchase system, or may be hosted on cloud145.

For example, client device110may be in communication with API gateway130via one or more networks (not shown), and may operate as a respective front-end to back-end pair with orchestration layer120. Client device110may transmit, for example from a mobile device application executing on client device110, one or more requests to API gateway130. The one or more requests may be associated with retrieving one or more data sets from microservice applications140,150,160,170. Orchestration layer120may receive the request from client device110. Based on the one or more requests from client device110, orchestration layer120may be configured to retrieve the requested one or more data sets from one or more of microservice applications140,150,160,170. Based on receipt of the requested one or more data sets from one or more microservice applications, orchestration layer120may be configured to orchestrate a response and thereafter may be configured to transmit the orchestrated response to client device110.

Orchestration layer120may include one or more processors, which are coupled to memory. Orchestration layer120may be configured as a central system, server or platform to control and call various microservice applications140,150,160,170at different times to execute a plurality of workflow actions. Orchestration layer120may comprise a light-weight orchestration layer. Orchestration layer120may be configured to connect to microservice applications140,150,160,170, as discussed below. Orchestration layer120may be connected to at least one client device110.

“Microservices” as used herein may include independent processes or applications that each provide a distinct capability, for example, a business functionality. Microservices may be hosted in one or more cloud and or cloud-based systems. Microservices may be a part of one or more cloud containers (not shown) that may be configured to operate the applications. In various examples according to the present disclosure, microservice applications140,150,160,170may be understood in the context of an auto loan and vehicle purchase platform. For example, numerous types of data and formats may be provided from a plurality of servers and/or databases of third parties, such as servers and/or databases from vehicle dealers, to microservice applications140,150,160,170. The data may be categorized by microservice applications140,150,160,170into a plurality of data sets, such as a first data set comprising a vehicle identification number, mileage, and other vehicle information, and/or another data set comprising an identity of the dealer, dealer reviews and/or dealer ratings, serviceability of the dealer, and/or any combination of the sets thereof. The data sets may be at least partially overlapping with other data sets. The data sets may be loaded in a batch format for data retrieval from the third parties at a predetermined rate, for example, every three to four hours. Once the respective data sets are received, its contents may be combined or otherwise consolidated by microservice applications140,150,160,170.

As discussed above, microservice applications140,150,160,170may be each associated with a respective dataset. Orchestration layer120may be configured to call each of microservice applications140,150,160,170through a protocol, such as a spanning tree protocol (STP). For example, although the fail fast pattern described herein may be configured to use hypertext transfer protocol (HTTP) and HTTP secure (HTTPS), the pattern may be used with any protocol of stateless communication. For example, orchestration layer120may be configured to validate, responsive to the connection of each of microservice applications140,150,160,170, microservice applications140,150,160,170by performing a first test and a second test. The first and/or second tests may be performed for only some, such as a designated set of microservice applications140,150,160,170or all of microservice applications140,150,160,170.

The first and/or second tests also may be performed in a sequential or a non-sequential manner. For example, from a sequential perspective, a first test may be performed for a first microservice application140and a second test may be performed for the first microservice application140. Thereafter, the first test may be performed for a second microservice application150and the second test may be performed for the second microservice application150. This manner or pattern may repeat sequentially up to and including the nth microservice application. In contrast, from a non-sequential perspective, a first test may be performed for a first microservice application140and a second test may be performed for the first microservice application140. Thereafter, the first test may be performed for a third microservice application160and the second test may be performed for the third microservice application160before proceeding to the second microservice application150or proceeding to a fourth microservice application170. This manner or pattern may then repeat non-sequentially up to and including the nth microservice application. In other words, it is not necessary that the tests for the first through the nth microservice applications are performed in that order. Rather, as discussed above, a designated set of microservice applications140,150,160,170may be decided, for example, by orchestration layer120to determine which microservice applications140,150,160,170are subject to performance of the first and second tests.

The first test may include an availability check. The availability check may be configured to determine whether all microservice applications140,150,160,170are at least available and/or connected to orchestration layer120through application programming interface (API) gateway130. For example, the first test may include whether a signal is received or not within a predetermined threshold time, such as two seconds, the signal being indicative of responsiveness associated with connectivity of microservice applications140,150,160,170and orchestration layer120via API gateway130. For example, a single API gateway130may be configured to connect microservice applications140,150,160,170to orchestration layer120. In some examples, there may be more than one gateway configured to connect microservice applications140,150,160,170to orchestration layer120. The first test may be associated with determining availability, including receiving status updates based on whether microservice applications140,150,160,170is/are operational and/or running and/or active. The first test may also be associated with connectivity, including receiving status updates based on whether microservice applications140,150,160,170is communicating (and with who) and/or connected (and to who).

The second test may include a health check. The health check may be configured to determine whether all microservice applications140,150,160,170are configured to serve traffic associated with the respective dataset. In some examples, the health check may depend on microservice application140,150,160,170logic to specify that it is health by providing one or more parameters, such as one or more business-related parameters. For example, a parameter may comprise a status and/or response from microservice application140,150,160,170indicating the latest loaded data for the particular microservice application140,150,160,170, which differs from the industry standard in which a mere “OK” response is provided by microservice application140,150,160,170. In some examples, there may be no dependency between the first test and the second test. For example, only the second test may be performed in substitute of the first test, and further, for microservice applications140,150,160,170. In some examples, “traffic” may refer to microservice application140,150,160,170as being ready and/or available to accept one or more requests through specific protocols from one or more client devices that are configured to utilize or expose functionality of microservice applications140,150,160,170. Orchestration layer120may be configured to deploy, responsive to the validation of microservice applications140,150,160,170, microservice applications140,150,160,170to execute a plurality of workflow actions. For example, a workflow action may define functionalities, such as different business functionalities, that orchestration layer120is performing by one or more microservice applications140,150,160,170.

Also, system100may include spring integration framework180, such as a Java or language-neutral spring integration framework, which may include a plurality of beans190, such as bean1, bean2, bean n, etc. Spring integration framework180may be implemented in other languages, such as Python, and is not limited to Java. Beans190may be each representative of a unit of work. Spring integration framework180may be configured to implement data flow, for example via JavaScript Object Notation (JSON), between microservice applications140,150,160,170and orchestration layer120by at least one of beans190of spring integration framework180. Spring integration framework180may be configured to implement data flow, for example via JavaScript Object Notation (JSON), orchestration layer120and client device110by at least one of beans190of spring integration framework180.

In various examples, system100may include an application, such as a mock service application195, which may reside in orchestration layer120. When executed, mock service application195may be configured to override behavior of data flow such that microservice applications140,150,160,170are deployed even after determining that at least one of microservice applications140,150,160,170failed the second test. Based on results of the mock service application195indicative of the at least one of microservice applications140,150,160,170failing the second test, a corresponding message may be logged in one or more databases (not shown), rather than producing an error notification. The corresponding message may comprise a notification that this service is a simulated service, i.e., a mock service. Based on the logged corresponding message, a user of client device110may decide to mock microservice applications140,150,160,170which are not intended for use. Thus, mock service application195may provide for deployment with information about microservice applications140,150,160,170. For example, as further discussed below,FIG. 3(mock failure) andFIG. 4(mock success) illustrate instances of when orchestration layer120may be deployed with respect to mock service application.

FIG. 2illustrates an example method200to detect the failure of microservice applications. As explained below, method200may reference same or similar components of system100.

At block210, an orchestration layer, (e.g., an orchestration layer120as shown and described inFIG. 1), may be configured to connect to a plurality of microservice applications, (e.g., microservice applications similar to microservice applications140,150,160,170as shown and described inFIG. 1) each associated with a respective dataset. The connection between the orchestration layer and the microservice applications may be based on one or more requests from a client device, (e.g. a client device similar to client device110as shown and described inFIG. 1). For example, the client device may be in communication with an API gateway (e.g. an API gateway similar to API gateway130as shown and described inFIG. 1) via one or more networks, and may operate as a respective front-end to back-end pair with the orchestration layer. The client device may transmit, for example from a mobile device application executing on the client device, one or more requests to the API gateway. The one or more requests may be associated with retrieving one or more data sets from the microservice applications. The orchestration layer may receive the request from the client device. Based on receipt of the one or more requests from the client device, the orchestration layer may be configured to retrieve the requested one or more data sets from one or more of the microservice applications. Based on receipt of the requested one or more data sets from the one or more microservice applications, the orchestration layer may be configured to orchestrate a response and thereafter may be configured to transmit the orchestrated response to the client device.

In various examples according to the present disclosure, the client device may be understood in the context of an auto loan and vehicle purchase platform. The one or more network-enabled computers may execute one or more software applications that uses the one or more microservice applications and may also enable, for example, network communications with one or more components of the system to transmit and/or receive data. For example, data that is configured to be transmitted and/or received may include one or more of vehicle identification number, mileage information, vehicle information, identity of the dealer, dealer reviews and/or dealer ratings, serviceability of the dealer, loan terms, credit check applications, pre-approval forms, loan financing, and/or any combination thereof. As discussed below, the microservice applications may each be a part of one or more cloud containers, may be coupled to one or more servers and/or databases associated with an auto loan and vehicle purchase system, or may be hosted on a cloud.

The orchestration layer may include one or more processors, which are coupled to memory. The orchestration layer may be configured as a central system, server or platform to control and call various microservice applications at different times to execute a plurality of workflow actions. The orchestration layer may comprise a light-weight orchestration layer. The orchestration layer may be configured to connect to the microservice applications, as discussed below. The orchestration layer may be connected to at least one client device.

Microservices may be hosted in one or more cloud and or cloud-based systems. Microservices may be a part of one or more cloud containers (not shown) that may be configured to operate the applications. In various examples according to the present disclosure, microservice applications may be understood in the context of an auto loan and vehicle purchase platform. For example, numerous types of data and formats may be provided from a plurality of servers and/or databases of third parties, such as servers and/or databases from vehicle dealers, to microservice applications. The data may be categorized by the microservice applications into a plurality of data sets, such as a first data set comprising a vehicle identification number, mileage, and other vehicle information, and/or another data set comprising an identity of the dealer, dealer reviews and/or dealer ratings, serviceability of the dealer, and/or any combination of the sets thereof. The data sets may be at least partially overlapping with other data sets. The data sets may be loaded in a batch format for data retrieval from the third parties at a predetermined rate, for example, every three to four hours. Once the respective data sets are received, its contents may be combined or otherwise consolidated by the microservice applications. As discussed above, the microservice applications may be each associated with a respective dataset. The orchestration layer may be configured to call each of the microservice applications through a protocol, such as a spanning tree protocol (STP). For example, although the fail fast pattern described herein may be configured to use HTTP and HTTPS, the pattern may be used with any protocol of stateless communication.

At block220, the orchestration layer may be configured to validate, responsive to the connection of each of the plurality of microservice applications of block210, the plurality of microservice applications by performing a first test and a second test. The first and second tests may be performed for only some, such as a designated set of microservice applications or all of microservice applications.

The first and second tests also may be performed in a sequential or a non-sequential manner. For example, from a sequential perspective, a first test may be performed for a first microservice application and a second test may be performed for the first microservice application. Thereafter, the first test may be performed for a second microservice application and the second test may be performed for the second microservice application. This manner or pattern may repeat sequentially up to and including the nth microservice application. In contrast, from a non-sequential perspective, a first test may be performed for a first microservice application and a second test may be performed for the first microservice application. Thereafter, the first test may be performed for a third microservice application and the second test may be performed for the third microservice application before proceeding to the second microservice application or proceeding to a fourth microservice application. This manner or pattern may then repeat non-sequentially up to and including the nth microservice application. In other words, it is not necessary that the tests for the first through the nth microservice applications are performed in that order. Rather, as discussed above, a designated set of microservice applications may be decided, for example, by the orchestration layer to determine which microservice applications are subject to performance of the first and second tests.

The first test may include an availability check. The availability check may be configured to determine whether all microservice applications are at least available and/or connected to the orchestration layer through an application programming interface (API) gateway. For example, a single API gateway may be configured to connect the microservice applications to the orchestration layer. In some examples, there may be more than one gateway configured to connect one or more microservice applications to the orchestration layer. The first test may be associated with determining availability, including receiving status updates based on whether the microservice applications is/are operational and/or running and/or active. The first test may also be associated with connectivity, including receiving status updates based on whether the microservice applications is/are communicating (and with who) and/or connected (and to who). For example, the first test may include whether a signal is received or not within a predetermined threshold time, such as two seconds, the signal being indicative of responsiveness associated with connectivity of the microservice applications and orchestration layer via the API gateway.

The second test may include a health check. The health check may be configured to determine whether all the microservice applications are configured to serve traffic associated with the respective dataset. In some examples, a health check may depend on microservice application logic to specify that it is health by providing one or more parameters, such as one or more business-related parameters. For example, a parameters may comprise a status and/or response from one or more of the microservice applications indicating the latest loaded data for the particular microservice application, which differs from the industry standard in which a mere “OK” response is provided by the microservice application. In some examples, there may be no dependency between the first test and the second test. For example, only the second test may be performed in substitute of the first test for one or more microservice applications. In some examples, “traffic” may refer to one or more microservice applications as being ready and/or available to accept one or more requests through specific protocols from one or more client devices that are configured to utilize or expose functionality of the microservice applications.

Also, system may include spring integration framework (similar to spring integration framework180as described above with respect toFIG. 1), such as a Java or language-neutral spring integration framework, which may include a plurality of beans, such as bean1, bean2, bean n, etc. (similar to beans190as described above with respect toFIG. 1). The spring integration framework may be implemented in other languages, such as Python, and is not limited to Java. The beans may be each representative of a unit of work. The spring integration framework may be configured to implement data flow, for example via JavaScript Object Notation (JSON), between the microservice applications and the orchestration layer by at least one of beans of the spring integration framework. The spring integration framework may be configured to implement data flow, for example via JavaScript Object Notation (JSON), between the orchestration layer and the client device by at least one of beans of the spring integration framework.

In various examples, system may include an application, such as a mock service application (similar to mock service application195as described above with respect toFIG. 1), which may reside in the orchestration layer. When executed, the mock service application may be configured to override behavior of data flow such that the microservice applications are deployed even after determining that at least one of the microservice applications failed the second test. Based on results of the mock service application indicative of the at least one of microservice applications failing the second test, a corresponding message may be logged in one or more databases (not shown), rather than producing an error notification. The corresponding message may comprise a notification that this service is mocked. Based on the logged corresponding message, a user of the client device may decide to mock the microservice applications which are not intended for use. Thus, the mock service application may provide for deployment with information about the microservice applications.

At block230, the orchestration layer may be configured to deploy, responsive to the validation of the plurality of microservice applications of block220, the plurality of microservice applications to execute a plurality of workflow actions.

FIG. 3illustrates a system300process the failure of microservice applications in connection with a failure stage of a mock service application according to an example of the present disclosure. System300may include the same or similar components as illustrated in system100. For example, system300may include client device310(similar to client device110as described above with respect toFIG. 1), orchestration layer320(similar to orchestration layer120as described above with respect toFIG. 1), application programming interface (API) gateway330(similar to API gateway130as described above with respect toFIG. 1), microservice applications340,350,360,370(similar to microservice applications140,150,160,170described above with respect toFIG. 1), cloud345(similar to cloud145as described above with respect toFIG. 1), and spring integration framework (not shown, similar to spring integration framework180as described above with respect toFIG. 1). AlthoughFIG. 3illustrates four microservice applications340,350,360,370, system300may include any number of microservice applications.

InFIG. 3, orchestration layer320may not be deployed (or may fail to deploy) because, for example, at least one or more of microservice applications340,350,360,370is not available (or failed) at the time of orchestration layer320startup. InFIG. 3, orchestration layer320may not be marked for mocking, and thus may be indicated by @FailFast annotation. For example, at least one or more of microservice applications340,350,360,370may not be available (or failed) to serve traffic because of not passing the availability check and/or the health check. Orchestration layer320may be configured to receive one or more responses from different microservice applications340,350,360,370. Orchestration layer320may receive data from at least two of microservice applications340,350,360,370, such as microservice applications340and350prior to orchestration layer320orchestrating and providing the corresponding orchestrated response to client device310. In one example, the corresponding orchestrated response transmitted from orchestration layer320to client device310may include orchestration layer320combining a response received from each of microservice applications, such as from340and350.

With respect to communications and data transfers between orchestration layer320and microservice applications340,350,360,370, the solid line may represent that a connection is always available between orchestration layer320and microservice application, such as microservice applications350and370. With respect to communications and data transfers between orchestration layer320and microservice applications340,350,360,370, the dashed line may represent that a request for connection thereto has been performed and a response to the request is pending, such as between orchestration layer320and microservice application and microservice applications340and360. Microservice applications340,350,360,370may be stateful, stateless, and/or any combination thereof. For example, stateful microservice applications340,350,360,370may be configured to retrieve data, for example responsive to one or more requests of data from orchestration layer320, from one or more databases (not shown). In contrast, stateless microservices340,350,360,370may be configured to receive and/or transmit one or more requests of data without saving or retrieving the data from the one or more databases (not shown), as microservices340,350,360,370may be connected thereto, transmit data responsive to one or more requests from orchestration layer320, and terminating the connection.

FIG. 4illustrates a system400process the failure of microservice applications in connection with a success stage of a mock service application according to an example of the present disclosure. System400may include the same or similar components as illustrated in system100. For example, system400may include client device410(similar to client device110as described above with respect toFIG. 1), orchestration layer420(similar to orchestration layer120as described above with respect toFIG. 1), application programming interface (API) gateway430(similar to API gateway130as described above with respect toFIG. 1), microservice applications440,450,460,470, (similar to microservice applications140,150,160,170described above with respect toFIG. 1), cloud445(similar to cloud145as described above with respect toFIG. 1), and spring integration framework (not shown, similar to spring integration framework180as described above with respect toFIG. 1). AlthoughFIG. 4illustrates four microservice applications440,450,460,470, system400may include any number of microservice applications.

InFIG. 4, orchestration layer420may be deployed (or successful deployment) because, for example, although at least one or more of microservice applications440,450,460,470is not available (or failed) at the time of orchestration layer420startup, orchestration layer420may be marked for mocking, and thus may be indicated by @FailFast(Mock=True) annotation. Thus, feature(s) associated with the data set of failed serving microservice application440,450,460,470will mock the response of the corresponding services and fulfill the feature. For example, at least one or more of microservice applications440,450,460,470may not be available (or failed) to serve traffic because of not passing the availability check and/or the health check. However, despite this unavailability (or failure), mock service application (similar to mock service application195as described above with respect toFIG. 1) may be configured to execute such that the feature(s) associated with the data set of unavailable (or failed) microservice application440,450,460,470will be retrieved and responsive to one or more requests from orchestration layer420. In this manner, orchestration layer420may be deployed after the mock service application has been executed in which a response from at least one or more of the microservice applications440,450,460,470is mocked.

Orchestration layer420may be configured to receive one or more responses from different microservice applications440,450,460,470. Orchestration layer420may receive data from at least two of microservice applications440,450,460,470, such as microservice applications440and450prior to orchestration layer420orchestrating and providing the corresponding orchestrated response to client device410. In one example, the corresponding orchestrated response transmitted from orchestration layer420to client device410may include orchestration layer420combining a response received from each of microservice applications, such as from440and450.

With respect to communications and data transfers between orchestration layer420and microservice applications440,450,460,470, the solid line may represent that a connection is always available between orchestration layer420and microservice application, such as microservice applications450and470. With respect to communications and data transfers between orchestration layer420and microservice applications440,450,460,470, the dashed line may represent that a request for connection thereto has been performed and a response to the request is pending, such as between orchestration layer420and microservice application and microservice applications440and460. Microservice applications440,450,460,470may be stateful, stateless, and/or any combination thereof. For example, stateful microservice applications440,450,460,470may be configured to retrieve data, for example responsive to one or more requests of data from orchestration layer420, from one or more databases (not shown). In contrast stateless microservices440,450,460,470may be configured to receive and/or transmit one or more requests of data without saving or retrieving the data from the one or more databases (not shown), as microservices440,450,460,470may be connected thereto, transmit data responsive to one or more requests from orchestration layer420, and terminating the connection.

It is further noted that the systems and methods described herein may be tangibly embodied in one of more physical media, such as, but not limited to, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a hard drive, read only memory (ROM), random access memory (RAM), as well as other physical media capable of data storage. For example, data storage may include random access memory (RAM) and read only memory (ROM), which may be configured to access and store data and information and computer program instructions. Data storage may also include storage media or other suitable type of memory (e.g., such as, for example, RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, flash drives, any type of tangible and non-transitory storage medium), where the files that comprise an operating system, application programs including, for example, web browser application, email application and/or other applications, and data files may be stored. The data storage of the network-enabled computer systems may include electronic information, files, and documents stored in various ways, including, for example, a flat file, indexed file, hierarchical database, relational database, such as a database created and maintained with software from, for example, Oracle® Corporation, Microsoft® Excel file, Microsoft® Access file, a solid state storage device, which may include a flash array, a hybrid array, or a server-side product, enterprise storage, which may include online or cloud storage, or any other storage mechanism. Moreover, the figures illustrate various components (e.g., servers, computers, processors, etc.) separately. The functions described as being performed at various components may be performed at other components, and the various components may be combined or separated. Other modifications also may be made.

In the preceding specification, various embodiments have been described with references to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded as an illustrative rather than restrictive sense.