US11860980B2 - Cognitive method to split monolithic architecture into microservice architecture - Google Patents

Abstract

A method and related system detail a split of an architecture of a monolithic application into an architecture of a micro service application. The method receives source code for the monolithic application, and maps the source code into a directed graph. The graph is split into subgraphs and optimized. The method further provides the detailing of the micro service application split, based on the subgraphs.

Description

BACKGROUND

Disclosed herein is a system and related method to split monolithic architecture into microservice architecture. A transition of software architectures from monolithic to microservice provides many benefits, but may be time consuming when done manually.

SUMMARY

According to one aspect disclosed herein, a computer-implemented method is provided for detailing a split of an architecture of a monolithic application into an architecture of a micro service application. The method comprises receiving source code for the monolithic application, and mapping the source code into a directed graph. The graph is split into subgraphs and optimized. The method further provides the detailing of the micro service application split, based on the subgraphs.

According to another aspect, a system is provided comprising a memory and a processor that executes instructions to perform the method is also described herein, along with a computer program product.

The computer program product contains instructions that are, accessible from a computer-usable or computer-readable medium providing program code for use, by, or in connection, with a computer or any instruction execution system. For the purpose of this description, a computer-usable or computer-readable medium may be any apparatus that may contain a mechanism for storing, communicating, propagating or transporting the program for use, by, or in connection, with the instruction execution system, apparatus, or device.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments are described herein with reference to different subject-matter. In particular, some embodiments may be described with reference to methods, whereas other embodiments may be described with reference to apparatuses and systems. However, a person skilled in the art will gather from the above and the following description that, unless otherwise notified, in addition to any combination of features belonging to one type of subject-matter, also any combination between features relating to different subject-matter, in particular, between features of the methods, and features of the apparatuses and systems, are considered as to be disclosed within this document.

The aspects defined above, and further aspects disclosed herein, are apparent from the examples of one or more embodiments to be described hereinafter and are explained with reference to the examples of the one or more embodiments, but to which the invention is not limited. Various embodiments are described, by way of example only, and with reference to the following drawings:

FIG.1A is a block diagram of a data processing system (DPS) according to one or more embodiments disclosed herein.

FIG.1B is a pictorial diagram that depicts a cloud computing environment according to an embodiment disclosed herein.

FIG.1C is a pictorial diagram that depicts abstraction model layers according to an embodiment disclosed herein.

FIG.2A is a block diagram that illustrates an example of an environment for executing a monolithic application, according to some embodiments.

FIG.2B is a block diagram illustrating a transition from a monolithic application to a micro service application, according to some embodiments.

FIG.3 is a flowchart that illustrates a general process used for various embodiments disclosed herein, according to some embodiments.

FIGS.4A and4B are block diagrams that illustrate the code mapping to a graph, according to some embodiments.

FIGS.5A and5B are block diagrams illustrating a scheme for the microservice code splitting, according to some embodiments.

DETAILED DESCRIPTION

The following general acronyms may be used below:

TABLE 1
General Acronyms

	API	application program interface
	ARM	advanced RISC machine
	CD-	compact disc ROM
	ROM
	CPU	central processing unit
	DPS	data processing system
	DVD	digital versatile disk
	EPROM	erasable programmable read-only memory
	FPGA	field-programmable gate arrays
	HA	high availability
	IaaS	infrastructure as a service
	I/O	input/output
	IPL	initial program load
	ISP	Internet service provider
	ISA	instruction-set-architecture
	LAN	local-area network
	LPAR	logical partition
	PaaS	platform as a service
	PDA	personal digital assistant
	PLA	programmable logic arrays
	RAM	random access memory
	RISC	reduced instruction set computer
	ROM	read-only memory
	SaaS	software as a service
	SLA	service level agreement
	SRAM	static random-access memory
	WAN	wide-area network

Data Processing System In General

FIG.1A is a block diagram of an example DPS according to one or more embodiments. In this illustrative example, theDPS10 may includecommunications bus12, which may provide communications between aprocessor unit14, amemory16,persistent storage18, acommunications unit20, an I/O unit22, and adisplay24.

Theprocessor unit14 serves to execute instructions for software that may be loaded into thememory16. Theprocessor unit14 may be a number of processors, a multi-core processor, or some other type of processor, depending on the particular implementation. A number, as used herein with reference to an item, means one or more items. Further, theprocessor unit14 may be implemented using a number of heterogeneous processor systems in which a main processor is present with secondary processors on a single chip. As another illustrative example, theprocessor unit14 may be a symmetric multi-processor system containing multiple processors of the same type.

Thememory16 andpersistent storage18 are examples ofstorage devices26. A storage device may be any piece of hardware that is capable of storing information, such as, for example without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. Thememory16, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Thepersistent storage18 may take various forms depending on the particular implementation.

For example, thepersistent storage18 may contain one or more components or devices. For example, thepersistent storage18 may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by thepersistent storage18 also may be removable. For example, a removable hard drive may be used for thepersistent storage18.

Thecommunications unit20 in these examples may provide for communications with other DPSs or devices. In these examples, thecommunications unit20 is a network interface card. Thecommunications unit20 may provide communications through the use of either or both physical and wireless communications links.

The input/output unit22 may allow for input and output of data with other devices that may be connected to theDPS10. For example, the input/output unit22 may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device. Further, the input/output unit22 may send output to a printer. Thedisplay24 may provide a mechanism to display information to a user.

Instructions for the operating system, applications and/or programs may be located in thestorage devices26, which are in communication with theprocessor unit14 through thecommunications bus12. In these illustrative examples, the instructions are in a functional form on thepersistent storage18. These instructions may be loaded into thememory16 for execution by theprocessor unit14. The processes of the different embodiments may be performed by theprocessor unit14 using computer implemented instructions, which may be located in a memory, such as thememory16. These instructions are referred to as program code38 (described below) computer usable program code, or computer readable program code that may be read and executed by a processor in theprocessor unit14. The program code in the different embodiments may be embodied on different physical or tangible computer readable media, such as thememory16 or thepersistent storage18.

TheDPS10 may further comprise an interface for anetwork29. The interface may include hardware, drivers, software, and the like to allow communications over wired andwireless networks29 and may implement any number of communication protocols, including those, for example, at various levels of the Open Systems Interconnection (OSI) seven layer model.

FIG.1A further illustrates acomputer program product30 that may contain theprogram code38. Theprogram code38 may be located in a functional form on the computerreadable media32 that is selectively removable and may be loaded onto or transferred to theDPS10 for execution by theprocessor unit14. Theprogram code38 and computerreadable media32 may form acomputer program product30 in these examples. In one example, the computerreadable media32 may be computerreadable storage media34 or computerreadable signal media36. Computerreadable storage media34 may include, for example, an optical or magnetic disk that is inserted or placed into a drive or other device that is part of thepersistent storage18 for transfer onto a storage device, such as a hard drive, that is part of thepersistent storage18. The computerreadable storage media34 also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory, that is connected to theDPS10. In some instances, the computerreadable storage media34 may not be removable from theDPS10.

Alternatively, theprogram code38 may be transferred to theDPS10 using the computerreadable signal media36. The computerreadable signal media36 may be, for example, a propagated data signal containing theprogram code38. For example, the computerreadable signal media36 may be an electromagnetic signal, an optical signal, and/or any other suitable type of signal. These signals may be transmitted over communications links, such as wireless communications links, optical fiber cable, coaxial cable, a wire, and/or any other suitable type of communications link. In other words, the communications link and/or the connection may be physical or wireless in the illustrative examples.

In some illustrative embodiments, theprogram code38 may be downloaded over a network to thepersistent storage18 from another device or DPS through the computerreadable signal media36 for use within theDPS10. For instance, program code stored in a computer readable storage medium in a server DPS may be downloaded over a network from the server to theDPS10. The DPS providing theprogram code38 may be a server computer, a client computer, or some other device capable of storing and transmitting theprogram code38.

The different components illustrated for theDPS10 are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a DPS including components in addition to or in place of those illustrated for theDPS10.

Cloud Computing In General

It is to be understood that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

Characteristics Are As Follows

On-demand self-service: a cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service's provider.

Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.

Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

Service Models Are As Follows

Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

Deployment Models Are As Follows

Private cloud: the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).

A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

Referring now toFIG.1B, illustrativecloud computing environment52 is depicted. As shown,cloud computing environment52 includes one or morecloud computing nodes50 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) orcellular telephone54A, desktop computer54B,laptop computer54C, and/or automobile computer system54N may communicate.Nodes50 may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allowscloud computing environment52 to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types ofcomputing devices54A-N shown inFIG.1B are intended to be illustrative only and thatcomputing nodes50 andcloud computing environment52 can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now toFIG.1C, a set of functional abstraction layers provided by cloud computing environment52 (FIG.1B) is shown. It should be understood in advance that the components, layers, and functions shown inFIG.1C are intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

Hardware and software layer60 includes hardware and software components. Examples of hardware components include: mainframes61; RISC (Reduced Instruction Set Computer) architecture basedservers62; servers63; blade servers64; storage devices65; and networks and networking components66. In some embodiments, software components include networkapplication server software67 and database software68.

Virtualization layer70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers71; virtual storage72; virtual networks73, including virtual private networks; virtual applications and operating systems74; andvirtual clients75.

In one example, management layer80 may provide the functions described below. Resource provisioning81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources.User portal83 provides access to the cloud computing environment for consumers and system administrators.Service level management84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment85 provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.

Workloads layer90 provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation91; software development and lifecycle management92; virtual classroom education delivery93; data analytics processing94; transaction processing95; and mobile desktop96.

Any of thenodes50 in thecomputing environment52 as well as thecomputing devices54A-N may be aDPS10.

As discussed in more detail herein, it is contemplated that some or all of the operations of some of the embodiments of methods described herein may be performed in alternative orders or may not be performed at all; furthermore, multiple operations may occur at the same time or as an internal part of a larger process.

Computer Readable Media

The present invention may be a system, a method, and/or a computer readable media at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Cognitive Method To Split Monolithic Architecture Into Microservice Architecture

Traditionally, software has been implemented in a monolithic application structure.FIG.2A is a block diagram that illustrates an example of anenvironment200 for executing amonolithic application222. In this example, an application consumer may use abrowser205 to access acloud220, such as thecloud computing environment52, anode50 in the cloud, or individual computer “Tomcat”220, such as theDPS10. Theenvironment200 may have aload balancer210 between the user'sbrowser205. Thebrowser205 may be used to access various services, Service A through Service E226.1-226.5 (referred to collectively or representatively as226). The services may execute within the monolithic application “War”222, and a front-end user interface224 may be used to present information to the user. The services226 may make use of data stored in adatabase230.

Referring toFIG.2B, which is a block diagram illustrating a transition from a monolithic application to a micro service application, code for themonolithic application222 may be provided to amicroservice splitter240, as described herein, and the output of themicroservice splitter240 may be to provide splitting recommendations to a developer, or to provide an actual modification of the code itself242 such that the developer's modified code or the modified code may be used to generate an application in the form of amicroservice architecture250. Compared with the traditionalmonolithic application200 architecture, themicroservice architecture250 has the characteristics of low coupling between different modules, simple code maintenance, load balancing, and strong scalability. It is suitable for agile development and deployment teams. InFIG.2B, auser interface260 to a micro-service application is provided which may be in the form of, e.g., apersonal computer270 or via amobile device272. These devices may access, via agateway274, various services, Service A through Service D276.1-276.4 within aservice layer262, each of which may be connected to their respective database286.1-286.4 within adata layer264.

However, there are many projects still using the traditionalmonolithic architecture200 for historical reasons. As a result, use of themonolithic architecture200 has resulted in difficulties in deployment, expansion, release rollback, rapid development, and testing during the development process. In order to reduce some of these problems, breaking down the traditional monolithic architecture into a microservice architecture has become a requirement for many projects and associated applications. To resolve this kind of requirement, a more commonly used method is to have developers spend a lot of time and cost to, for themonolithic application200, read the code, sort out the code structure, and split it manually.

FIG.3 is a flowchart that illustrates ageneral process300 used for various embodiments disclosed herein. Thisprocess300 provides an intelligent method to split the traditional monolithic architecture into a microservice architecture. For existing monolithic architecture projects, this method may automatically generate recommendations for splitting and may actually split the monolithic application and its respective code into microservices and their respective code, thus helping developers to sort out the code structure and performing the splitting of the code work.

Thisprocess300 mainly includes three primary operations, illustrated by way of example inFIG.3, but also with respect to the following block diagrams. In a firstprimary operation310, the code from a monolithic architecture is mapped into a directed graph. In a secondprimary operation340, a discovery algorithm (e.g., the Community Overlap PRopagation Algorithm (COPRA)) and label classification model may be used to split the graph into subgraphs and optimizing the graph/subgraph. In a thirdprimary operation370, a recommended solution for microservice splitting is provided corresponding to the subgraph. These three primary operations are discussed in more detail below.

Referring also toFIGS.4A and4B, which show related components, the firstprimary operation310 uses a code to graph mapper410 to map the entire project code structure of aproject file405 to a directedgraph420. Taking methods430 (represented as octagons) and classes425 (represented as circles) as nodes, the affiliation (represented by the “include”435 arrow) of eachclass425 andmethod430, the inheritance between different classes (represented by the “extends”450 arrow inFIG.4B), and the invocation ofmethods430 byclasses425 are all represented by edges (arrows) on thegraph420. The firstprimary operation310 may comprise anoperation312 in which a code tograph mapper410 traverses the project source files405, including itsclass425 files and allmethods430 in the class of the project. The source files may be, e.g., in a text format, and text parsing algorithms may look for key words designating classes, methods, and other relevant code features. As themapper410 performs this traversal, it designates eachclass425 andmethod430 as a vertex of thegraph420, and uses the “include”relationship435 between theclass425 and themethod430 to connect with each other. Theresultant graph420 is illustrated by way of example inFIG.4A.

Next, inoperation314, thegraph mapper410 traverses all of the project files405 (code) again, and uses the “implements”relationship445 to connect the implementation betweenclasses425 andinterfaces440, uses the “extends”relationship450 to connect the inheritance betweendifferent classes425, and use the “call”relationship455 to connect the calling relationship of theclass425 to themethod430. Through the above twooperations312,314, the completed directedgraph420′, corresponding to the project files405 (code), may be obtained.

The secondprimary operation340, based on, e.g., a graph-based community discovery algorithm COPRA and a label classification model, may divide thegraph420′generated in thefirst operation310 into several subgraphs. It may then combine a hierarchical label of the nodes and a splitting principle of microservices as the constraints of the subgraph, and iteratively optimize an optimal subgraph.

In more detail, inoperation342, the label classification model may be used to label eachclass node425 in thegraph420′. The labels may include basic service layer, composite service layer, and controller layer. Inoperation344, the community discovery algorithm COPRA may be used to split existinggraphs420′ into overlapping subgraphs. In the iterative optimization process of the algorithm, each intermediate result may be verified using the following constraints, and a penalty mechanism may be established. The predefined constraints include: a) different sub-graphs can only be called one-way—it is strictly prohibited to call the subgraphs in a loop (which creates a stop condition); and b) the division of sub-graphs follows the horizontal split according to the level label, not on the vertical—corresponding microservices cannot separate each step but should be split into independent microservices according to the business.

When the algorithm parameters are converged and the constraint conditions are met, the sub-graph split is completed. The splitting of the graph to the subgraph obtained in this way has the characteristics of high cohesion and low coupling, and thus has similar characteristics to the splitting of services to microservices. The splitting principle of microservices may be used as constraints to the splitting principle of subgraphs ensure that the subgraphs obtained can be used as microservice splitting.

In a thirdprimary operation370, with each subgraph corresponding to a microservice, and according to the classes and methods contained in the subgraph, a recommended scheme for microservice code splitting is generated.FIGS.5A and5B are block diagrams illustrating a scheme for the microservice code splitting. This scheme may be used as a reference for developers to split microservices, or may be used for embedding comments, flags, compiling/interpreting/execution directives into the code listings themselves.

Each subgraph generated in the secondprimary operation340 corresponds to a microservice510.1 through510.4 (collectively or representatively510), and the thirdprimary operation370 generates a recommendedsolution500 for microservice splitting according to the code file corresponding to the respective subgraph. As shown inFIGS.5A and5B, and according to some embodiments, an output result of this method is the generation a microservice split recommendation solution500 (or plan). Each microservice510 has a “Class” as the granularity level, and the parts belonging to different microservices may be, e.g., marked with different colors (not shown), which may serve as the reference plan for microservice splitting to be used by developers. In some embodiments, the microservicesplit recommendation solution500 may be utilized in actual copies of the code originally used as an input, and flags and the like embedded into the code copies and/or original code files may be split, rearranged, and reassembled based on the microservice split recommendation.

Technical Application

The one or more embodiments disclosed herein accordingly provide an improvement to computer technology. For example, an improvement to a method for splitting a monolithic application architecture into a microservice architecture using graphs allows for more efficient and effective porting of software into an easier to implement and manage microservice architecture scheme.

Claims (11)

What is claimed is:

1. A method for detailing a split of an architecture of a monolithic application into an architecture of a micro service application comprising:

receiving source code for the monolithic application;

mapping the source code into a directed graph;

splitting the graph into subgraphs and optimizing the subgraph;

providing the detailing of the micro service application split, based on the subgraphs; and

performing multiple iterations to optimize a subgraph of the subgraphs; wherein:

the splitting of the graph further comprises utilizing a discovery algorithm and a label classification model for the splitting of the directed graph into the subgraphs;

the iterative optimization comprises verifying each iterative result based on predefined constraints;

the predefined constraints comprise:

different sub graphs can only be called one-way and not in a loop; and

a division of subgraphs follows a horizontal split according to a level label, and not on a vertical; and

the label classification model performs labelling each class node, wherein the label for each class node is selectable from the hierarchical group comprising “basic service layer”, “composite service layer”, and “controller layer”.

2. The method ofclaim 1, wherein the discovery algorithm is a Community Overlap PRopagation Algorithm (COPRA).

3. The method ofclaim 1, wherein the mapping comprises traversing a source file, and, based on the traversing:

designating identified classes and methods as respective vertices of the directed graph; and

designating an include relationship between classes and methods to connect them.

4. The method ofclaim 3, wherein the mapping further comprises:

designating an implements relationship between classes and interfaces; and

designating an extends relationship between classes.

5. The method ofclaim 4, wherein the extend relationship is an inheritance relationship.

6. The method ofclaim 1, wherein the providing of the detailing comprises:

generating a recommendation for the micro services application split; and

communicating the recommendation to developers via a network interface.

7. The method ofclaim 1, wherein the providing of the detailing comprises modifying the source code using the micro service application split to enable a generation of the micro service application from the source code.

8. A system, the system comprising:

a memory, the memory containing one or more instructions; and

a processor, the processor communicatively coupled to the memory, the processor, in response to reading the one or more instructions, configured to:

receive source code for the monolithic application;

map the source code into a directed graph;

split the graph into subgraphs and optimizing the subgraph;

provide the detailing of the micro service application split, based on the subgraphs; and

perform multiple iterations to optimize a subgraph of the subgraphs; wherein:

the split of the graph further comprises the processor being configured to utilize a discovery algorithm and a label classification model for the split of the directed graph into the subgraphs;

the iterative optimization comprises the processor being configured to verify each iterative result based on predefined constraints;

the predefined constraints comprise:

different sub graphs can only be called one-way and not in a loop; and

a division of subgraphs follows a horizontal split according to a level label, and not on a vertical; and

the label classification model causes the processor to label each class node, wherein the label for each class node is selectable from the hierarchical group comprising “basic service layer”, “composite service layer”, and “controller layer”.

9. The system ofclaim 8, wherein the processor is configured to, for the mapping, traverse a source file, and, based on the traversal:

designate identified classes and methods as respective vertices of the directed graph; and

designate an include relationship between classes and methods to connect them;

designate an implements relationship between classes and interfaces; and

designate an extends relationship between classes.

10. The system ofclaim 8, wherein the processor is configured to, for the providing of the detailing:

generate a recommendation for the micro services application split;

communicate the recommendation to developers via a network interface; and

modify the source code using the micro service application split to enable a generation of the micro service application from the source code.

11. A computer program product, the computer program product comprising:

one or more computer readable storage media; and

program instructions collectively stored on the one or more computer readable storage media, the program instructions configured to, when run on a processor:

receive source code for the monolithic application;

map the source code into a directed graph;

split the graph into subgraphs and optimizing the subgraph;

provide the detailing of the micro service application split, based on the subgraphs; and

perform multiple iterations to optimize a subgraph of the subgraphs, wherein:

the split of the graph further comprises the processor being configured to utilize a discovery algorithm and a label classification model for the split of the directed graph into the subgraphs;

the iterative optimization comprises the processor being configured to verify each iterative result based on predefined constraints;

the predefined constraints comprise:

different sub graphs can only be called one-way and not in a loop; and

a division of subgraphs follows a horizontal split according to a level label, and not on a vertical; and

the label classification model causes the processor to label each class node, wherein the label for each class node is selectable from the hierarchical group comprising “basic service layer”, “composite service layer”, and “controller layer”.

Images