Patent Description:
<CIT> discloses partitioning monolithic legacy applications.

Microservice (or microservice architecture) is an architectural style that structures an application as a collection of layers (or services). It can allow developers to design applications by decomposing the application into layers that implement specific functions. The microservice architecture can be suitable for rapid, frequent and reliable delivery of applications that are large and/or complex. The various layers can communicate with each other through standardized application programming interfaces (APIs).

Various aspects of the disclosed subject matter may provide one or more of the following capabilities.

In one implementation, a method includes receiving data characterizing a notification indicative of modification to a first source code of a first layer of a software architecture. The first layer is stored in a first repository of a plurality of repositories of a microservice. The method further includes generating a modified first package including a first computer-executable code generated by at least compiling the first source code and assigning a unique first name to the modified first package. The method further includes transmitting an instruction to a repository manager of a package repository to store the modified first package with the assigned first name in the package repository. The method also includes generating a first modified container image including the modified first package.

One or more of the following features can be included in any feasible combination.

In some implementations, the method further includes executing the first modified container image. The first modified container image further includes a microservice layer including a microservice source code configured to execute source codes in a plurality of packages in the modified container image by at least communicating between one or more packages of the plurality of packages. The plurality of packages includes the modified first package.

In some implementations, the method further includes retrieving at least a second source code of a second layer of the plurality of layers. The method also includes generating a modified second package including a second computer-executable code generated by at least compiling the second source code and assigning a unique second name to the modified second package. The method further includes transmitting an instruction to the repository manager of the package repository to store the modified second package with the assigned second name in the package repository. The method also includes generating a second modified container image including the modified second package and the modified first package.

In some implementations, the method further includes receiving data characterizing a second notification indicative of modification to the second source code of the second layer of the software architecture. In some implementations, the software architecture includes a plurality of layers including the first layer and the second layer. The first layer is stored in a first repository of the plurality of repositories and the second layer is stored in a second repository of the plurality of repositories.

In some implementations, the package repository is configured to store packages associated with each of the plurality of layers of the software architecture. In some implementations, source code of each of the plurality of repositories is configured to be independently compiled. In some implementations, the method further includes retrieving at least the first source code of the first layer. In some implementations, the software architecture is configured to be executed on a plurality of compute nodes.

These and other capabilities of the disclosed subject matter will be more fully understood after a review of the following figures, detailed description, and claims.

Microservice or microservice architecture can allow for software development by dividing a software architecture into multiple layers or modules (e.g., based on functionality). The source code of the various layers can be interdependent. For example, a first source code (e.g., a class) in a first layer can be dependent on (e.g., call upon) a second source code (e.g., a class) in a second layer, and changes made to the first source code can affect the second source code and vice-versa. The various layers can be stored in the same data repository and can be compiled as a unit to generate a package. This form of dependency can be referred to as tight-coupling. Tight coupling between the layers of the software architecture can render the process of software development on the microservice inefficient. For example, developers may not be able to independently work on the source code of the different layers of a tightly coupled architecture (e.g., independently compile an updated version of the source code of a given layer).

Some implementations of the current subject matter can enable independent handling of the various layers. The source code of the different layers can be independent of each other (e.g., compiled separately). Independent compilation can be achieved, for example, by storing the source code of different layers in separate repositories that can be independently compiled to generate independent packages. For example, each time a developer modifies the source code of a given layer, the modified source code can be compiled to generate a new / modified package that includes computer-executable code associated with the modified source code. The new package can be assigned a unique name and stored in a package repository. Storing the source code for different layers in different repositories can improve the manageability and maintenance of the source code in the various layers. For example, storing the source code of different layers in separate repositories can maintain the integrity of source codes of the different layers when modifications are made to the source code of a given layer. In other words, if a user is modifying the source code of a given layer, modifications to source code of a different layer stored in a second repository can be prevented (e.g., because the user may not have access to the second repository).

A container image can be generated that can include the various packages in the package repository (e.g., one package for each layer in the microservice). In some implementations, each time a source code of a layer is compiled (e.g., after a modification has been committed) to generate a new package, a new container image that includes the new package can be generated. The container image can include a microservice layer (e.g., included in the software architecture) that can facilitate communication between the various packages, and can serve as an external interface (e.g., handle requests from users). The new container image can be deployed and executed (e.g., in distributed compute nodes).

<FIG> is a flow chart of an exemplary method for generating a modified container image based on modification to a layer of a software architecture. At step <NUM>, data characterizing a notification indicative of modification to a first source code can be received. The first source code can be included in a first layer of a software architecture. The first layer can be stored in a first repository of a plurality of repositories of a microservice architecture. <FIG> illustrates an exemplary microservice architecture <NUM> for generating and deploying a container image. The microservice architecture <NUM> includes an architecture layer repository <NUM> (e.g., multiple file storage locations), an integration pipeline <NUM>, a package repository <NUM>, container registry <NUM> and a deployment pipeline <NUM>. The architecture layer repository <NUM> can include multiple repositories (e.g., multiple file / source code storage locations) that can store the different layers of the software architecture. The various repositories can be configured to store the source code of the layers (e.g., each layer repository can store the source code of a unique layer).

As illustrated in <FIG>, the architecture layer repository <NUM> can include a first repository <NUM>, a second repository <NUM>, a third repository <NUM>, and a fourth repository <NUM>. A software architecture can be developed and executed on the microservice architecture <NUM>. The software architecture can include multiple layers where each layer can include a source code. Layers of the software architecture (e.g., source codes of the layers) can be stored in the different repositories, and the source codes can be independently compiled. For example, source codes of the different layers may be loosely coupled (e.g., source codes pass dependencies externally instead of being hard-coded). Loose coupling and/or storage of source codes of different layers in different repositories can allow for independent compilation of the source codes and generation of the corresponding packages.

In some implementations, the software architecture can include a contract layer <NUM> stored in the first repository <NUM>; a data access layer <NUM> stored in the second repository <NUM>; a business layer <NUM> stored in the third repository <NUM>; and a microservice layer <NUM> stored in the fourth repository <NUM>. In some implementations, the contract layer <NUM> can define interfaces, provide API declarations and fix contracts for communications. In some implementations, data access layer <NUM> can allow for creating, retrieving, updating and deleting operations. In some implementations, the business layer <NUM> can represent the part of the software architecture that implements logic. For example, it can be responsible for retrieving data and converting it into meaningful concepts for the software architecture (e.g., tasks such as processing, validating, associating, etc., associated with handling data). In some implementations, the microservice layer can handle user requests (e.g., requests from a developer computing device <NUM>), and render a response to the user (e.g., with the aid of the business layer <NUM> and/or the data access layer <NUM>).

When the source code (e.g., the first source code) in one of the layers (e.g., contract layer <NUM>, data access layer <NUM>, business layer <NUM>, etc.) is modified (e.g., by a developer computing device <NUM>), data characterizing a notification indicative of modification to the source code can be transmitted (e.g., by the architecture layer repository <NUM>) and received by the integration pipeline <NUM>. Returning to <FIG>, at step <NUM>, a package (e.g., a modified first package) including a computer-executable code (e.g., a first computer-executable code) can be generated by at least compiling the source code (e.g., the first source code of one of the contract layer <NUM>, the data access layer <NUM>, the business layer <NUM>, etc.). For example, the integration pipeline <NUM> can retrieve the source code from the architecture layer repository <NUM> after receiving the notification at step <NUM> (e.g., from the architecture layer repository <NUM>), and compile the source code to generate the computer-executable code. The integration pipeline <NUM> can generate the package that includes the computer executable code generated at step <NUM>. The package can further include library code needed to execute the computer-executable code in the package. In some implementations, the library code can allow for execution of the computer-executable code in the package by a computing device or a distributed computing system (e.g., a kubernetes cluster, elastic container service, etc.) without the need for additional prerequisite software.

In some implementations, the integration pipeline <NUM> can assign a unique name (e.g., a unique first name) to the package generated at step <NUM>. The assigned unique name can be indicative of a change made to the source code that triggered the notification at step <NUM>, the identity of the integration pipeline <NUM> and a unique number generated (e.g., by the integration pipeline <NUM>) when the integration pipeline <NUM> receives the notification at step <NUM>. The unique name assigned to the package can allow for identifying the generated package. In some implementations, the unique name can have three components separated by ". " (e.g., A. The first component ("A") can be indicative of a change in the name of a function in the source code (e.g., API breaking change). The second component ("B") can be indicative of a changes the source code that may not affect the existing functionality of the source code (e.g., addition of a new function to the source code, creating of a new API, etc.). The third component ("CDE") can include a unique number generated when the integration pipeline <NUM> receives the notification at step <NUM>.

Returning to <FIG>, at step <NUM>, an instruction can be transmitted (e.g., by the integration pipeline <NUM>) to the repository manager of the package repository <NUM> to store the package (e.g., the modified first package with the assigned first name) in the package repository <NUM>. The repository manager can control the operation of the package repository <NUM>. For example, the repository manager can store data files (e.g., packages) on the package repository <NUM> (e.g., based on an external instruction / request). The repository manager can retrieve data files from the package repository <NUM>. Upon receiving the instruction, the repository manager can store the package generated by the integration pipeline <NUM> at step <NUM>. The package repository <NUM> can be configured to store packages associated with the plurality of layers. In some implementations, the package repository <NUM> can store multiple packages for a given layer of the software architecture. For example, each time the source code of a layer has been modified, a new modified package can be generated and stored in the package repository <NUM>. In some implementations, the package repository <NUM> can replace the previous version of the package of a given layer with a new version of the package indicative of the latest changes to the source code of the given layer.

At step <NUM>, a container image <NUM> (e.g., a modified container image) that includes multiple packages in the package repository <NUM> can be generated by the integration pipeline <NUM>. In some implementations, the container image <NUM> can include packages associated with multiple layers of the software architecture. The container image <NUM> can include a package for each layer in the software architecture. Additionally, the container image <NUM> can include the package (e.g., the modified first package) generated at step <NUM>. In some implementations, the integration pipeline <NUM> can be configured to select the newest package for each layer of the software architecture (e.g., the most recently generated package for each of the layers). In some implementations, the packages can be selected by a user (e.g., via the developer computing device <NUM>). For example, the integration pipeline <NUM> can present a list of packages stored in the package repository <NUM> to the user, and the user can select the packages to be included in the container image <NUM> (e.g., a package for each of the layers in the software architecture). The integration pipeline <NUM> can receive data characterizing the user selection of the packages and generate a container image that includes the selected packages.

The container image <NUM> can be stored in the container registry <NUM>. The integration pipeline <NUM> can generate a unique identifier associated with the container image <NUM> that can be used to deploy the container image <NUM>. For example, the unique identifier can be used to retrieve the container image <NUM> form the container registry <NUM>. The unique identifier can be provided to a user (e.g., via the computing device <NUM>). The user can request the deployment of the container image <NUM> by providing the unique identifier to the deployment pipeline <NUM>. The deployment pipeline <NUM> can retrieve the container image <NUM> from the container registry <NUM> and deploy the container image <NUM> on a computing device or a distributed computing system (e.g., a kubernetes cluster).

In some implementations, the deployment pipeline <NUM> can receive data characterizing deployment parameters associated with the deployment of the container image <NUM> (e.g., deployment on a plurality of compute nodes of a distributed computing system) from a user. The deployment parameters can include the computing resources of the distributed computing system needed to execute the computer-executable codes of the various layers in the packages in the container image <NUM>. For example, the deployment parameters can include one or more of the compute nodes (e.g., processors / processing resources), data storage capacity, RAM, etc. that are needed to execute the computer-executable codes. Based on deployment parameters, the deployment pipeline <NUM> can allocate the computing resources of the distributed computing system.

In some implementations, the deployment pipeline <NUM> can deploy or generate a microservice pod <NUM> associated with the container image <NUM>. The deployment pipeline <NUM> can retrieve the container image <NUM> from the container registry <NUM> and generate the microservice pod <NUM> based on the retrieved container image <NUM> and the received deployment parameters. The microservice pod <NUM> can be configured to execute the computer-executable code in the container image <NUM> (e.g., on a distributed computing system based on the deployment parameters).

In some implementations, the container image <NUM> can include a microservice layer including a microservice source code configured to execute the source codes in the various packages in the container image <NUM>. The integration pipeline <NUM> can store the microservice layer (e.g., stored in the fourth repository <NUM> of the architecture layer repository <NUM>). The microservice layer can allow for communication between one or more packages in the container image <NUM> (e.g., between modified first package and other packages in the container image <NUM>).

In some implementations, each time source code of a layer (e.g., second source code of a second layer) stored in the architecture layer repository <NUM> is modified (e.g., by the developer computing device <NUM>), steps <NUM>-<NUM> described above can be repeated. For example, a new package (e.g., modified second package) with the computer-executable code of the aforementioned source code can be generated. The integrated pipeline <NUM> can retrieve the modified source code, compile the source code and generate the new package (e.g., as described in steps <NUM> and <NUM> above). The integrated pipeline <NUM> can transmit instructions to the repository manager of the package repository <NUM> to store the new package (e.g., the modified second package with the assigned second name) in the package repository <NUM> (e.g., as described in step <NUM> above). Additionally, a new container image (e.g., a second modified container image) that includes multiple packages in the package repository <NUM> can be generated (e.g., as described in step <NUM> above). In some implementations, the second modified container image can include the newest package for each layer of the software architecture (e.g., the modified first package and/or the modified second package).

In some implementations, source code can be human-readable code that can be written in program languages such as python, C++, etc. In some implementations, computer-executable codes can be machine-readable codes that can be generated by compiling one or more source codes. Computer-executable codes can be executed by operating systems (e.g., linux, windows, mac, etc.) of a computing device or distributed computing system. For example, computer-executable codes can include data needed to create runtime environment (e.g., binary machine code) that can be executed on the processors of the computing system or the distributed computing system.

Other embodiments are within the scope of the disclosed subject matter. For example, the prioritization method described in this application can be used in facilities that have complex machines with multiple operational parameters that need to be altered to change the performance of the machines. Usage of the word "optimize" / "optimizing" in this application can imply "improve" / "improving.

Certain exemplary embodiments will now be described to provide an overall understanding of the principles of the structure, function, manufacture, and use of the systems, devices, and methods disclosed herein. One or more examples of these embodiments are illustrated in the accompanying drawings. Those skilled in the art will understand that the systems, devices, and methods specifically described herein and illustrated in the accompanying drawings are non-limiting exemplary embodiments and that the scope of the present invention is defined solely by the claims. The features illustrated or described in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention.

The subject matter described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them.

Generally, a processor will receive instructions and data from a Read-Only Memory or a Random Access Memory or both.

The subject matter described herein can be implemented in a computing system that includes a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a web interface through which a user can interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, and front-end components.

Claim 1:
A method (<NUM>) comprising:
receiving (<NUM>) data characterizing a notification indicative of modification to a first source code of a first layer of a software architecture including multiple layers, wherein the first layer is stored in a first repository (<NUM>) of a plurality of repositories (<NUM>, <NUM>, <NUM>, <NUM>) of a microservice, the layers being stored in different repositories (<NUM>, <NUM>, <NUM>, <NUM>) where each layer includes a source code and the source codes are independently compilable by the source codes being arranged to pass dependencies externally instead of being hard-coded,
wherein if a user is modifying the source code of a given layer, modifications to source code of a different layer stored in a second repository can be prevented;
generating (<NUM>) a modified first package including a first computer-executable code generated by at least compiling the first source code and assigning a unique first name to the modified first package indicative of the modification made to the first source code that triggered the notification;
transmitting (<NUM>) an instruction to a repository manager of a package repository to store the modified first package with the assigned first name in the package repository; and
generating (<NUM>) by an integration pipeline (<NUM>) a first modified container image (<NUM>) including packages associated with multiple layers, the container image (<NUM>) including the newest package for each layer, the container image (<NUM>) including a microservice layer to facilitate communication between the packages and serving as an external interface to handle requests from users.