FIELD OF THE DISCLOSURE

The present disclosure generally relates to computing, namely distributed microservices. More particularly, the present disclosure relates to systems and methods for managing a distributed microservice architecture as a monolithic distribution.

BACKGROUND OF THE DISCLOSURE

A Service-Oriented Architecture (SOA) is an approach in software design in which application components provide services to other components via a communications protocol. The principles of service-orientation are independent of any vendor, product, or technology. A service is a self-contained unit of functionality, and services can be combined to provide the functionality of a large software application. A processing device can run any number of services, and each service is built in a way that ensures that the service can exchange information with any other service. Microservices are a variant of SOA used to build distributed software systems. Similar to SOA, services in a Microservice Architecture (MSA) are processes that communicate with each other over the network in order to fulfill an objective, and these services use technology-agnostic protocols. In a Microservice Architecture, services should be small, and the protocols should be lightweight. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it much easier to change and add functions and qualities to the system anytime. One example of a distributed software system that uses services is a network element in a telecommunications network, e.g., an optical network element, router, switch, etc.

A distributed microservice architecture is a system in which microservices can be deployed to run independently and distributed across a set of processors. Each microservice is responsible for managing its own data, and the data ownership model can be distributed across many microservices. This architecture does not dictate any specific database solution to manage this configuration data. In fact, configuration data in one microservice may be translated and stored in storage owned by a completely different internal microservice.

Current systems allow transactional support across distributed systems, but in all cases, the client must have detailed knowledge of the services it is communicating with. In a network-wide deployment, a channel being set up across multiple devices needs to talk to each device and manage the transaction at the network level. This is satisfactory since the network has been designed with the components in mind. In cases where the details of the implementation are abstracted from the controller, there is a need for a separate hand-crafted orchestrator, i.e., described herein as a service broker, to manage transactions across granular services.

BRIEF SUMMARY OF THE DISCLOSURE

In an embodiment, a non-transitory computer-readable storage medium includes instructions stored thereon, the instructions provide a service broker that is an orchestration layer for transactions in a distributed microservice system. The instructions, when executed, cause one or more processors to perform the steps of receiving a provisioning request in the distributed microservice system, wherein the provisioning request is redirected to the service broker, and wherein the distributed microservice system includes a plurality of microservices each managing its own data such that there is no central configuration store for the plurality of microservices; and managing the plurality of microservices by the service broker as a monolith in context of the provisioning request to perform detecting, validating, and one of committing and canceling changes in the distributed microservice system due to the provisioning request. The provisioning request can be for a transaction that spans multiple microservices of the plurality of microservices. The monolith can include the service broker temporarily managing the data of each of the plurality of microservices. The service broker can include a library in each microservice, configured to redirect the provisioning request to a local service broker. The service broker can be a global service broker for all of the plurality of microservices in the distributed microservice system. The provisioning request can be a first request for a transaction, and wherein subsequent requests for the transaction are managed internally by the service broker. The instructions, when executed, can further cause one or more processors to perform the steps of constructing a temporary monolithic database of data in respective microservices for the managing; and destroying the temporary monolithic database subsequent to completion of the transaction.

In another embodiment, a distributed microservices system includes a plurality of microservices each executed on one or more processing devices, wherein each microservice manages its own data such that there is no central configuration store for the plurality of microservices; and a service broker configured to operate as an orchestration layer for transactions in the distributed microservice system, wherein the service broker is configured to receive a redirected provisioning request, and manage the plurality of microservices by the service broker as a monolith in context of the provisioning request to perform detection, validation, and one of commit and cancel changes in the distributed microservice system due to the provisioning request.

In a further embodiment, a method, for implementing a service broker that is an orchestration layer for transactions in a distributed microservice system, includes receiving a provisioning request in the distributed microservice system, wherein the provisioning request is redirected to the service broker, and wherein the distributed microservice system includes a plurality of microservices each managing its own data such that there is no central configuration store for the plurality of microservices; and managing the plurality of microservices by the service broker as a monolith in context of the provisioning request to perform detecting, validating, and one of committing and canceling changes in the distributed microservice system due to the provisioning request.

