WO2023065861A1

WO2023065861A1 - Application migration assessment

Info

Publication number: WO2023065861A1
Application number: PCT/CN2022/117163
Authority: WO
Inventors: Vishal Navnit PANDYA; Vineet Kumar MAHESHWARI
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2021-10-18
Filing date: 2022-09-06
Publication date: 2023-04-27
Anticipated expiration: 2024-04-18
Also published as: CN118103828A

Abstract

Approaches for assessing a migration of an application from a source database to a target database are described. An application, during runtime, may generate an application query. The application query may be directed to and executed on a source database, and may be intercepted. Once intercepted, the application query may then be extracted. Thereafter, the extracted application query may be directed to execute on a target database. The execution of the extracted application query on the target database may be assessed. Based on the assessment, a feasibility of migration of the application from the source database to the target database may then be determined.

Description

APPLICATION MIGRATION ASSESSMENT

BACKGROUND

Large volumes of data may be stored and utilized using databases. To this end, servers may host multiple applications, and the servers may use the data from the database to perform a number of functions. In certain instances, the databases may have to be migrated to different platform for either upgrading or expanding an existing platform. During database migration, applications may be migrated such that they may then communicate to a target database, as opposed to a source database. To affect the migration of the databases, a number of processes may have to be undertaken. Examples of such processes include, but are not limited to, schema conversion, data migration, followed by application migration.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description references the drawings, wherein:

FIG. 1 illustrates an application server and an assessment system within an example computing environment for assessing migration of an application from a source database to a target database, as per an implementation of the present subject matter;

FIG. 2 illustrates a block diagram of an assessment system for assessing migration of an application from a source database to a target database, as per an implementation of the present subject matter;

FIG. 3 illustrates a detailed block diagram of an example computing environment for assessing migration of an application from a source database to a target database, implementing an application server and an assessment system, as per an implementation of the present subject matter;

FIG. 4 is a flowchart of an example method to be implemented in an assessment system, as per an implementation of the present subject matter;

FIG. 5 is a flowchart of an example method to be implemented in an assessment system, as per another implementation of the present subject matter; and

FIG. 6 illustrates a non-transitory computer-readable medium for causing an application server to assess migration of an application from a source database to a target database, as per an implementation of the present subject matter.

Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the example shown. Moreover, the drawings provide examples and/or implementations consistent with the description; however, the description is not limited to the examples and/or implementations provided in the drawings.

DETAILED DESCRIPTION

Various organizations and enterprises generally use large volumes of data and records, which may be stored and utilized in the form of databases. The databases store the large volumes of data in a structured manner, and may allow the organization to efficiently manage, retrieve, and use the data. In such cases, multiple applications may be implemented and built around the database in a manner, so that the applications may use the data from the database to perform a number of functions. For example, an organization may process data and records such as employee details, compensation, incentives, leaves, etc., using various applications, such as a payroll application. Such applications may typically query the database for processing the data and implementing various functionalities. These applications may be designed in such a manner that they may use the data from the database as an input for one of the associated functionalities, and may store the output back into the database.

In certain instances, organizations may plan to migrate their existing databases onto a different database. For example, an organization may initially be using a source database, referred to source database ‘A’ , but may choose to migrate their applications to a target database ‘B’ , which in certain instances may be from a different vendor. Changing or migrating to a different database, a process which is referred to as database migration, may involve a variety of tasks, which include, but are not limited to schema conversion, data migration and application migration.

Schema conversion includes migration of structural information or a ‘blueprint’ of the source database. Such structural information provided in the schema of the source database defines how the database itself may be structured. Once the schema of the source database is ported to the target database, the target database will have the same logical structure as that of the source database. The scheme conversion may migrate the tables, objects, etc., of the source database to the target database, and may ensure that the structure of the source database works with the target database.

Once the schema is migrated, the data may need to be migrated from the source database to the target database. Once the data is moved to the target database, eventually the application migration may be performed. Application migration refers to processes or steps that are to be performed to enable the applications, say hosted on an application server, to communicate and execute queries on the target database instead of the source database.

To this end, certain configurational changes may have to be affected which will ensure that the applications may communicate with the target database, in a performant manner. Application migration may involve switching or reconfiguring applications, which were previously configured to communicate with the source database, to now communicate and operate with the target database, so that the applications may access and communicate with the target database seamlessly and efficiently. As may be noted, the applications which communicate with the source database may be specifically configured which allows the applications to communicate with and access the source database. Such configurations may govern execution mechanisms, operational settings, as well as communication protocols, based on which the applications may communicatively operate with the source database. The configuration may differ depending on the type of databases.

As a result, the same set of applications may have to be configured differently to enable communication with different databases. The configuration of the applications may be performed at the time when the entire database was, perhaps, being set up and may be implemented by way of application programming interface or drivers. Examples of these include, but are not limited to, Java Database Connectivity (JDBC) for Java-based applications. JDBC may include a set of interfaces and classes written in Java language, and may allow the Java-based applications to access the database.

Once configured, the applications may generate executable queries which when executed on the source database may communicate with the source database and may retrieve the appropriate data. The retrieved data in turn, may be used for implementing different functionalities by the applications.

During application migration, certain executable queries that may be used for accessing the source database, may have to be reconfigured so that they may be executed on the target database. Such configurational changes may be performed to enable the applications to communicate with and access the target database.

Existing approaches of migrating queries during application migration are cumbersome and inefficient, and largely depend on manual evaluation and examination to determine what configurational changes may need to be affected. Since the underlying applications cannot be changed, certain changes may involve converting queries which may not be compatible (i.e., executable on the target database) .

For example, during application migration, an administrator may initially attempt to execute a number of queries (generated by the applications) on the target database. The execution of the queries may have to be manually reviewed (e.g., by reviewing or examining log files, registries, or such) to determine whether the application queries would be compatible with the target database. Compatibility may be ascertained by determining whether a subject query executed in an expected manner on a given database. If the query executed successfully, the query may be considered as being compatible with the given database. Conversely, if the query failed to execute on the given database, it may be concluded that the query was not compatible. Accordingly, it may be possible to ascertain which of the queries are likely to be compatible with or executable on the target database, and which of the queries are not likely to be compatible with or executable on the target database.

The queries that may be compatible with the target database may be allowed or implemented without any restriction when the applications are migrated. However, the queries that may have failed to execute on the target database may need to be altered thereafter. Accordingly, the queries which were determined to be incompatible may have to be converted such that the applications may operate in a performant manner with the target database.

Furthermore, it may also be the case that the administrator may have to eventually choose a certain target database from amongst multiple databases. It may be possible that one database may take comparatively less amount of execution time to execute the queries but may involve additional costs, while another database may utilize comparatively less computational resources. In such cases, the conventional and existing approaches of migrating queries from the source database to the target database may also be inefficient in comparing the performance of the different databases.

Approaches for assessing migration of an application from a source database to a target database are described. The application migration may be a part of the database migration process. The approaches of the present subject matter may assess the migration of the applications from the source database to the target database, and may provide a feasibility of migrating from the source database to the target database.

In one example, the application may be accessing the source database. Examples of such application may include, but are not limited to a Java-based application, Python-based application, and . NET-based application. However, it may be noted that such examples of the application are only illustrative, and should not be construed to limit the scope of the subject matter in any manner. Any other platform-based application may also be accessing and executing on the source database and may be migrated to the target database without deviating from the scope of the present subject matter.

Continuing with the present example, during runtime, the application may generate an application query, which may be directed to and executed on the source database. The application query, when generated, may be intercepted. In an example, interception may be affected by intercepting one or more system calls through an application driver that may be invoked in response to the generation of the application query. In another example, an application byte code, generated upon execution of the application query, may be intercepted by executable agents through various Application Programming Interfaces (APIs) corresponding to the application and the source database. However, any other techniques for intercepting the application query known to a person skilled in the art may also be used without deviating from the scope of the present subject matter.

Continuing with the present example, the application query, once intercepted, may then be extracted. Thereafter, the extracted application query may be directed to and executed on the target database. In one example, in the case of interception of one or more system calls, the intercepted system calls may be then be directed through the application driver to the target database. In another example, in the case of interception of the application byte code corresponding to the application query, the intercepted application byte code may be modified to direct the corresponding application query to and execute on the target database.

Thereafter, the execution of the extracted application query on the target database may then be assessed. Based on the assessment, a feasibility of migration of the application from the source database to the target database may be determined. In one example, the assessment may be performed based on a ratio of a number of queries that successfully executed on the target database to a number of queries that failed while executing on the target database. To this end, queries which executed successfully on the target database may be considered as being compatible, while queries which failed to execute may be considered as incompatible queries. Based on the ratio of the number of compatible queries to the number of incompatible queries, a compatibility parameter may be determined.

Depending on the compatibility parameter, an assessment may be made as to the feasibility of migrating the applications from the source database to the target database. For example, if the compatibility parameter is greater than a threshold, the migration of the application from the source database to the target database may be determined to be feasible. On the other hand, if the compatibility parameter is lower than the compatibility threshold, the migration may be determined to be non-feasible.

In another example, in addition to determining whether the application queries are compatible with the target database, an accuracy of the query results may also be assessed to determine the feasibility of migrating to the target database. For example, the result obtained by execution of the application queries on the target database, referred to as target result, may be compared with the result obtained by execution of the same set of queries on the source database, referred to as source result. The source result and the target result may be compared, and based on their comparison, the feasibility of migrating the applications from the source database to the target database may be determined. If the accuracy of the results obtained by executing queries on the target database is greater than an accuracy threshold value, the target database may be concluded as being feasible.

In yet another example, operational parameters of the target database may also be determined to assess and ascertain the feasibility of migrating the applications from the source database to the target database. For example, various operational parameters may be determined while the queries are being executed on the target database. These operational parameters may then be compared with the result of execution of the same set of queries on the source database. In an example, the time taken for queries, amount of computational resources utilized may be assessed to determine the feasibility of migrating to the target database.

As would be appreciated, the execution of the application queries on the target database may be done in a test environment, so as to replicate the manner in which the applications and their corresponding application queries will execute while executing on the target database. As a result, the approaches of the present subject matter may allow the application queries to be executed on the target database automatically in the background, thereby eliminating the manual effort required to individually assess the compatibility of each of the application queries while migrating from the source database to the target database.

The present subject matter is further described with reference to the accompanying figures. Wherever possible, the same reference numerals are used in the figures and the following description to refer to the same or similar parts. It should be noted that the description and figures merely illustrate principles of the present subject matter. It is thus understood that various arrangements may be devised that, although not explicitly described or shown herein, encompass the principles of the present subject matter. Moreover, all statements herein reciting principles, aspects, and examples of the present subject matter, as well as specific examples thereof, are intended to encompass equivalents thereof.

The manner in which the example computing devices are implemented are explained in detail with respect to FIGS. 1-6. While aspects of described computing devices can be implemented in any number of different electronic devices, environments, and/or implementations, the examples are described in the context of the following example system (s) . It is to be noted that drawings of the present subject matter shown here are for illustrative purposes and are not to be construed as limiting the scope of the subject matter claimed.

FIG. 1 illustrates a computing environment 100 with an application server 102 and an assessment system 104 for assessing a migration of an application from a source database to a target database, as per an implementation of the present subject matter. In one example, the application server 102 may be any hardware-based, software-based, or network-based server operating on a network. In another example, the application server 102 may be any computing device such as a Personal Computer (PC) , Laptop, mobile device, etc., capable of receiving, processing, and transmitting any data.

In another example, the assessment system 104 may be any computing device similar to, or different from the application server 102. The assessment system 104 may further include an assessment module 106. Although, the assessment module 106 has been depicted within the assessment system 104 in FIG. 1, it may be implemented within the application server 102 without deviating from the scope of the present subject matter in any manner.

Continuing with the present example, as depicted in FIG. 1, a plurality of application (s) 108-1, 108-2, …, 108-N, collectively referred to as applications 108, may be operating on the application server 102. Examples of such applications 108 may include, but are not limited to, Java-based applications, Python-based applications, and . NET-based applications. However, it may be noted that such examples of the applications 108 are only illustrative, and should not be construed to limit the scope of the subject matter in any manner. Any other platform-based applications may also be operating on the application server 102 without deviating from the scope of the present subject matter.

Such applications 108, during runtime, may generate a plurality of application queries 110 directed to and executed on a source database 112. As a result, the source database 112 may be accessed and processed through the execution of such application queries 110. In one example, the application queries 110 may be a set of SQL queries, that may be directed to and executed on the source database 112.

In operation, the applications 108, during database migration, may undergo migration. As a part of the application migration, the applications 108 may be configured to communicate and execute queries on a target database 114 instead of the source database 112. As described previously, the application 108, during runtime, may generate the application query 110 which may be directed to and executed on the source database 112.

Although the present example has been explained with respect to an application 108 generating an application query 110, it may be noted that the same is done only for the sake of clarity and explanation. Any number of applications 108 may be generating multiple application queries 110, to access the source database 112. The present subject matter may allow assessment of migration of any number of applications 108 from a source database to a target database, without deviating from the scope of the present subject matter.

Continuing with the present example, the assessment module 106 may initially intercept the application query 110 during runtime. Once intercepted, the assessment module 106 may extract the application query 110. Thereafter, the assessment module 106 may direct the extracted application query 110 to be executed on a target database 114. Thereafter, the assessment module 106 may assess the execution of the extracted application query 110 on the target database 114. Based on the assessment, the assessment module 106 may determine a feasibility of migration of the application 108 from the source database 112 to the target database 114.

In one example, the assessment module 106 may perform the assessment based on a ratio of a number of queries 110 that successfully executed on the target database 114, to a number of queries 110 that failed while executing on the target database 114. As described previously, queries which failed to execute may be considered as queries which are incompatible with the target database 114, while queries which successfully execute may be considered as queries which were compatible with the target database 114. Based on the ratio of the number of compatible queries to the number of incompatible queries, the assessment module 106 may determine a compatibility parameter, based on which, may assess the feasibility of migrating the applications 108 from the source database 112 to the target database 114.

For example, if the compatibility parameter is greater than a compatibility threshold, the migration of the application 108 from the source database 112 to the target database 114 may be determined to be feasible. On the other hand, if the compatibility parameter is lower than the compatibility threshold, the migration may be determined to be non-feasible.

In another example, the assessment module 106 may also assess an accuracy of the query results to determine the feasibility of migrating to the target database 114. For example, the result obtained by execution of the application queries 110 on the target database 114, referred to as target result, may be compared with the result obtained by execution of the same set of queries 110 on the source database 112, referred to as source result. The source result and the target result may be compared, and based on the comparison, the feasibility of migrating the application 108 from the source database 112 to the target database 114 may be determined. In such a case, if the comparison reveals that the target results match the source result, it may be ascertained that the results obtained from the target database 114 are accurate and hence conclude, that it may be feasible for migrating the source database 112 to the target database 114. For example, if a comparison score generated by comparing the target result with the source result is greater than a comparison threshold, the migration may be determined to be feasible. On the other hand, if the comparison score is less than the comparison threshold, the migration may be determined to be non-feasible.

The assessment module 106 may further ascertain based on one or more operational parameters of the target database 114, whether it would be feasible for migrating to the target database 114. For example, various operational parameters may be determined while the queries 110 are being executed on the target database 114. These operational parameters may then be compared with values of corresponding parameters based on execution of the same set of queries 110 on the source database 112. In an example, the time taken for queries, amount of computational resources utilized, or other such operational parameters may be considered for determining the feasibility of migrating to the target database 114.

It may be noted that the above examples are provided for sake of explanation only, and that the same are not be used for limiting the subject matter in any manner. Certain steps and functions may be implemented differently without deviating from the scope of the present subject matter. Certain such examples are explained further in conjunction with other figures. For example, the manner in which the assessment system 104 assesses migration of the application 108 from the source database 112 to the target database 114 is described in further detail in conjunction with FIGS. 2-6.

FIG. 2 is a block diagram of an assessment system 104 for assessing migration of an application from a source database to a target database, as per an implementation of the present subject matter. The assessment system 104 may be implemented as any hardware-based, software-based, or network-based computing device for assessing the migration of an application from a source database to a target database.

Continuing with the present implementation, the assessment system 104 may include a processor (s) 202, a memory 204, and an interface (s) 206. The processor (s) 202 may be implemented as signal processor (s) , state machine (s) , logic circuitries, and/or any other device or component that manipulate signals based on operational instructions.

The memory 204 may store one or more computer-readable instructions. The memory 204 may include any non-transitory computer-readable medium including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like. The interface (s) 206 may include a variety of interfaces, for example, interface for data input and output devices, referred to as I/O devices, storage devices, network devices, and the like, for communicatively associating the assessment system 104 with other entities in the computing environment 100 as described in FIG. 1.

The assessment system 104 may further include module (s) 208 and data 210. The module (s) 208 may be implemented as a combination of hardware and programming logic (e.g., programmable instructions) to implement one or more functionalities of the assessment system 104. In one example, the module (s) 208 may include the assessment module 106, application byte code 212, and other module (s) 214. The data 210 on the other hand includes application query 216, compatible queries 218, incompatible queries 220, compatibility parameter 222, compatibility threshold 224, source result 226, target result 228, comparison score 230, comparison threshold 232, and other data 234. Further, the other data 234, amongst other things, may serve as a repository for storing data that is processed, or received, or generated as a result of the execution of one or more modules in the module (s) 208.

In examples described herein, such combinations of hardware and programming may be implemented in a number of different ways. For example, the programming for the module (s) 208 may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the module (s) 208 may include a processing resource (e.g., one or more processors) , to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement module (s) 208 or their associated functionalities.

As described previously, an application, such as application 108 as described in FIG. 1, may be operating on an application server, such as application server 102 as described in FIG. 1. Examples of such application 108 may include, but are not limited to a Java-based application, Python-based application, and . NET-based application. However, it may be noted that such examples of the application 108 are only illustrative, and should not be construed to limit the scope of the subject matter in any manner. Any other platform-based application 108 may be migrated from a source database to a target database without deviating from the scope of the present subject matter.

Such application 108, during runtime, may generate an application query 216 directed to and executed on a source database, such as source database 112 as depicted in FIG. 1. As a result, the source database 112 may be accessed and processed through the execution of such application query 216. In one example, the application query 216 may be a SQL query, that may be directed to and executed on the source database 112.

In operation, the assessment module 106 may intercept the application query 216 during runtime. In an example, the interception of the application query 216 may be affected by intercepting one or more system calls, say through an application driver (not depicted in FIG. 2) , that may be invoked in response to the generation of the application query 216. However, it may be noted that any other application driver corresponding to the application 108 and the source database 112 may be used without deviating from the scope of the present subject matter. In the case of a Java-based application 108, the application query 216, upon generation, may invoke a plurality of system calls through application driver such as Java Database Connectivity (JDBC) .

In another example, an application byte code 212, generated upon execution of the application query 220, may be executed by executable agents through various Application Programming Interfaces (APIs) . In the case of a Java-based application 108, the application byte code 212 may be generated upon compilation of the application query 216 during runtime on a Java Virtual Machine (JVM) . Thereafter, the application byte code 212 may be intercepted by a dedicated java file, such as ‘java agent’ through Java Instrumentation API. However, any other techniques for intercepting the application query 216 known to a person skilled in the art may also be used without deviating from the scope of the present subject matter.

Continuing with the present example, once intercepted, the assessment module 106 may extract the application query 216 and store the same within the assessment system 104. Thereafter, the assessment module 106 may direct the extracted application query 216 to be executed on a target database, such as target database 114, as depicted in FIG. 1.

In one example, in the case of interception of one or more system calls, the assessment module 106 may direct the intercepted system calls through the application driver to be executed on the target database 114. In another example, in the case of interception of the application byte code 212 corresponding to the application query 216, the intercepted application byte code 212 may be modified to direct the corresponding application query 216 to execute on the target database 114.

Continuing with the present example, the assessment module 106 may assess the execution of the extracted application query 216 on the target database 114. Based on the assessment, the assessment module 106 may determine a feasibility of migration of the application 108 from the source database 112 to the target database 114. Such an assessment may be performed on multiple basis.

For example, the assessment may be made based on compatibility of queries, operational parameters and based on one or more operational parameters pertaining to the target database 114. Examples of such operational parameters may include, but are not limited to, computational performance of the target database 114 in executing the queries, accuracy of the results obtained, costs, and such. It may be noted that multiple other such operational parameters may be utilized as a basis for assessing the feasibility of migrating to the target database 114. These and other aspects are now further explained in conjunction with the following examples.

In one example, the assessment may be performed based on a ratio of the application queries 216 that successfully executed on the target database 114 to a number of application queries 216 that failed while executing on the target database 114. To this end, queries 216 which executed successfully on the target database 114 may be considered as being compatible queries 218, while queries 216 which failed to execute may be considered as incompatible queries 220. Based on the ratio of the number of compatible queries 218 to the number of incompatible queries 220, the assessment module 106 may ascertain a degree to which the application queries 216 are compatible. In an example, the assessment module 106 may quantify the extent of compatibility using a compatibility parameter 222. The compatibility parameter 222 may be based on the number of queries 216 which were determined to be incompatible and the number of queries 216 that were determined. In an example, the compatibility parameter 222 may be determined based on a ratio of the compatible queries 218 and the incompatible queries 220.

Based on the compatibility parameter 222, the assessment module 106 may assess the feasibility of migrating the applications 108 from the source database 112 to the target database 114. For example, if the compatibility parameter 222 is greater than a compatibility threshold 224, the migration of the application 108 from the source database 112 to the target database 114 may be determined to be feasible. On the other hand, if the compatibility parameter 222 is lower than the compatibility threshold 224, the migration may be determined to be non-feasible. The compatibility threshold 224 may correspond to a maximum allowable limit of application queries 216 amongst the total queries 216 that may need to be migrated from the source database 112 to the target database 124, to be able to execute successfully on the target database 114.

As would be noted, determining the feasibility of migrating the applications 108 from the source database 112 to the target database 114 based on the compatibility parameter 222 may provide insights into a compatibility of the target database 114 based on the number of queries that will fail to execute while trying to migrate from the source database 112 to the target database 114. For example, it may be the case that an administrator, while performing application migration and migrating the applications 108 from the source database 112, may have various target databases to choose from. In such cases, the compatibility parameter 222 of each of the available target databases may be taken into consideration. The target database with the maximum compatibility parameter 222 may allow the maximum number of application queries 216 to be successfully migrated from the source database 112.

In another example, in addition to determining whether the application queries 216 are compatible with the target database 114, the assessment module 106 may also assess an accuracy of the query results to determine the feasibility of migrating the applications 108 from the source database 112 to the target database 114.

For example, the assessment module 106 may compare the result obtained by execution of the application queries 216 on the target database 114, referred to as target result 228, with the result obtained by execution of the same set of application queries 216 on the source database 112, referred to as source result 226. The assessment module 106 may compare the source result 226 and the target result 228, and based on the comparison, may determine the feasibility of migrating the applications 108 from the source database 112 to the target database 114. In such a case, if the comparison reveals that the target results match the source result, it may be ascertained that the results obtained from the target database 114 are accurate and hence conclude, that it may be feasible for migrating the source database 112 to the target database 114. For example, if a comparison score 230 generated by comparing the target result 228 with the source result 226 is greater than a comparison threshold 232, the assessment module 106 may determine the migration of the application 108 from the source database 112 to the target database 114 to be feasible. On the other hand, if the comparison score 230 is less than the comparison threshold 232, the assessment module 106 may determine the migration of the application 108 from the source database 112 to the target database 114 to be non-feasible. Such assessment may correspond to the accuracy of results of the application queries 216 that may need to be migrated from the source database 112 to the target database 114.

In yet another example, during assessment, in cases where all the application queries 216 executed successfully on the target database 114 and the value of the compatibility parameter 222 equals ‘1’ , and the target result 228 completely match the source result 226, the assessment module 106 may determine the target database 114 to be completely compatible for migrating the applications 108 from the source database 112. Such assessment may indicate that all the application queries 216 will be successfully executed and will provide accurate results while migrating to the target database 114. In such cases, while undergoing application migration, the administrator of the assessment system 104 may just need to modify the connection information in the configuration properties of the application 108 to point from the source database 112 to the target database 114. In the case of Java-based applications 108, the administrator may just need to modify the connection information in the Java-based code of the application queries 216 executing on the source database 112 to point to the target database 114.

In yet another example, the assessment module 106 may also assess one or more operational parameters of the target database 114 to assess and ascertain the feasibility of migrating the applications 108 from the source database 112 to the target database 114. One of such operational parameters include accuracy of the search results. To this end, the assessment module 106 may execute the application queries 216 on both the source database 112 and the target database 114. The results obtained as a result of executing the application queries 216 on the source database 112 (i.e., the source results 226) and the results obtained as a result of executing the application queries 216 on the target database 114 (i.e., the target result 228) may be obtained and analyzed. In an example, the assessment module 106 may compare the source results 226 and the target result 228 and determine a deviation therebetween. A comparison between the source results 226 and the target result 228 may then be used to assess as to how the target database 114 fares in terms of accuracy, when the application queries 216 are executed on it.

Besides accuracy, the feasibility may be assessed based on other operational parameters as well. For example, the assessment module 106 may monitor the computational performance of the queries 216 with respect to the target database 114 versus the performance of the queries 216 with respect to the source database 112. To this end, the assessment module 106 may monitor utilization of computational resources, e.g., CPU usage, memory utilization, and such, when the application queries 216 are executed on the source database 112. In a similar manner, the computational resource utilization may also be determined when the application queries 216 are executed on the target database 114. The respective performance outcomes may then be compared to determine how the computational performance of the application queries 216 executing on the source database 112 compares with the execution of the same set of application queries 216 on the target database 114. In an example, the variance between the source results 226 and the target result 228 may be determined based on different mathematical approaches, without deviating from the scope of the present subject matter.

For example, in a similar manner as described previously, the assessment module 106 may compare the source result 226 and the target result 228 to determine the comparison score 230. In the case of assessment of the feasibility based on accuracy of the execution of the application queries 216 on the target database 116, the comparison score 230 may correspond to the deviation of the accuracy of execution of the application queries 216 on the target database 114, from the accuracy of the execution of the same set of application queries 216 on the source database 112.

In the case of assessment of the feasibility based on performance of the target database 114, the comparison score 230 may correspond to the variance between the performance of application queries 216 on the target database 114 versus the performance of the same set of application queries on the source database 112.

As would be noted, it may also be the case that the administrator may compare the operational characteristics of various available target databases and may choose amongst the available target databases, the most suitable target database 114 based on the assessment to migrate the applications 108 from the source database 112.

The manner in which the assessment module 106 may assess the migration of applications 108 from the source database 112 to the target database 114, in the context of the interception from the application byte code 212, is described in further details in conjunction with FIG. 3.

FIG. 3 illustrates a computing environment 300 with an application server 302 and an assessment system 304 for assessing a migration of an application from a source database to a target database, as per an implementation of the present subject matter. In one example, the application server 302 and the assessment system 304 may be any hardware-based, software-based, or network-based servers operating on a network. In another example, the application server 302 and the assessment system 304 may be implemented as the application server 102 and the assessment system 104 respectively, as described in FIG. 1.

The assessment system 304 may further include an assessment module 306. Although, the assessment module 306 has been depicted within the assessment system 304, it may be implemented within the application server 302 without deviating from the scope of the present subject matter. In one example, the assessment module 306 may be implemented as the assessment module 106 as described in FIG. 1.

In operation, as described previously, a plurality of application (s) 308-1, 308-2, …, 308-N, collectively referred to as applications 308, may be operating on the application server 302. Examples of such application 308 may include, but are not limited to a Java-based application, Python-based application, and . NET-based application. However, it may be noted that such examples of the application 308 are only illustrative, and should not be construed to limit the scope of the subject matter in any manner. Any other platform-based application 308 may be migrated from a source database to a target database without deviating from the scope of the present subject matter.

Such application 308, during runtime, may generate an application query. An application byte code 310 may be generated upon compilation of the application query during runtime, depicted as step 312 in FIG. 3. In the case of a Java-based application 308, the application byte code 310 may be generated upon compilation of the application query on a Java Virtual Machine (JVM) . However, any other technique known to a person skilled in the art may also be used for generation of application byte code 310 by compiling the application query.

Continuing with the present example, the application query may be directed to and executed on the source database 314, depicted as step 316 in FIG. 3, and may allow the application 308 to access the source database 314. In one example, the application query may be a SQL query, that may be directed to and executed on the source database 314.

The assessment module 306 may then intercept the application query. In an example, as described in FIG. 3, the application byte code 310, generated upon execution of the application query, may be intercepted by executable agents, depicted as step 318 in FIG. 3, through various Application Programming Interfaces (APIs) . In the case of a Java-based application 308, the application byte code 310 may be intercepted by a dedicated java file, such as ‘java agent’ through Java Instrumentation API. However, any other techniques for intercepting the application query known to a person skilled in the art may also be used without deviating from the scope of the present subject matter.

Continuing with the present example, once intercepted, the assessment module 306 may extract the application query, depicted as step 320 in FIG. 3 and store the same within the assessment system 304. Thereafter, the assessment module 306 may direct the extracted application query to the target database 322, depicted as step 324 in FIG. 3.

Thereafter, the intercepted application byte code 310 corresponding to the extracted application query may then be modified, depicted as block 326 in FIG. 3. Thereafter, the modified application query, may then be directed to and executed on the target database 322, depicted as step 328 in FIG. 3.

Thereafter, the assessment module 306 may assess the execution of the extracted application query on the target database 322. Based on the assessment, the assessment module 306 may determine a feasibility of migration of the application 308 from the source database 314 to the target database 322.

In one example, the assessment module 306 may perform the assessment based on a ratio of a number of queries that successfully executed on the target database 322, to a number of queries that failed while executing on the target database 322. For example, if the ratio is greater than a threshold, the migration of the application 308 from the source database 314 to the target database 322 may be determined to be feasible. On the other hand, if the ratio is lower than the threshold, the migration may be determined to be non-feasible.

In another example, the assessment module 306 may also assess an accuracy of the query results to determine the feasibility of migrating to the target database 322. For example, the result obtained by execution of the application queries on the target database 322, referred to as target result 330, may be compared with the result obtained by execution of the same set of queries on the source database 314, referred to as source result 332. The source result 332 and the target result 330 may be compared, and based on the comparison, the feasibility of migrating the application 308 from the source database 314 to the target database 322 may be determined. In such a case, if the comparison reveals that the target results match the source result, it may be ascertained that the results obtained from the target database 322 are accurate and hence conclude, that it may be feasible for migrating the source database 314 to the target database 114.

For example, if a comparison score generated by comparing the target result 330 with the source result 332 is greater than a comparison threshold, the migration may be determined to be feasible. On the other hand, if the comparison score is less than the comparison threshold, the migration may be determined to be non-feasible.

The assessment module 306 may further ascertain based on one or more operational parameters of the target database 322, whether it would be feasible migrating to the target database 322. For example, various operational parameters may be determined while the queries are being executed on the target database 322. These operational parameters may then be compared with values of corresponding parameters based on execution of the same set of queries on the source database 314. In an example, the time taken for queries, amount of computational resources utilized, or other such operational parameters may be considered for determining the feasibility of migrating the applications 308 from the source database 314 to the target database 322.

FIG. 4 illustrates a method 400 to be implemented by assessment system 104, as per an example of the present subject matter. Although the method 400 may be implemented for servicing of a variety of computing devices, for the ease of explanation, the present description of the example method 400 is provided in reference to the above-described assessment system 104. The order in which the various method blocks of method 400 are described, is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 400, or an alternative method.

The blocks of the method 400 may be implemented through instructions stored in a non-transitory computer-readable medium, as will be readily understood. The non-transitory computer-readable medium may include, for example, digital memories, magnetic storage media, such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

At block 402, an application query may be intercepted by an application server. The application query may be generated by an application during runtime to be directed to and executed on a source database. For example, an application 108 may be operating on an application server 102. Such application 108, during runtime, may generate an application query 216 directed to and executed on a source database 112. In operation, the assessment module 106 may intercept the application query 216 during runtime.

At block 404, the intercepted application query may then be extracted. For example, once intercepted, the assessment module 106 may extract the application query 216 and store the same within the assessment system 104.

At block 406, the extracted application query may be directed to a target database. For example, thereafter, the assessment module 106 may direct the extracted application query 216 to a target database 114.

At block 408, the extracted application query may be caused to execute on the target database. For example, the extracted application query 216, once directed, may then be executed on the target database 114.

At block 410, the execution of the extracted application query may be assessed. Further, at block 412, based on the assessment of the execution of the extracted application query on the target database, a feasibility of migration of the application query from the source database to the target database may be determined. For example, the assessment module 106 may assess the execution of the extracted application query 110 o the target database 114. Based on the assessment, the assessment module 106 may determine a feasibility of migration of the application 108 from the source database 112 to the target database 114.

In one example, the assessment module 106 may perform the assessment based on a ratio of a number of queries 216 that successfully executed on the target database 114, to a number of queries 216 that failed while executing on the target database 114. The queries 216 which failed to execute on the target database 114 may be considered as incompatible 220, while queries 216 which successfully executed on the target database 114 may be considered as compatible queries 218. Based on the ratio of the number of compatible queries 218 to the number of incompatible queries 220, the assessment module 106 may determine a compatibility parameter 222, based on which, may assess the feasibility of migrating the applications 108 from the source database 112 to the target database 114.

For example, if the compatibility parameter 222 is greater than a compatibility threshold 224, the assessment module 106 may determine the migration of the application 108 from the source database 112 to the target database 114 to be feasible. On the other hand, if the compatibility parameter 222 is lower than the compatibility threshold 224, the migration may be determined to be non-feasible.

In another example, the assessment module 106 may also assess an accuracy of the query results to determine the feasibility of migrating to the target database 114. For example, the result obtained by execution of the application queries 216 on the target database 114, referred to as target result 228, may be compared with the result obtained by execution of the same set of queries 216 on the source database 112, referred to as source result 226. The source result 226 and the target result 228 may be compared, and based on the comparison, the feasibility of migrating the application 108 from the source database 112 to the target database 114 may be determined. In such a case, if the comparison reveals that the target results 228 match the source result 226, it may be ascertained that the results obtained from the target database 114 are accurate and hence conclude, that it may be feasible for migrating the source database 112 to the target database 114. For example, if a comparison score 230 generated by comparing the target result 228 with the source result 226 is greater than a comparison threshold 232, the migration may be determined to be feasible. On the other hand, if the comparison score 230 is less than the comparison threshold 232, the migration may be determined to be non-feasible.

FIG. 5 illustrates a method 500 to be implemented by assessment system 104, as per another example of the present subject matter. Although the method 500 may be implemented for servicing of a variety of computing devices, for the ease of explanation, the present description of the example method 500 is provided in reference to the above-described assessment system 104. The order in which the various method blocks of method 500 are described, is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 500, or an alternative method.

The blocks of the method 500 may be implemented through instructions stored in a non-transitory computer-readable medium, as will be readily understood. The non-transitory computer-readable medium may include, for example, digital memories, magnetic storage media, such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

At block 502, an application query generated by an application during runtime may be intercepted. The application query may be directed to and executed on a source database. For example, an application 108 may be operating on an application server 102. Examples of such application 108 may include, but are not limited to a Java-based application, Python-based application, and . NET-based application. Such application 108, during runtime, may generate an application query 216 directed to and executed on a source database 112. As a result, the source database 112 may be accessed and processed through the execution of such application query 216. In one example, the application query 216 may be a SQL query, that may be directed to and executed on the source database 112.

In operation, the assessment module 106 may intercept the application query 216 during runtime. In an example, the interception of the application query 216 may be affected by intercepting one or more system calls, say through an application driver, that may be invoked in response to the generation of the application query 216.

In another example, an application byte code 212, generated upon execution of the application query 220, may be executed by executable agents through various Application Programming Interfaces (APIs) .

At block 504, the intercepted application query may be intercepted. For example, once intercepted, the assessment module 106 may extract the application query 216 and store the same within the assessment system 104.

At block 506, the extracted application query may be directed to a target database. Further, at block 508, the extracted application query may be caused to execute on the target database. For example, the assessment module 106 may direct the extracted application query 216 to be executed on a target database 114. In one example, in the case of interception of one or more system calls, the assessment module 106 may direct the intercepted system calls through the application driver to be executed on the target database 114. In another example, in the case of interception of the application byte code 212 corresponding to the application query 216, the intercepted application byte code 212 may be modified to direct the corresponding application query 216 to execute on the target database 114. The assessment module 106 may assess the execution of the extracted application query 216 on the target database 114. Such an assessment may be performed on multiple basis.

In one example, upon the execution of extracted application 216 on the target database 114, at block 510, a compatibility parameter may be determined. For example, the assessment may be performed based on a ratio of the application queries 216 that successfully executed on the target database 114 to a number of application queries 216 that failed while executing on the target database 114. To this end, queries 216 which executed successfully on the target database 114 may be considered as being compatible queries 218, while queries 216 which failed to execute may be considered as incompatible queries 220. Based on the ratio of the number of compatible queries 218 to the number of incompatible queries 220, the assessment module 106 may ascertain a degree to which the application queries 216 are compatible. In an example, the assessment module 106 may quantify the extent of compatibility using a compatibility parameter 222. The compatibility parameter 222 may be based on the number of queries 216 which were determined to be incompatible and the number of queries 216 that were determined. In an example, the compatibility parameter 222 may be determined based on a ratio of the compatible queries 218 and the incompatible queries 220.

At block 512, the compatibility parameter may be compared with a compatibility threshold. For example, based on the compatibility parameter 222, the assessment module 106 may assess the feasibility of migrating the applications 108 from the source database 112 to the target database 114.. If the compatibility parameter 222 is determined to be greater than the compatibility threshold 224 ( ‘Yes’ path from block 512) , the method 500 may proceed to block 514, where the assessment module 106 may determine the migration of the application 108 from the source database 112 to the target database 114 to be feasible.

On the other hand, if the compatibility parameter 222 is determined to be lower than the compatibility threshold 224 ( ‘No’ path from block 512) , the method 500 may proceed to block 516, where the assessment module 106 may determine the migration of the application 108 from the source database 112 to the target database 114 to be non-feasible.

In another example, upon the execution of extracted application 216 on the target database 114, at block 518, a target result may be determined and compared with a source result. For example, in addition to determining whether the application queries 216 are compatible with the target database 114, the assessment module 106 may also assess an accuracy of the query results to determine the feasibility of migrating the applications 108 from the source database 112 to the target database 114. For example, the assessment module 106 may compare the result obtained by execution of the application queries 216 on the target database 114, referred to as target result 228, with the result obtained by execution of the same set of application queries 216 on the source database 112, referred to as source result 226.

In yet another example, the assessment module 106 may also assess one or more operational parameters of the target database 114 to assess and ascertain the feasibility of migrating the applications 108 from the source database 112 to the target database 114. One of such operational parameters include accuracy of the search results. To this end, the assessment module 106 may execute the application queries 216 on both the source database 112 and the target database 114. The results obtained as a result of executing the application queries 216 on the source database 112 (i.e., the source results 226) and the results obtained as a result of executing the application queries 216 on the target database 114 (i.e., the target result 228) may be obtained and analyzed.

Besides accuracy, the feasibility may be assessed based on other operational parameters as well. For example, the assessment module 106 may monitor the computational performance of the queries 216 with respect to the target database 114 versus the performance of the queries 216 with respect to the source database 112. To this end, the assessment module 106 may monitor utilization of computational resources, e.g., CPU usage, memory utilization, and such, when the application queries 216 are executed on the source database 112. In a similar manner, the computational resource utilization may also be determined when the application queries 216 are executed on the target database 114.

At block 520, the comparison score may be compared with a comparison threshold. For example, if the comparison score 230 is determined to be greater than the comparison threshold 232 ( ‘Yes’ path from block 520) , the method 500 may proceed to block 514, where the assessment module 106 may determine the migration of the application 108 from the source database 112 to the target database 114 to be feasible.

On the other hand, if the comparison score 230 is determined to be lower than the comparison threshold 232 ( ‘No’ path from block 520) , the method 500 may proceed to block 516, where the assessment module 106 may determine the migration of the application 108 from the source database 112 to the target database 114 to be non-feasible.

FIG. 6 illustrates a computing environment 600 implementing a non-transitory computer readable medium for assessing migration of an application from a source database to a target database. In an example, the computing environment 600 includes processor 602 communicatively coupled to a non-transitory computer readable medium 604 through communication link 606. In an example, the processor 602 may have one or more processing resources for fetching and executing computer-readable instructions from the non-transitory computer readable medium 604. The processor 602 and the non-transitory computer readable medium 604 may be implemented in an application server 608.

The non-transitory computer readable medium 604 may be, for example, an internal memory device or an external memory. In an example implementation, the communication link 606 may be a network communication link, or other communication links, such as a PCI (Peripheral component interconnect) Express, USB-C (Universal Serial Bus Type-C) interfaces, I ²C (Inter-Integrated Circuit) interfaces, etc. In an example implementation, the non-transitory computer readable medium 604 includes a set of computer readable instructions 610 which may be accessed by the processor 602 through the communication link 606 and subsequently executed to assess migration of an application from a source database to a target database.

Referring to FIG. 6, in an example, the non-transitory computer readable medium 604 includes computer readable instructions 610 that cause the processor 602 to intercept an application query. The application query may be generated by an application during runtime to be directed to and executed on a source database..

The instructions 610 may further cause the processor 602 to extract the intercepted application query. The instructions 610 may further cause the processor 602 to direct the extracted application query to a target database. Further, the instructions 610 may cause the processor 602 to cause the extracted application query to execute on the target database.

Furthermore, the instructions 610 may cause the processor 602 to assess the execution of the extracted application query on the target database. Based on the assessment, the instructions 610 may cause the processor 602 to determine a feasibility of migrating the application query from the source database to the target database.

Although examples for the present disclosure have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed and explained as examples of the present disclosure.

Claims

An application server comprising:

a processor;

an assessment module coupled to the processor, wherein the assessment module is to:

intercept an application query, wherein the application query is generated by an application during runtime to be directed to and executed on a source database;

extract the intercepted application query;

direct the extracted application query to a target database;

cause the extracted application query to execute on the target database;

assess the execution of the extracted application query on the target database; and

based on the assessment of the execution of the extracted application query on the target database, determine a feasibility of migration of the application from the source database to the target database.
The application server as claimed in claim 1, wherein the assessment module, based on the execution of the extracted application query on the target database, is to determine a compatibility parameter, wherein the compatibility parameter corresponds to a ratio of a number of compatible queries to a number of incompatible queries, wherein:

the compatible queries correspond to the application queries successfully executed on the target database; and

the incompatible queries correspond to the application queries that failed while executing on the target database.
The application server as claimed in claim 2, wherein the assessment module determines the migration of the application query from the source database to the target database to be feasible when the compatibility parameter is greater than a compatibility threshold.
The application server as claimed in claim 2, wherein the assessment module determines the migration of the application query from the source database to the target database to be non-feasible when the compatibility parameter is lower than a compatibility threshold.
The application server as claimed in claim 1, wherein the assessment module is to:

based on the generation of the application query, invoke a plurality of system calls through an application driver for allowing the application to access the source database;

intercept at least one of the plurality of system calls corresponding to the application query; and

direct the intercepted system calls through the application driver to the target database.
The application server as claimed in claim 1, wherein the application query, on execution, is to generate an application byte code.
The application server as claimed in claim 6, wherein the assessment module is to:

intercept the application byte code corresponding to the application query;

modify the application byte code, wherein modification of the application byte code is to direct the corresponding application query to the target database; and

cause the modified application byte code to execute the application query on the target database.
The application server as claimed in claim 7, wherein the application byte code is intercepted by an executable agent through a corresponding Application Programming Interface (API) .
The application server as claimed in claim 1, wherein the application is one of a Java-based application, Python-based application, and a. NET-based application.
A method comprising:

intercepting, by an application server, an application query, wherein the application query is generated by an application during runtime to be directed to and executed on a source database;

extracting the intercepted application query;

directing the extracted application query to a target database;

causing the extracted application query to execute on the target database;

assessing the execution of the extracted application query on the target database; and

based on the assessment of the execution of the extracted application query on the target database, determining a feasibility of migration of the application query from the source database to the target database.
The method as claimed in claim 10, further comprising:

based on an execution of the application query on the source database, determining a source result; and

based on the execution of the application query on the target database, determining a target result.
The method as claimed in claim 11, wherein the source result and the target result further comprises a plurality of operational parameters of the source database and the target database respectively, and wherein the plurality of operational parameters corresponds to the execution of the application query on each of the source database and the target database.
The method as claimed in claim 12, wherein the plurality of operational parameters comprises one of an execution time parameter, a computational resource parameter, or a combination thereof.
The method as claimed in claim 13, wherein:

the execution time parameter of the source result and the target result corresponds to a measure of time taken by the application query to execute on the source database and the target database respectively; and

the computational resource parameter of the source result and the target result corresponds to a measure of amount of computational resources utilized by the application query to execute on the source database and the target database respectively.
The method as claimed in claim 11, further comprising determining the migration of the application query from the source database to the target database to be feasible when a comparison score generated based on a comparison of the source result and the target result is greater than a comparison threshold.
The method as claimed in claim 11, further comprising determining the migration of the application query from the source database to the target database to be non-feasible when a comparison score generated based on a comparison of the source result and the target result is lower than a comparison threshold.
A non-transitory computer readable medium comprising computer-readable instructions, which when executed by a processor, cause an application server to:

intercept an application query, wherein the application query is generated by an application during runtime to be directed to and executed on a source database;

extract the intercepted application query;

direct the extracted application query to a target database;

cause the extracted application query to execute on the target database;

assess the execution of the extracted application query on the target database; and

based on the assessment of the execution of the extracted application query on the target database, determine a feasibility of migration of the application query from the source database to the target database.
The non-transitory computer-readable medium as claimed in claim 17, wherein the instructions, based on the execution of the extracted application query on the target database, is to cause the application server to determine a compatibility parameter, wherein the compatibility parameter corresponds to a ratio of a number of compatible queries to a number of incompatible queries, wherein:

the compatible queries correspond to the application queries successfully executed on the target database; and

the incompatible queries correspond to the application queries that failed while executing on the target database.
The non-transitory computer-readable medium as claimed in claim 18, wherein the instructions cause the application server to determine the migration of the application query from the source database to the target database to be feasible when the compatibility parameter is greater than a compatibility threshold.
The non-transitory computer-readable medium as claimed in claim 18, wherein the instructions cause the application server to determine the migration of the application query from the source database to the target database to be non-feasible when the compatibility parameter is lower than a compatibility threshold.