Generally, the invention relates to software applications. More specifically, the invention relates to method and system for providing recommendations on deployment of a monolith application.
BACKGROUND
[002] Today, to be competitive in business, data should be processed and analytical decision making or other similar operations should be performed on right time, at right platform and place (for example, near site or on cloud), and in right environment. A decision on “what needs to be processed where?” may be taken based on nature of the business, criticality of information availability, and nature of a use case to be addressed. Further, advancement of Cloud/Edge computing makes data processing and decision making distributable, collaborative, and multi-layered with respect to time and space. Hence, nature of the application, business requirement, and characteristics of cloud/edge may be considered for suitable decoding and migration while transforming an existing monolith application for new business needs. Today various systems are available which may follow some approaches for application explorations and identify functionalities. However, the existing systems lack in providing recommendation on deployment of monolith application.
[003] Therefore, there is a need to develop a device which may help to decouple monolithic applications and provide recommendations for Cloud/Edge/On-premises migration.
SUMMARY OF INVENTION
[004] In one embodiment, a method for providing recommendations on deployment of a monolith application is disclosed. The method may include identifying a plurality of functionalities decomposable as microservices by performing a multidimensional analysis on the monolith application. The method may further include evaluating each of the plurality of functionalities based on a type of the monolith application. The method may further include determining a logical fitment value corresponding to each of a plurality of parameters with respect to each of a plurality of deployment options based on evaluation, for each of the plurality of functionalities. The method may further include determining a compliance level against each of the plurality of parameters for each of the plurality of functionalities. The method may further include determining an actual fitment value corresponding to each of the plurality of parameters with respect to each of the plurality of deployment options based on the compliance level and the logical fitment value for each of the plurality of functionalities. The method may further include identifying an appropriate deployment option based on actual fitment values of the plurality of functionalities to provide recommendations for deployment of the monolith application.
[005] In another embodiment, a system for providing recommendations on deployment of a monolith application is disclosed. The system may include a processor and a memory communicatively coupled to the processor. The memory may store processor-executable instructions, which, on execution, may cause the processor to identify a plurality of functionalities decomposable as microservices by performing a multidimensional analysis on the monolith application. The processor-executable instructions, on execution, may further cause the processor to evaluate each of the plurality of functionalities based on a type of the monolith application. The processor-executable instructions, on execution, may further cause the processor to determine a logical fitment value corresponding to each of a plurality of parameters with respect to each of a plurality of deployment options based on evaluation, for each of the plurality of functionalities. The processor-executable instructions, on execution, may further cause the processor to determine a compliance level against each of the plurality of parameters for each of the plurality of functionalities. The processor-executable instructions, on execution, may further cause the processor to determine an actual fitment value corresponding to each of the plurality of parameters with respect to each of the plurality of deployment options based on the compliance level and the logical fitment value, for each of the plurality of functionalities. The processor-executable instructions, on execution, may further cause the processor to identify an appropriate deployment option based on actual fitment values of the plurality of functionalities to provide recommendations for deployment of the monolith application.
[006] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[007] The present application can be best understood by reference to the following description taken in conjunction with the accompanying drawing figures, in which like parts may be referred to by like numerals
[008] FIG. 1 is a functional block diagram of various modules within a recommendation device configured for providing recommendations on deployment of a monolith application, in accordance with an embodiment.
[009] FIG. 2 is a flowchart of a method for providing recommendations on deployment of a monolith application, in accordance with an embodiment.
[010] FIG. 3 is a flowchart of a method for generating clusters of transactions from a functionality, in accordance with an embodiment.
[011] FIGS. 4A and 4B are exemplary tables representing a multi-parameter deployment fitment matrix and evaluated functionalities respectively, in accordance with an embodiment.
[012] FIGS. 5A, 5B, and 5C are exemplary logical fitment tables corresponding to various functionalities, in accordance with an embodiment.
[013] FIG. 6 is an exemplary table representing compliance levels for various functionalities, in accordance with an embodiment.
[014] FIGs. 7A, 7B, and 7C are exemplary actual fitment tables corresponding to various functionalities, in accordance with an embodiment.
[015] FIG. 8A is an exemplary table representing transaction level analysis against various parameters, in accordance with an embodiment.
[016] FIG. 8B is an exemplary deployment fitment table, in accordance with an embodiment.
[017] FIG. 8C is an exemplary system for deployment driven transaction deflection, in accordance with an embodiment.
[018] FIG. 9 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS
[019] The following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of particular applications and their requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that the invention might be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail. Thus, the invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
[020] While the invention is described in terms of particular examples and illustrative figures, those of ordinary skill in the art will recognize that the invention is not limited to the examples or figures described. Those skilled in the art will recognize that the operations of the various embodiments may be implemented using hardware, software, firmware, or combinations thereof, as appropriate. For example, some processes can be carried out using processors or other digital circuitry under the control of software, firmware, or hard-wired logic. (The term “logic” herein refers to fixed hardware, programmable logic and/or an appropriate combination thereof, as would be recognized by one skilled in the art to carry out the recited functions.) Software and firmware can be stored on computer-readable storage media. Some other processes can be implemented using analog circuitry, as is well known to one of ordinary skill in the art. Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention.
[021] Referring now to FIG. 1, a functional block diagram of various modules within a recommendation device 100 configured for providing recommendations on deployment of a monolith application 102 is illustrated, in accordance with an embodiment. The recommendation device 100 may analyze decomposable functionalities associated with the monolith application 102 independently and collectively to decide an appropriate deployment option and deployment model. For example, deployment options may include, but are not limited to, on-cloud deployment, edge deployment, and retain on on-premises. Further, in some embodiments, the recommendation device 100 may further divide the functionalities and deploy them based on nature of data processing requirements and business reasons. The recommendation device 100 may include functionality analyzer module 104, a functionality evaluation module 106, a logical fitment determination module 108, a compliance level determination module 110, an actual fitment determination module 112, and a recommendation generating module 114. Further, the recommendation device 100 may also include a data store to store various information and intermediate results generated by the modules 104-114. By way of an example, the modules 104-114 may perform various operations in order to provide recommendations on deployment of the monolith application 102.
[022] The functionality analyzer module 104 may be configured to perform a multidimensional analysis on the monolith application 102. Further, in some embodiments, based on the analysis performed on the monolith application 102, a plurality of functionalities that are decomposable as microservices may be identified by the functionality analyzer module 104. In other words, a multi-dimensional analysis may be performed on the monolith application 102 to identify functionalities which may be decomposable as independent microservices and functionalities which may be retained as monolith itself. Further, the multidimensional analysis may include, but is not limited to, a complexity analysis, a dependency analysis, a functional analysis, a usage analysis, and a business analysis. The functionality analyzer module 104 may be communicatively coupled to the functionality evaluation module 106.
[023] The functionality evaluation module 106 may be configured to evaluate each of the plurality of functionalities. In some embodiments, the evaluation may be performed based on a type of monolith application. In other words, each of the plurality of functionalities may be evaluated based on a plurality of parameters with respect to the expectation for business requirement and associate weightage defined by application nature. The plurality of parameters may include, but are not limited to, a response time requirement, a process intensiveness, a data requirement, a persistence storage requirement, a context sensitivity requirement, a historical data dependency, and an external dependency. Further, the plurality of parameters may vary from one application to other application. In some embodiments, the functionality evaluation module 106 may create fitment matrix by determining weightage of each of the plurality of parameters corresponding to each of the plurality of deployment options for each of the plurality of functionalities of the monolith application. Further, the functionality evaluation module 106 may be operatively coupled to the logical fitment determination module 108.
[024] The logical fitment determination module 108 may be configured determine a logical fitment value. It should be noted that the logical fitment value is determined for each of the plurality of functionalities. The logical fitment value may be determined corresponding to each of the plurality of parameters with respect to each of a plurality of deployment options based on the evaluation. Further, the logical fitment module 108 may be operatively coupled to the compliance level determination module 110.
[025] The compliance level determination module 110 may be configured to determine a compliance level against each of the plurality of parameters for each of the plurality of functionalities. Further, the compliance level determination module 110 may transmit compliance levels corresponding to the plurality of functionalities to the connected actual fitment determination module 112. The actual fitment determination module may be configured to determine an actual fitment value corresponding to each of the plurality of parameters with respect to each of the plurality of deployment options based on the compliance level and the logical fitment value for each of the plurality of functionalities.
[026] The recommendation generating module 114 may be configured for providing recommendations for deployment of the monolith application. In some embodiments, the recommendation module may employ an identification module (not shown in FIG. 1). In particular, the identification module may identify an appropriate deployment option based on actual fitment values of the plurality of functionalities, which may be provided as recommendation by the recommendation module 114. It should be noted that the plurality of deployment options are assigned with a plurality of categories based on the weightage of the plurality of parameters corresponding to the plurality of deployment options. The plurality of categories represents level of criticality. The plurality of categories may include a medium type, a high type, a low type, and a not applicable type.
[027] Further, the recommendation device 100 may also include a splitting module (not shown in FIG. 1) for splitting a functionality further into a plurality of transactions when an actual fitment value of the functionality is out of a predefined threshold range. Further, the plurality of transactions may be analysed by a transaction analyser module (not shown in FIG. 1) to analyse each of the plurality of transactions against the plurality of parameters. Further, clusters of two or more of the plurality of transactions may be generated based on the analysis by a clustering module (not shown in FIG. 1) of the recommendation device 100.
[028] It should be noted that the recommendation device 100 may be implemented in programmable hardware devices such as programmable gate arrays, programmable array logic, programmable logic devices, or the like. Alternatively, the recommendation device 100 may be implemented in software for execution by various types of processors. An identified engine/module of executable code may, for instance, include one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, module, procedure, function, or other construct. Nevertheless, the executables of an identified engine/module need not be physically located together but may include disparate instructions stored in different locations which, when joined logically together, comprise the identified engine/module and achieve the stated purpose of the identified engine/module. Indeed, an engine or a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[029] As will be appreciated by one skilled in the art, a variety of processes may be employed to the recommendation device 100. For example, the recommendation device 100 may provide recommendation on deployment of monolith application, by the process discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the recommendation device 100 either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by a processor of the recommendation device 100 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some, or all the processes described herein may be included in the processor of the recommendation device 100.
[030] Referring now to FIG. 2, a method for providing recommendations on deployment of a monolith application is depicted via a flowchart 200, in accordance with an embodiment. Each step of the method may be executed by the modules 104-114 of the recommendation providing device 100. FIG. 2 is explained in conjunction with FIG. 1.
[031] At step 202, a plurality of functionalities that are decomposable as microservices may be identified. The identification may be performed by performing a multidimensional analysis on the monolith application. The multidimensional analysis may include one or more of a complexity analysis, a dependency analysis, a functional analysis, a usage analysis, and a business analysis. It should be noted that the functionality analyzer module 104 may be responsible for performing this step.
[032] Further, at step 204, each of the plurality of functionalities may be evaluated. It should be noted that a type of the monolith application may be a consideration for evaluation. Also, it should be noted that the functionality evaluation module 106 may execute this step. Further, in some embodiments, a fitment matrix may be created by determining weightage of each of a plurality of parameters corresponding to each of a plurality of deployment options for each of the plurality of functionalities of the monolith application. For example, for a functionality the plurality of parameters may include a response time requirement, a process intensiveness, a data requirement, a persistence storage requirement, a context sensitivity requirement, a historical data dependency, and an external dependency. The plurality of deployment options may include an edge fitment option, a cloud fitment option, and an on-premises fitment option.
[033] Further, the plurality of deployment options may be assigned with a plurality of categories based on the weightage of the plurality of parameters corresponding to the plurality of deployment options. A category may represent level of criticality that may include, but is not limited to, a medium type, a high type, a low type, and a not applicable type.
[034] At step 206, a logical fitment value corresponding to each of the plurality of parameters may be determined with respect to each of the plurality of deployment options based on evaluation. It should be noted that the logical fitment value may be determined for each of the plurality of functionalities. To perform this step, the logical fitment determination module 108 may be employed.
[035] After that, at step 208, a compliance level may be determined using the compliance level determination module 110. The compliance level may be determined against each of the plurality of parameters for each of the plurality of functionalities. At step 210, an actual fitment value corresponding to each of the plurality of parameters with respect to each of the plurality of deployment options may be determined. The actual fitment determination module 112 may be used to perform this step. The actual fitment value may be determined for each of the plurality of functionalities.
[036] At step 212, an appropriate deployment option may be identified using the identification module of the recommendation module 114. Further, it should be noted that the appropriate deployment option may be identified based on actual fitment values of the plurality of functionalities in order to provide recommendations, using the recommendation module 114, for deployment of the monolith application.
[037] Referring now to FIG. 3, a method for generating clusters of transactions from a functionality is depicted via a flowchart 300, in accordance with an embodiment. FIG. 3 is explained in conjunction with Figs 1-2. At step 302, a functionality may be split into a plurality of transactions using the splitting module of the recommendation device 100. In some embodiments, an actual fitment value of the functionality may be checked. If the actual fitment value of the functionality is out of a predefined threshold range, then functionality may be split into the plurality of transactions for further analysis.
[038] Thereafter, at step 304, each of the plurality of transactions may be analyzed against the plurality of parameters. It should be noted that transaction analyzer module may be used to perform this step. At step 306, two or more of the plurality of transactions may be clustered based on the analysis using the clustering module of the recommendation device as explained in FIG. 1.
[039] Referring now to Figs 4A and 4B, tables 400A and 400B representing a multi-parameter deployment fitment matrix and evaluated functionalities are respectively illustrated, in accordance with an exemplary embodiment. Figs 4A and 4B are explained in conjunction with Figs 1-3. As illustrated in the table 400A, parameters 402 may include a response time requirement, a process intensiveness data requirement, a persistence storage requirement, context sensitivity requirements, a historical data dependency, and an external dependency (i.e., 402a to 402g). Further, the table 400A includes a plurality of deployment options including an edge fitment option 404, a cloud fitment option 406, and an on-premises fitment option 408. Each of the fitment options 404, 406, and 408 is assigned with one category from a high type, a low type, a medium type and a not applicable (NA) category. The table 400A may be created based on the market acceptance and further may be refined based on business requirements. In some embodiments, for example, on a scale of 5, a high category may be considered as 5, a medium category may be considered as 3, and a low category may be considered as 2, and NA category may be considered as 1.
[040] The table 400B includes a plurality of functionalities (for example, functionality 1 to functionality 6). Further, each functionality may be evaluated based on the parameters 402 with respect to the expectation for business requirement and associate weightage defined by application nature. As illustrated in FIG. 4B, each functionality is assigned with a value and a weight (wt) based on the parameters 402. For example, for the functionality 1, a value and a weight with respect to parameter P1 are ‘5’ and ‘9’, respectively. For the functionality 2, value and weight with respect to parameter P1 are ‘5’ and ‘3 respectively’. By way of an example, in a toll-plaza management system, for a functionality ‘Display board update’, a parameter ‘Response Time’ may have high weightage. However, in the same system, for a functionality ‘Fast Tag balance check functionality”, a parameter ‘Data accuracy’ may be more critical.
[041] Referring now to Figs 5A, 5B, and 5C, exemplary logical fitment tables 500A, 500B, and 500C corresponding to various functionalities are illustrated, in accordance with an exemplary embodiment. The table 500A corresponds to a functionality 1, the table 500B corresponds to a functionality 2, and the table 500C corresponds to a functionality 3. Figs 5A, 5B, and 5C are explained in conjunction with Figs 1-4. Each of the tables 500A, 500B, and 500C includes parameters P1 to P7 in rows and deployment options (for example, edge, cloud, and on-prem) in columns. A logical fitment value corresponding to each of a plurality of parameters with respect to each of a plurality of deployment options may be determined as per equation 1, given below:
Logical Fitment for Functionality K for parameter PM = Deployment fitment of PM * PM value of functionality K * PM weightage for functionality K… (1)
[042] By way of an example, consider that the parameter P1 (i.e., response time requirement) is critical for the functionality 1. Hence, based on the table 500A, it may be feasible to deploy the functionality F1 on edge side rather than deploying on other options. Further, consider that the parameter P2 (i.e., Process Intensiveness) is critical for the functionality 2. Hence, based on the table 500B, it may be feasible to deploy the functionality F2 on cloud side rather than deploying on other options. When the parameter P7 (i.e., External Dependency) is critical for the functionality 3. In that case, based on the table 500C, it may be feasible to deploy the functionality F3 on on-premises rather than deploying on other options.
[043] Referring now to FIG. 6, an exemplary table 600 representing compliance levels for various functionalities is illustrated, in accordance with an exemplary embodiment. FIG. 6 is explained in conjunction with FIGs. 1-3. For example, compliance levels for the functionality 1 corresponding to the parameters P1 to P7 are 70%, 40%, 75%, 20%, 10%, 20%, and 45% respectively. By way of an example, if the parameter P1 (i.e., response time) of the functionality F1 is expected to be less than 1ms, then the functionality F1 may be monitored to check adherence of the expectation for compliance level determination.
[044] Referring now to FIGs. 7A, 7B, and 7C, exemplary actual fitment tables 700A, 700B, and 700C corresponding to various functionalities are illustrated, in accordance with an exemplary embodiment. The table 700A corresponds to a functionality 1, the table 700B corresponds to a functionality 2, and the table 700C corresponds to a functionality 3. FIGs. 7A, 7B, and 7C are explained in conjunction with FIGs. 1-6. Actual fitment values of the functionalities are determined based on the corresponding compliance values. In an exemplary embodiment, the actual fitment value may be determined as per equation 2, given below:
Actual fitment for Functionality K for parameter PM = Logical fitment of PM * corresponding compliance value … (2)
[045] It should be noted that based on the actual fitment calculations the best suited deployment type for each functionality may be determined. Further, for example, the logical fitment value for the functionality 1 corresponding to deployment option ‘edge’ is ‘225’ (as illustrated in the table 500A) and the actual fitment value for the functionality 1 corresponding to the deployment option ‘edge’ is ‘168.75’. In this case, if a fitment threshold 80% (i.e., 200) is considered, then the functionality 1 may be considered for further granular level analysis, which may be explained further in conjunction with FIGs. 8A, 8B, and 8C.
[046] Referring now to FIG. 8A, an exemplary table 800A representing transaction level analysis against various parameters 802 is illustrated, in accordance with an exemplary embodiment. When the actual fitment of a functionality does not meet expected threshold of the business, the functionality may be further sub divided into multiple transactions (for example, transactions 804) and analyzed to see the transaction level fitment. The functionality may be decomposed to multiple transactions and each transaction may be analyzed against the parameters 802. By way of an example, for a ‘Fast Tag Processing’ functionality, logically it may be expected to be processed at the edge side as the processing time is very critical for end user. Further, the processing involves many back-end transactions as well. Therefore, the functionality may not be fully deployable on the edge side. It should be noted, in some embodiments, priority and order of the deployment may be predefined by corresponding businesses. For example, typically, deploy on edge if it feasible, otherwise on cloud. And, if cloud deployment is also not feasible then retain for On-premises.
[047] The typical transactions 804 may include a transaction ‘T1: Read fast tag details’, a transaction ‘T2: Send request to payment gateway’, a transaction ‘T3: Payment gateway transfer the amount to plaza management’, a transaction ‘T4: Send notifications to Plaza Management system’, a transaction ‘T5: Allow the vehicle to pass through, a transaction ‘T6: Send message to the vehicle owner’, a transaction ‘T7: Log all transactions’, and a transaction ‘T8: Save all camera/video evidence for the future use’. As illustrated in the table 800A, analysis results are scattered and may be difficult for selecting a deployment type. Therefore, a parameter driven analysis may be performed on the transactions 804 to group two or more transactions from the transactions 804 (i.e., T1 to T8).
[048] By way of an example, clusters of the transactions may be formed in such a way that a cluster 1 may include response critical transactions, a cluster 2 may include data sensitive transactions, a cluster 3 may include a data size and bandwidth sensitive transactions. Therefore, the cluster 1 may include T1 (i.e., read the fast tag details), T2-T4 (i.e., process the fast-tag), and T5 (i.e., allow the vehicle to passthrough). The cluster 2 may include T2 (i.e., send request to payment gateway), T3 (i.e., payment gateway transfer the amount to plaza management), T4 (i.e., send notifications to plaza management system), and T6 (i.e., send message to the vehicle owner). The cluster 3 may include T7 (i.e., Log all transactions), and T8 (i.e., save all camera/video evidence for the future use). This is further explained in detail in conjunction with FIG. 8C.
[049] The transactions T2 -T4 are associated with parameters including data critical, persistence storage, external dependency, and other parameters in addition to response time. Hence, the transactions T2-T4 may be further processed for transactions inter-dependency and decoupling analysis against transaction T5.
[050] Based on the inter-dependency and decoupling analysis, the transactions T2 – T4 may be split into two categories:
Category 1: Minimal data dependent that may improve the response time and deploy on ‘Edge’ side.
Category 2: Data dependent where response time is not critical and may be considered for ‘Cloud’ deployment.
[051] Further, redefined transactions for category 1 may include T2: A plaza manager sends request to payment gateway and T4: A payment gateway verifies the details and share approve/reject notifications to the plaza manager. The payment related transactions involve data and external dependencies and may be included in category 2. The transactions in the Category 2 may include ‘T2: Send request to payment gateway’, ‘T3: payment gateway transfer the amount to plaza management’, ‘T4: Send notifications to Plaza Management system’, ‘T6: Send message to the vehicle owner’. These transactions are not response critical as compared to transactions of category 1. Hence, the transactions of category 2 may be considered for cloud deployment. Another cluster 3 of transactions T7 and T8 is data size and bandwidth critical. Therefore, various data driven analysis may be performed further on the two transactions (T7 and T8) for deciding more suitable deployment option.
[052] Referring now to FIG. 8B, an exemplary deployment fitment table 800B is illustrated, in accordance with an exemplary embodiment. The table 800B includes a plurality of analysis 806-812 that may be performed on transactions (for example, for transactions T7 and T8). The table 800B may further include a plurality of deployment option (i.e., cloud, edge, and on-premises). In some embodiments, a data validation analysis may be performed on the transactions to check for delicacy, relevance, and clarity. Additionally, in some embodiments, a data sensitivity analysis 806 may be performed to decide if it permissible to persist, and permission to send through network. In some other embodiments, a data reusability level analysis 808 may be performed to check reusability expected in a day, reusability expected in a week, reusability expected beyond, or no reusability. Further, in some embodiments a data reusability scope analysis 810 may be performed to check if not reusable, reusable only on current context (for example, In current plaza), reusable on current region, reusable anywhere. Moreover, a data sizing-based storage/bandwidth cost analysis 812 may be performed to check another typical non-functional requirement.
[053] Further, in the table 800B, ‘N’ represents not feasible deployment option, ‘Y’ represents eligible deployment option, and ‘X’ represents eligible deployment option. With this analysis, the transactions T7 and T8 may be redefined based on a deployment driven analysis. The log/data/video with sensitive data may not be saved for further processing. Hence, deployment options may not be considered. On edge side, persist the data that is highly reusable and also the scope is in current context, for quicker processing. On cloud side, data that has future reusability and wider usage may be moved to cloud for persistence and processing. On-premises may be considered when processing is not feasible for the transactions either on edge or on cloud, because of reasons like Hard-coded dependencies.
[054] Referring now to FIG. 8C, an exemplary depiction 800C for deployment driven transaction deflection is illustrated, in accordance with an exemplary embodiment. The depiction 800C includes the plurality of transactions T1 to T8 generated from a functionality. Further, a plurality of parameter driven clusters may be formed. For example, a cluster 1 of transactions T1, T2-T4, T5, a cluster 2 of transactions T2, T3, T4, T6, a cluster 3 of transactions T7 and T8. Thereafter feasible options may be selected for deployment.
[055] In conclusion, a multi-level analysis may be performed on each of the functionalities for clustering and deployment selection, based on compliance need, business sensitively of data, and regulatory needs. Once the functionalities are independently analyzed and clustered, fine tuning for the decision may be performed collectively and at application level. Some parameters that may influence deployment on the cloud may include edge capacity constraints. For example, if more micro services are identified for edge deployment, which are beyond its capacity, then prioritization needs to be performed at application level. Further, inter functionalities/transactions affinity may be another parameter for which analysis may be performed for coupling and decoupling microservices. It should be noted that functionalities/transactions affinity may be performed to identify transactions/functions, which when moving together, may be beneficial. Further, a collective functionalities/transactions/data usage frequency may be a parameter for analysis. The parameters for analysis may also be redefined based on the nature of the functionality. For example, for the functionality with process intensive steps (for example, image processing/pattern matching etc,), parameters for analysis may be completely different. In some embodiments, a data versus process movement analysis may be performed to decide whether to move the data from edge to cloud for processing or or move the processing element from cloud to the edge side or to use a hybrid model thereof.
[056] The multi-level and recursive analysis explained in the present disclosure helps in decomposing a monolith application to manageable decomposed components and thus redefine the same in order to recommend the best fit deployment option for a particular business.
[057] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. Referring now to FIG. 9, an exemplary computing system 900 that may be employed to implement processing functionality for various embodiments (e.g., as a SIMD device, client device, server device, one or more processors, or the like) is illustrated. Those skilled in the relevant art will also recognize how to implement the invention using other computer systems or architectures. The computing system 900 may represent, for example, a user device such as a desktop, a laptop, a mobile phone, personal entertainment device, DVR, and so on, or any other type of special or general-purpose computing device as may be desirable or appropriate for a given application or environment. The computing system 900 may include one or more processors, such as a processor 902 that may be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, the processor 902 is connected to a bus 904 or other communication medium. In some embodiments, the processor 902 may be an Artificial Intelligence (AI) processor, which may be implemented as a Tensor Processing Unit (TPU), or a graphical processor unit, or a custom programmable solution Field-Programmable Gate Array (FPGA).
[058] The computing system 900 may also include a memory 906 (main memory), for example, Random Access Memory (RAM) or other dynamic memory, for storing information and instructions to be executed by the processor 902. The memory 906 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 902. The computing system 900 may likewise include a read only memory (“ROM”) or other static storage device coupled to bus 904 for storing static information and instructions for the processor 902.
[059] The computing system 900 may also include a storage device 908, which may include, for example, a media drives 910 and a removable storage interface. The media drive 910 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an SD card port, a USB port, a micro USB, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. A storage media 906 may include, for example, a hard disk, magnetic tape, flash drive, or other fixed or removable medium that is read by and written to by the media drive 920. As these examples illustrate, the storage media 912 may include a computer-readable storage medium having stored there in particular computer software or data.
[060] In alternative embodiments, the storage devices 908 may include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into the computing system 900. Such instrumentalities may include, for example, a removable storage unit 914 and a storage unit interface 916, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit 914 to the computing system 900.
[061] The computing system 900 may also include a communications interface 918. The communications interface 918 may be used to allow software and data to be transferred between the computing system 900 and external devices. Examples of the communications interface 818 may include a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a USB port, a micro USB port), Near field Communication (NFC), etc. Software and data transferred via the communications interface 918 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by the communications interface 918. These signals are provided to the communications interface 918 via a channel 920. The channel 920 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of the channel 920 may include a phone line, a cellular phone link, an RF link, a Bluetooth link, a network interface, a local or wide area network, and other communications channels.
[062] The computing system 900 may further include Input/Output (I/O) devices 922. Examples may include, but are not limited to a display, keypad, microphone, audio speakers, vibrating motor, LED lights, etc. The I/O devices 922 may receive input from a user and also display an output of the computation performed by the processor 902. In this document, the terms “computer program product” and “computer-readable medium” may be used generally to refer to media such as, for example, the memory 906, the storage devices 908, the removable storage unit 914, or signal(s) on the channel 920. These and other forms of computer-readable media may be involved in providing one or more sequences of one or more instructions to the processor 902 for execution. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 900 to perform features or functions of embodiments of the present invention.
[063] In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system 900 using, for example, the removable storage unit 914, the media drive 910 or the communications interface 918. The control logic (in this example, software instructions or computer program code), when executed by the processor 902, causes the processor 902 to perform the functions of the invention as described herein.
[064] Various embodiments provide method and system for providing recommendations on deployment of a monolith application. The disclosed method and system may help in taking decomposition decision of monolith applications, suggesting an approach for decomposition to micro services for prioritized functionalities, taking decision on what to host where and how to optimally meet business dynamics and at the same time stay competitive.
[065] It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[066] Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention.
[067] Furthermore, although individually listed, a plurality of means, elements or process steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.

CLAIMS

We Claim:

1. A method (200) for providing recommendations on deployment of a monolith application, the method (200) comprising:
identifying (202), by a recommendation device (100), a plurality of functionalities decomposable as microservices by performing a multidimensional analysis on the monolith application;
evaluating (204), by the recommendation device (100), each of the plurality of functionalities based on a type of the monolith application;
for each of the plurality of functionalities, by the recommendation device (100), determining (206) a logical fitment value corresponding to each of a plurality of parameters with respect to each of a plurality of deployment options based on evaluation;
determining (208), by the recommendation device (100), a compliance level against each of the plurality of parameters for each of the plurality of functionalities;
determining (210), by the recommendation device (100), for each of the plurality of functionalities, an actual fitment value corresponding to each of the plurality of parameters with respect to each of the plurality of deployment options based on the compliance level and the logical fitment value; and
identifying (212), by the recommendation device (100), an appropriate deployment option based on actual fitment values of the plurality of functionalities to provide recommendations for deployment of the monolith application.

2. The method (200) of claim 1, wherein the multidimensional analysis comprises one or more of a complexity analysis, a dependency analysis, a functional analysis, a usage analysis, and a business analysis.

3. The method (200) of claim 1, comprising creating a fitment matrix by determining weightage of each of the plurality of parameters corresponding to each of the plurality of deployment options for each of the plurality of functionalities of the monolith application.

4. The method (200) of claim 1, wherein the plurality of deployment options comprises an edge fitment option, a cloud fitment option, and an-on-premises fitment option, wherein the plurality of deployment options is assigned with a plurality of categories based on the weightage of the plurality of parameters corresponding to the plurality of deployment options, and wherein the plurality of categories comprises a medium type, a high type, a low type, and a not applicable type.

5. The method (200) of claim 1, wherein the plurality of parameters comprises a response time requirement, a process intensiveness, a data requirement, a persistence storage requirement, a context sensitivity requirement, a historical data dependency, and an external dependency.

6. The method (200) of claim 1, comprising:
splitting (302) a functionality into a plurality of transactions when an actual fitment value of the functionality is out of a predefined threshold range;
analysing (304) each of the plurality of transactions against the plurality of parameters; and
clustering (306) two or more of the plurality of transactions based on the analysis.

7. A system (900) for providing recommendations on deployment of a monolith application, the system (900) comprising:
a processor (902); and
a memory (906) communicatively coupled to the processor (902), wherein the memory (906) stores processor-executable instructions, which, on execution, causes the processor (902) to:
identify (202) a plurality of functionalities decomposable as microservices by performing a multidimensional analysis on the monolith application;
evaluate (204) each of the plurality of functionalities based on a type of the monolith application;
for each of the plurality of functionalities, determine (206) a logical fitment value corresponding to each of a plurality of parameters with respect to each of a plurality of deployment options based on evaluation;
determine (208) a compliance level against each of the plurality of parameters for each of the plurality of functionalities;
determine (210), for each of the plurality of functionalities, an actual fitment value corresponding to each of the plurality of parameters with respect to each of the plurality of deployment options based on the compliance level and the logical fitment value; and
identify (212) an appropriate deployment option based on actual fitment values of the plurality of functionalities to provide recommendations for deployment of the monolith application.

8. The system (900) of claim 7, wherein the processor-executable instructions cause the processor (902) to create a fitment matrix by determining weightage of each of the plurality of parameters corresponding to each of the plurality of deployment options for each of the plurality of functionalities of the monolith application.

9. The system (900) of claim 7, wherein the plurality of deployment options comprises an edge fitment option, a cloud fitment option, and an-on-premises fitment option, wherein the plurality of deployment options is assigned with a plurality of categories based on the weightage of the plurality of parameters corresponding to the plurality of deployment options, and wherein the plurality of categories comprises a medium type, a high type, a low type, and a not applicable type.

10. The system (900) of claim 7, wherein the processor-executable instructions cause the processor (902) to:
splitting (302) a functionality into a plurality of transactions when an actual fitment value of the functionality is out of a predefined threshold range;
analysing (304) each of the plurality of transactions against the plurality of parameters; and
clustering (306) two or more of the plurality of transactions based on the analysis.