Systems, methods, and media for operating a microservices architecture with a shared distributed cache

Techniques are provided for managing and operating a microservices architecture with ad distributed cache. A data provider microservice may modify a data object stored on a database managed by the data provider microservice. In response, the modified data object may be transmitted to the distributed cache for storage. A data consumer microservice may request a data object. The distributed cache may be searched for the requested object. If the requested object is stored at the distributed cache, the requested object may be provided to the data consumer microservice. If the requested object is not stored at the distributed cache, the data consumer microservice may issue a request for the data object to the data provider microservice that manages the database that stores the data object. The data provider microservice may provide the data object to the distributed cache for storage and provide the data object to the data consumer microservice.

TECHNICAL FIELD

The present disclosure relates generally to microservices, and more specifically to techniques for operating a microservices architecture with a shared distributed cache.

BACKGROUND INFORMATION

In recent years, the ubiquity of mobile computing has required application developers to deploy actions quickly and make changes to applications without complete redeployment. This has led to a new development paradigm called “microservices”, i.e., a microservices architecture. Microservices are an architectural and organizational approach to software development Where a single software application is, for example, composed of independent services (e.g., microservices). Microservices are lightweight, self-contained components that perform respective functions for the application. Even though microservices are independent from each other, they can communicate with each other over well-defined Application Program Interfaces (APIs) to achieve desired application results.

Because microservices operate independently, each microservice may have its own dedicated resources. For example, each microservice may have its own central processing unit (CPU), runtime environment, database, etc. Though each microservice having its own database promotes microservice independence, it also can introduce significant latency when microservices share data from their databases. For example, microservices may share data using Representational State Transfer (REST) APIs. When an application has low-latency requirements, microservice data sharing using microservices APIs can become a major bottleneck for east-west traffic (e.g., traffic within a data center in which the application comprising the microservices is located).

Therefore, what is needed is a microservices architecture that reduces or mitigates east-west traffic bottlenecks that may be impacted by microservices data sharing.

SUMMARY

Techniques are provided for operating a microservices architecture with a distributed cache according to the one or more embodiments as described herein. Specifically, data from data provider microservices may be stored on a distributed cache in response to the data being modified by the data provider microservices. Subsequently, is data consumer microservices may obtain requested data objects from the distributed cache such that east-west traffic is reduced or mitigated.

In an embodiment, each of one or more data provider microservices may manage a corresponding database. Each data provider microservice may only access and modify data that is stored at the database that is managed by the data provider microservice. In an embodiment, modifying data on a managed database includes one or more of (1) generating new data to be maintained on the managed database, (2) changing data that is stored on the managed database, and (3) deleting data from the managed database.

In response to modifying data by a data provider microservice, the modified data may be provided and stored at a distributed cache in the microservices architecture. The distributed cache may store the modified data objects with an identifier that uniquely identifies the modified data object at the distributed cache. For example, the identifier may include a data type identifier that is unique to a data provider microservice of all the data provider microservices in the microservices architecture. The identifier may also include a data object identifier. In an embodiment, the data type identifier and the data object identifier may, together, uniquely identify the data object on the distributed cache.

In an embodiment, a client device operated by a user (e.g., a customer or employee of an enterprise) may issue a request for a data object. The request may be transmitted from the client device to a data consumer microservice that does not manage a database. The data consumer microservice may issue a command for the requested data object to the distributed cache. The distributed cache may be searched for the requested object.

If the requested object is stored at the distributed cache, the requested object may be provided to the requesting client device. If the requested object is not stored at the distributed cache, the data consumer microservice may send a request, e.g., REST API command, to the data provider microservice that manages the database that stores the requested data object. In response to receiving the request, the data provider microservice may obtain the requested data object and (1) provide the requested object to the distributed cache for storage and (2) provide the requested object to the client device via the requesting data consumer microservice.

Because data consumer microservices can obtain a data object from the distributed cache instead of issuing a data sharing request to a data provider microservice, east-west traffic is reduced/mitigated when compared to conventional microservices architectures. Stated another way, conventional microservices architectures require the use of data sharing API requests among microservices to share objects. This contributes to the amount of east-west traffic in a data center that may include other east-west traffic. Because the one or more embodiments described herein can obtain requested data objects from the distributed cache instead of using data sharing APIs, the one or more embodiments as described herein reduce east-west traffic when compared to conventional systems.

Because east-west traffic is reduced, the one or more embodiments as described herein provide an improvement to microservices systems, i.e., a computer itself, when compared to conventional systems. Additionally, and by reducing east-west traffic, the one or more embodiments as described herein provide an improvement in the existing is technological field of microservices computing.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE

Embodiment

FIG.1Ais a high-level block diagram of an example system environment100for operating a microservices architecture with a shared distributed cache according to one or more embodiments as described herein. The system environment100may be divided into a client side102that includes one or more local client devices110that are local to end users, and an enterprise side104that includes microservices architecture126that is remote to the end users. Enterprise side104may be managed, operated, and maintained by an enterprise. In an embodiment, the enterprise side104may be referred to as a data center and the enterprise may be a financial services institution.

The client side102may include one or more local client devices110that provide a variety of user interfaces and non-processing intensive functions. For example, a local client device110may provide a user interface, e.g., a graphical user interface and/or a command line interface, for receiving user input and displaying output according to the one or more embodiments as described herein. In an embodiment, the client device110may be a server, a workstation, a platform, a mobile device, a network host, or any other type of computing device. The client device110may be operated by, for example, customers of the enterprise. For example, client device110may download and execute application125that is provided by the enterprise. The execution of application125may allow customers of the enterprise to implement one or more financial services functions. Client device110may also be operated by authorized personnel, e.g., employees of the enterprise.

The client device110may communicate with the microservices architecture126, managed/operated by the enterprise, over network111. For example, a user may utilize application125, executing on client device110, to request a data object from enterprise side104as will be described in further detail below.

FIG.1Bis a detailed block diagram of an example microservices architecture with a shared distributed cache according to one or more embodiments as described herein. Microservices architecture126of enterprise side104may implement the one or more embodiments as described herein. As will be described in further detail below, the is configuration and operation of microservices architecture126with distributed cache130may reduce and/or mitigate east-west traffic bottlenecks on the enterprise side104, e.g., within the data center.

As depicted inFIG.1B, microservices architecture126includes data consumer microservices127A-127D, data provider microservices128A-128D, databases129A-129D, and distributed cache130. For simplicity and ease of understanding, a data consumer microservice or data consumer microservices may be referenced using reference number127. Similarly, a data provider microservice or data provider microservices may be referenced using reference number128. Further, a database or databases may be referenced using reference number129.

For illustrative purposes, microservices architecture126ofFIG.1Bincludes four data consumer microservices and four data provider microservices with corresponding databases. However, it is expressly contemplated that microservices architecture126may include any number of data consumer microservices and data provider microservices with corresponding databases.

In an embodiment, each of data consumer microservices127and data provider microservices128may implement a different function for a single application. For example, each of data consumer microservices127and data provider microservices128may implement a different function for application125on client side102. Alternatively, each of data consumer microservices127and data provider microservices128may implement a different function for an enterprise application (not shown) hosted on the enterprise side104, wherein the client application125interacts with the enterprise is application (not shown).

In an embodiment, each of data consumer microservices127may implement a different data consumer function for a financial services application and each of data provider microservices128may implement a different data provider function for the financial services application. For example, the different data consumer functions may include, but are not limited to, a UI function, an orders function, a records function, a trades functions, etc. The different data provider functions may include, but are not limited to, a price function, a securities reference function, a customer function, a balances function, etc. In an embodiment, the data consumer microservices and data provider microservices may communicate with each other to implement one or more financial services functions.

As depicted inFIG.1B, each of data provider microservices128A-128D may manage at least one database129. For example, data provider microservice128A manages database129A, data provider microservice128B manages database129B, data provider microservice128C manages database129C, and data provider microservice129D manages database129D.

Each of databases129A-129D may be a relational database that includes one or more tables. Additionally, each of databases129A-129D may store provider microservice data that includes one or more data objects. In an embodiment, each of databases129A-129D may store a different type of data object. The type of data object stored in a database129may correspond to the function being implemented by the data provider microservice128that manages the database129. For example, the type of data is objects stored in database129A may correspond to the type of function that data provider microservice128A implements for an application. Similarly, the type of data object stored in database129B may correspond to the type of function that data provider microservice128B implements for the application.

The microservices architecture126may include distributed cache130. The distributed cache130may store one or more data objects from databases129A-129D. As will be described in further detail below with relation to procedure200ofFIG.2, a data provider microservice128may modify a data object (e.g., create a new data object, change an existing data object, remove/delete an existing data object) on a corresponding database129. In response to the modifying, the data provider microservice128may provide, e.g., transmit, the modified data object to the distributed cache130and the distributed cache130may store the modified data object. Each of data provider microservices128may provide data objects to the distributed cache130for storage and may also access the distributed cache130to obtain a data object. Additionally, each data provider microservice128may request and obtain a data object from a different data provider microservice128when, for example, the requested data object is not maintained at the distributed cache130.

Each of data consumer microservices127A-127D does not manage a corresponding database129. As such, the data consumer microservices127A-127D may not provide data to distributed cache130for storage. Instead of managing data via a database129, a data consumer microservice127may request and receive a data object as will be described in further detail below with relation to procedure300ofFIG.3. Each is data consumer microservice127may access the distributed cache130to obtain a data object. Additionally, each data consumer microservice127may request and obtain (as indicated by the dashed lines inFIG.1B) a data object from a data provider microservice128when, for example, the requested data object is not maintained at the distributed cache130.

Therefore, the data consumer microservices127can only access distributed cache130, while data provider microservices128may provide data for storage at distributed cache130and may also access distributed cache130for a data object, i.e., the data provider microservice128may also operate as a data consumer microservice127.

Each computing device, e.g., one or more local client devices110, data consumer microservices127, data provider microservices128, and data cache130, may include processors, memory/storage, a display screen, and/or other hardware (not shown) for executing software, storing data, and/or displaying information. In an embodiment, data consumer microservices127and data provider microservices128may each be a server with dedicated resources.

FIG.2is a flow diagram of a sequence of steps for storing and maintaining data at a distributed cache130of microservices architecture126according to the one or more embodiments as described herein. Although the description with relation toFIG.2may refer to data provider microservice128, data consumer microservice127, and/or data cache130performing an operation/function/step, it is expressly contemplated that a processor (not shown) of data provider microservice128, data consumer microservice127, and/or data cache130may perform the described operation/function/step.

The procedure200starts at step205and continues to step210where one or more data provider microservices128, e.g.,128A-128D, modify data on a corresponding managed database. For example, data provider microservice128A may modify data on database129A, data provider microservice128B may modify data on database129B, data provider microservice128C may modify data on database129C, and data provider microservice129D may modify data on database129D. However, data provider microservice128A cannot, for example, modify data on databases129B-129D since data provider microservice128A does not manage databases129B-129D.

In an embodiment, a data provider microservice128modifying data on a managed database129includes one or more of (1) the data provider microservice128generating new data to be maintained on the managed database129, (2) the data provider microservice128changing data that is stored on managed database129, and (3) the data provider microservice128deleting data from the managed database129.

In an embodiment, a request to modify data may originate from client device110. For example, a user, e.g., customer or authorized employee of the enterprise, may utilize application125executing on client device110to issue a request to modify data stored on database129A managed by data provider microservice128A. In response to receiving the request, data provider microservice128A may determine if the modification request is consistent with the privileges assigned to the user that is making the request. For example, a user may have privileges to only change data objects, e.g., the user does not is have the privilege to delete/remove data objects. If the modification request is consistent with the privileges, the data provider microservice128A may modify the data object as requested. If the modification request is inconsistent with the privileges, the data provider microservice128A may decline to perform the modification and provide a notification to the user via the client device110.

In an embodiment, a data provider microservice128may optionally store an identifier on a managed database129indicating that data has been modified. For example, let it be assumed that data provider microservice128A changes data object X from a value of “2” to a value of “4” in database129A. In response to changing data object X, the data provider microservice128A may store an identifier in database129A indicating that data object X has changed its value. For example, a column of a table stored on database129A may include a row for each data object, and a row corresponding to data object X may store an identifier of “change” indicating that data object X has changed. If, for example, a new data object has been added to managed database129A, the data provider microservice128A may store an identifier of “add”. Similarly, if a data object is removed from managed database129A, data provider microservice128A may store an identifier of “remove”. Although the examples as described herein use particular identifiers to indicate a modified data object, it is expressly contemplated that any of a variety of different identifiers may be utilized.

For the example ofFIG.2, Let it be assumed that data provider microservice128A changes data object X that is stored on database129A and data provider microservice128C adds new data object Y to database129C.

The procedure200continues to step215and the one or more modified data objects are transmitted to distributed cache130. In an embodiment, a data provider microservice128may transmit a modified data object to distributed cache130in near real-time. For example, and in response to modifying data objects X and Y, data provider microservices128A and128C may respectively transmit data objects X and Y to distributed cache130.

In addition or alternatively, a data provider microservice128may transmit a modified data object to distributed cache130on-demand. For example, a user, e.g., a customer or employee of the enterprise, may utilize application125executing on client device110to issue a command requesting that all modified objects be transmitted to distributed cache130. In response to the command, data provider microservices128A and128C may respectively transmit data objects X and Y to distributed cache130. In addition or alternatively, data provider microservices128may transmit modified data objects to distributed cache130on a predetermined schedule. For example, let it be assumed that the predetermined schedule is every day at 5:00 PM EST. Therefore, each data provider microservice128may transmit the data objects that are modified for that day at 5:00 PM EDT on that same day.

In an embodiment, a modified data object may be transmitted with a data type identifier and a data object identifier. As previously explained, each of databases129A-129D may store a different type of data object. The type of data object stored in a database129may correspond to the function being implemented by the data provider microservice128that manages the database129. For example, the type of data objects is stored in database129A may correspond to the type of function that data provider microservice128A implements for an application, while the type of data objects stored in database129C may correspond to the type of function that data provider microservice128C implements for the application.

Because data object types are unique for each managed database129, an identifier for the data object type can be used to uniquely identify the data provider microservice128that manages the corresponding database129. For example, a data type identifier that uniquely identifies the type of data objects stored in database129A can be used to uniquely identify data provider microservice128A from the other data provider microservices128B-128D. Similarly, a data type identifier that uniquely identifies the type of data objects stored in database129C can be used to uniquely identify data provider microservice128C from the other data provider microservices129A,129B, and129D.

For this example, let it be assumed that identifier “111” is a data type identifier for the data objects stored on database129A that is managed by data provider microservice128A. Therefore, identifier “111” may uniquely identify data provider microservice128A from data provider microservices128B-128D. Further, let it be assumed that identifier “222” is a data type identifier for the data objects stored on database129C that is managed by data provider microservice128C. Therefore, identifier “222” may uniquely identify data provider microservice128C from data provider microservices128A,128B, and128D.

Additionally, a data object identifier may uniquely identify a data object on a is database129. For example, an identifier of “X1” may uniquely identify data object X from all other data objects stored on database129A. Further, an identifier of “Y2” may uniquely identify data object Y from all other data objects stored on database129C. It should be noted that because the data object identifier is unique for a database129, multiple databases129may use the same data object identifier. For example, database129A may store a data object with a data object identifier of “Y2”. Similarly, database129C may store a data object with a data object identifier of “X1”.

Therefore, and based on modifying data object X, data provider microservice128A may transmit data object X, data type identifier “111”, and data object identifier “X1” to distributed cache130. Based on modifying data object Y, data provider microservice128C may transmit data object Y, data type identifier “222”, and data object identifier “Y2” to distributed cache130.

The procedure200optionally continues to step220and the distributed cache130determines if the one or more modified data objects are from authorized microservices. In an embodiment, the distributed cache130may maintain a data structure (not shown) that stores data type identifiers that correspond to data provider microservices128that are authorized to store data objects at distributed cache130. For this example, let it be assumed that the data structure maintained at distributed cache130indicates that data provider microservices128A-12BC are authorized data provider microservices128. As such, data objects from databases129A-129C can be provided by data provider microservices128A-128C to distributed cache130for storage. If, for example, data is provider microservice128D provides a modified data object from database129D to distributed cache130, distributed cache130may determine that the data type identifier for data provider microservice128D is not included in the data structure. As such, the distributed cache130may reject the request to store the data object from database129D.

In an embodiment, data consumer microservices127are not permitted to store objects on distributed cache130. As such, and in this example, if the data consumer microservice127provides data to the distributed cache130for storage, the distributed cache130may decline the storage request.

If at optional step220it is determined that the one or more modified data objects are not from authorized microservices, the procedure continues to step225and the distributed cache130does not store the received modified data objects. The procedure200continues from step225and reverts to step210such that modified data objects can be provided, repeatedly and iteratively, from microservice data provider128A-128D and stored to the distributed cache130.

If optional step220is not performed or if it is determined at optional step220that the one or more modified data objects are from authorized microservices, the procedure continues to step230. At step230, the distributed cache130stores the received modified data objects. In an embodiment, a modified object is stored at distributed cache130with the transmitted data type identifier and data object identifier. In this example, data object X is stored at distributed cache130with data type identifier “111” and data object identifier “X1”. Similarly, data object Y is stored at distributed cache130with data type identifier “222” and data object identifier “Y2”.

As previously mentioned, the data object identifier for a data object may be unique on the database129on which the data object is stored. However, the data object identifier may not be unique across databases129. Therefore, the data type identifier, which is unique for each data provider microservice128and its managed database129, can be utilized in conjunction with the data object identifier to uniquely identify the data object on distributed cache130. As such, and in this example, the data type identifier of “111” and data object identifier of “X1” can uniquely identify data object X, that is from data provider microservice128A, on distributed cache130. Similarly, the data type identifier of “222” and data object identifier of “Y2” can uniquely identify data object Y, that is from data provider microservice128C, on distributed cache130.

In an embodiment, the distributed cache130may determine if there is enough available storage on the distributed cache130to store the one or more modified data objects. If there is not enough available storage, the distributed cache130may implement an eviction policy to remove one or more existing data objects from the distributed cache130to enable the necessary storage to store the one or more modified data objects. In an embodiment, the eviction policy is a time to live algorithm that evicts existing cache data from the distributed cache130that is the oldest. In an embodiment, the eviction policy is an algorithm that evicts the least-frequently used data objects from the distributed cache130. Alternatively, any of a variety of different eviction policies may be utilized by the distributed cache.

In addition or alternatively, the distributed cache130may implement an eviction policy when the available storage on the distributed cache130reaches a threshold amount. For example, the distributed cache130may implement an eviction policy when there is only 10% available storage on the distributed cache130.

The procedure200continues from step230and reverts to step210such that modified data objects can be provided, repeatedly and iteratively, from microservice data provider128A-128D and stored to the distributed cache130.

As will be described in further detail below, a microservice, e.g., a consumer microservice127, may request a data object from distributed cache130. If the data object is stored at the distributed cache130, the data object may be provided from the distributed cache130to the requesting microservice. If the data object is not stored at distributed cache130, the microservice may directly request the data object from a data provider microservice, and the data object may be stored at the distributed cache130and provided to the requesting microservice.

FIG.3is a flow diagram of a sequence of steps for a microservice requesting data from a microservices architecture126with distributed cache130according to the one or more embodiments as described herein. Although the description with relation toFIG.3may refer to data provider microservice128, data consumer microservice127, and/or data cache130performing an operation/function/step, it is expressly contemplated that a processor (not shown) of data provider microservice128, data consumer microservice127, and/or data cache130may perform the described operation/function/step.

The procedure300starts at step305and continues to step310where a request is received for a data object from microservices architecture126. In an embodiment, the request may be issued from client device110on client side102. Specifically, a user may is utilize application125executing on client device110to request a data object. For example, a customer or employee of a financial services institution may utilize application125executing on client device110to request a financial services data object. Continuing with the example utilized in relation toFIG.2, let it be assumed that a user requests data object Y using application125executing on client device110.

In an embodiment, the request from the client device110may invoke an API corresponding to a particular microservice. Specifically, each of data consumer microservices127and/or data provider microservice128may publish the API utilized to request its services. As such, the client device110may issue the request utilizing a published API for a particular microservice. Alternatively, the request may be issued to an API gateway (not shown). The API gateway may act as a single-entry endpoint to the microservices architecture126that maps and forwards the request issued by client device110to the appropriate data consumer microservice127, for example.

The procedure300continues to step315and the request for the data object is transmitted to a data consumer microservice127. In an embodiment, the request from the client device110may be transmitted over network111to a data consumer microservice127. Alternatively, the request from the client device110may be transmitted over network111to a data provider microservice128that operates as a data consumer in addition to operating as a data provider microservice. In this example, let it be assumed that the request for data object Y is transmitted from the client device110to data consumer microservice127B utilizing the API for data consumer microservice127B.

The procedure continues to step320and the data consumer microservice127is issues a cache request to the distributed cache130for the data object. In an embodiment, the cache request includes at least an object type identifier and an object identifier corresponding to the requested data object. For this example, the cache request transmitted from data microservice127B to distributed cache130includes at least data type identifier of “222” and data object identifier “Y2” for data object Y.

The procedure continues to step325and the distributed cache130determines if the requested data object is stored (i.e., cache hit) or not stored (i.e., cache miss) at the distributed cache130. In an embodiment, the distributed cache130utilizes the data type identifier and the data object identifier included in the cache request from data consumer microservice127B to search the distributed cache130for the requested data object. Specifically, the data type identifier and the data object identifier may uniquely identify the data object in the distributed cache130.

In this example, the data type identifier of “222” and the data object identifier of “Y2” uniquely identify data object Y at distributed cache130. As such, the distributed cache130utilizes the data type identifier of “222” and the data object identifier of “Y2” to search the distributed cache130for data object Y.

If it is determined at step325that the requested data object is stored at the distributed cache130, the procedure continues to step330and the requested data object is returned. For example, the distributed cache130may provide the data object Y to data consumer microservice127B, and data consumer microservice127B may return data object Y to client device110that issued the request for data object Y. Alternatively, the distributed cache130may directly transmit requested data object Y to client device110. The procedure then ends at step350.

If it is determined at step325that the requested data is not stored at the distributed cache130, the procedure300continues from step325to step335. At step335, the data consumer microservice127may issue a request for the data object to a data provider microservice128that manages a database129that stores the requested data object. In an embodiment, the data consumer microservice127may issue the request utilizing the published IP of the data provider microservice128.

In an embodiment, the request from the data consumer microservice127includes a data type identifier and/or data object identifier for the requested data object. In an embodiment, the data consumer microservice127may issue the request to an API gateway that may issue a subsequent request, that includes the data type identifier and/or data object identifier, to the data provider microservice128utilizing the API of the data provider microservice128.

Procedure300continues from step335to step340. At step340, and in response to receiving the request from the data consumer microservice127for the data object, the data provider microservice128provides the requested data object to the distributed cache130for storage and the data consumer microservice127. Specifically, the data provider microservice128may utilize the data object identifier, included in the request from the data consumer microservice127, to obtain the data object from the managed database129. The data consumer microservice127may then transmit, in parallel or serially, the obtained data object to the distributed cache130for storage and to the data consumer microservice127that requested the data object. The data object may be stored at the distributed cache130with a data type identifier and a data object identifier.

The procedure continues to step345and the data consumer microservice127transmits the data object to the requesting client device110. Specifically, the data consumer microservice127may transmit the data object to the application125executing on the client device110. The procedure300then continues from step345to step350and ends.

According to the one or more embodiments as described herein, a data consumer microservice127can obtain a requested data object from distributed cache130without having to issue a microservice data sharing request, e.g., REST API, to a data provider microservice128. Because microservice data sharing is not required when the data object can be obtained from the distributed cache130, the one or more embodiments as described herein reduce east-west traffic when compared to conventional microservices architectures that require microservice data sharing between microservices to share data objects.

Because east-west traffic is reduced according to the one or more embodiments described herein, the response latency at data consumer microservices127requesting a data object is also reduced. For example, the following tables illustrate different response latencies. The first table illustrates the response latency for data consumer microservices127operating in microservices architecture126with distributed cache130according to the one or more embodiments as described herein. The second table illustrates the is response latency for data consumer microservices operating in conventional microservices architectures without a distributed cache and that require microservice data-sharing (e.g., east-west traffic) to share data objects.

As illustrated above, the data consumer microservices127experience a response latency of 1.5 ms during both test durations (e.g., 10 minutes and 60 minutes) when obtaining the requested data objects from distributed cache130of microservices architecture126according to the one or more embodiments as described herein. In contrast, data consumer microservices of conventional systems that utilize microservice data sharing to obtain data objects (e.g., east-west traffic) experience a response latency of 20 ms and 25 ms for the two test durations, respectively. Because the one or more embodiments improve latency (e.g., reduce latency for requested objects) when compared to conventional techniques, the one or more embodiments as described herein provide an improvement to the computer, e.g., microservices architecture126, itself and also provide an improvement in the existing technological field of microservices computing.

It should be understood that a wide variety of adaptations and modifications may be made to the techniques. For examples, the steps of the flow diagrams as described is herein may be performed sequentially, in parallel, or in one or more varied orders. In general, functionality may be implemented in software, hardware or various combinations thereof. Software implementations may include electronic device-executable instructions (e.g., computer-executable instructions) stored in a non-transitory electronic device-readable medium (e.g., a non-transitory computer-readable medium), such as a volatile memory, a persistent storage device, or other tangible medium.

Additionally, it should be understood that the term user and customer may be used interchangeably. Hardware implementations may include logic circuits, application specific integrated circuits, and/or other types of hardware components. Further, combined software/hardware implementations may include both electronic device-executable instructions stored in a non-transitory electronic device-readable medium, as well as one or more hardware components. Above all, it should be understood that the above description is meant to be taken only by way of example.