This disclosure relates generally to software development, and more particularly to assessing the readiness of a software application for deployment via a container.
Many software applications have been designed for deployment in an on-premises environment. Recently, however, it has become increasingly desirable to deploy software applications as containers in a software as a service (“SaaS”) environment, due to the increased flexibility and scalability that containerization provides. Accordingly, many entities have sought to migrate software applications that were originally designed as on-premises applications to deployment via containers in a SaaS environment. Not all on-premises software applications are amenable to deployment via containers, however, and there are a number of factors that must be assessed when determining whether an on-premises application can feasibly be containerized. This determination—whether a software application can be migrated from an on-premises environment to containers—is often a complex and time-consuming project, requiring extensive analysis of the software application in question and intimate knowledge of containerization principles.
Techniques are disclosed relating to assessing the container-readiness of a software application. In some embodiments, a computer system performs an assessment of the container-readiness of a software application relative to a specified containerization procedure. The assessment may be based on a plurality of parameters associated with the software application. In some embodiments, the assessment includes parsing program code associated with the software application to determine, for one or more static parameters, corresponding static parameter scores. In some embodiments, for example, the one or more static parameters may include at least one of a size of the software application, deployment dependencies associated with the software application, or software packages utilized by the software application. The assessment may further include analyzing runtime information corresponding to the software application to determine a runtime parameter score for at least one runtime parameters. In some embodiments, for example, the at least one runtime parameter may correspond to a CPU usage level of a computing device when executing the software application in a test environment. Further, the assessment may include generating a container-readiness value for the software application based on the runtime parameter score and the static parameter scores. In some embodiments, the container-readiness value is indicative of a degree of compliance with the specified containerization procedure.
In the past, it was common practice to design enterprise software applications for deployment in an on-premises environment. In recent years, however, it has become increasingly cost-effective and technically feasible to deploy enterprise applications in a SaaS environment. For example, application deployment through SaaS can offer improved flexibility and scalability relative to an on-premises deployment, while reducing costs associated with establishing and maintaining on-premises infrastructure. One popular SaaS technique is containerization, in which a software application is packaged with all of its requisite libraries and dependencies and run on host machine as a container. Containers also offer several benefits over application deployment via virtual machines (“VMs”). For example, VMs are created and managed by a hypervisor, and each VM on a host machine typically requires its own guest operating system. Containers, by contrast, run directly within the host machine's kernel, and the host machine is not required to implement a hypervisor. As a result, containers are lighter and more-quickly instantiated than VMs, and a given host machine can typically host more containers than it could corresponding VMs.
Accordingly, many entities have sought to migrate software applications that were originally designed as on-premises applications to deployment as containers in a SaaS environment. Due to the differences between their original development environment and the desired containerization deployment environment, however, not all on-premises software applications are good candidates for deployment via containers, and there are a number of factors that must be assessed when determining whether an on-premises application can feasibly be containerized. For example, on-premises applications that require extensive local configurations to their host machines, are large (e.g., one or more gigabytes) in size, or rely on specific hardware integration may be difficult to transition to a container-based deployment. In some instances, it may be more time- and cost-effective to entirely redesign a software application specifically for containerization than it would be to simply modify the software application in its current state. This determination—whether a software application can be readily migrated from an on-premises environment to deployment via one or more containers—is often a complex and time-consuming technical problem, requiring extensive analysis of the software application in question and intimate knowledge of containerization principles.
Referring now to
In the depicted embodiment, system 100 assesses the container-readiness of software application 102. System 100 may receive software application 102, or information associated with software application 102, as part of a request to assess its container-readiness. In various embodiments, the disclosed systems and methods may assess the container-readiness of software applications based on various parameters relevant to containerization. In some embodiments, these parameters include “static parameters,” which, as used herein, are factors associated with a software application that may be assessed without executing the software application itself. In some embodiments, static parameters may be assessed by analyzing program code associated with the software application. Non-limiting examples of static parameters include the size of a software application, deployment dependencies associated with the software application, or software packages utilized by the software application. In
The container-readiness of a software application may also be assessed on the basis of one or more “runtime parameters,” which, as used herein, are factors associated with a software application that may be assessed by analyzing runtime information corresponding to a test execution of the software application. Note that, in at least some embodiments, the disclosed systems and methods may generate a container-readiness value for a software application without reliance on any distinction between static and runtime parameters. Instead, in some such embodiments, a parameter score may simply be determined for each of the parameters for which a given software application 102 is being assessed. In
System 100 further includes container-readiness value generation module 116, which in various embodiments is operable to generate a container-readiness value 118 for the software application 102 based on the runtime parameter score(s) 114 and the static parameter scores 108. For example, container-readiness value generation module 116, in various embodiments, includes or has access to weighting factors for the parameters used to assess the container-readiness of software application 102. Container-readiness value generation module 116 may use these weighting factors to generate weighted versions of the static parameter scores 108 and runtime parameter scores 114, which in turn may be used to generate container-readiness value 118. As noted above, this container-readiness value 118 is indicative of a degree of compliance of software application 102 with a specified containerization platform, such as Docker Enterprise container platform or any other suitable alternative. Stated differently, the container-readiness value 118, in some embodiments, is indicative of the readiness of the software application in question for deployment as a container. For example, in some embodiments, a relatively high container-readiness value 118 may indicate that few modifications need to be made to software application 102 before it may be successfully deployed as a container. In such an instance, the software application 102 may be considered a good candidate for containerization. Conversely, in some embodiments, a relatively low container-readiness value 118 may indicate that extensive changes need to be made to the software application 102 (e.g., by removing hardware dependencies, modifying network communication behavior of the application 102, etc.) before it may be successfully deployed as a container. In such an instance, the software application 102 may be considered a poor candidate for containerization and it may be deemed more prudent to instead redesign the application 102 specifically for containerization, rather than adapting the existing application architecture. Note, however, that these embodiments are described merely as an example and are not intended to limit the scope of the present disclosure. In other embodiments, container-readiness values 118 may be generated such that the degree of compliance with a specified containerization platform increases as the value 118 decreases, etc.
The present disclosure addresses technical problems in the field of software development and, more specifically, software containerization. As noted above, the determination of whether a software application can be migrated from an on-premises environment to deployment via one or more containers is often a complex and time-consuming technical problem. Depending on the complexity of the software application in question, such a determination can take weeks or months of time and effort to resolve. Various embodiments of the present disclosure, however, provide a technical solution to this technical problem, thereby improving the process of assessing the container-readiness of a software application and the software development process as a whole. For example, by assessing the container-readiness of a given software application 102 using system 100, the determination of whether to migrate the software application 102 from an on-premises deployment to deployment via containers may be made very quickly and with a high degree of precision, saving time and effort on the part of one or more software engineers. This, in turn, may reduce the expense and time required to migrate a software application from an on-premises environment to deployment via containers. Further, in some embodiments, the disclosed systems and methods may prevent the migration to containers of a software application that is a poor candidate for containerization. Instead, using various disclosed embodiments, it may be determined that, rather than attempting to migrate the application in its existing state to containers, such time and effort would be better spent redesigning the application to be inherently more amenable to containerization.
In some instances, use of an on-premises environment, such as that depicted in block diagram 200, may require significant overhead costs to establish, implement, and maintain the various components shown in
Block diagram 250 shows a container-based deployment of application 208, for example as part of a SaaS environment, according to one embodiment. As shown in diagram 250, the container-based deployment environment includes infrastructure 252, host OS 254, container manager 256, and various containers 258A-258N. Within each container 258 is an instance of application 208 packaged with its necessary binary files, composition files, and libraries 260.
Containerization can offer a number of benefits over an on-premises deployment of application 208, in various instances. For example, as noted above, containers are lightweight and can be quickly instantiated in response to increased need. Additionally, containers typically require less overhead costs to establish and maintain on-premises infrastructure. In various embodiments, a software application may migrated from an on-premises deployment to a container-based deployment based, at least in part, on a container-readiness value generated for the software application. For example, in response to a container-readiness value 118 for software application 102 exceeding a predetermined threshold, containerization operations may be initiated to migrate the application 208 from the on-premises environment to a container-based environment.
Referring now to
In various embodiments, program code analysis module 106 is operable to parse program code 104 associated with software application 102 and to determine, for one or more static parameters, corresponding static parameter scores 108. In the depicted embodiment, program code analysis module 106 parses program code 104 to assess the software application 102 on the basis of a variety of static parameters, include static parameter 302. As shown in
The presence of other parameters or sub-parameters, however, may pose a more-significant obstacle to containerization of the software application and, accordingly, the corresponding complexity ratings for those parameters or sub-parameters may indicate this increased difficulty (e.g., by having a relatively high complexity rating). Continuing with the above example, sub-parameter 304B may be the specific hardware integrations the application 102 relies on in operation. In some embodiments, this presence of this sub-parameter 304B—the hardware integrations utilized—may pose a significant obstacle to migrating the application 102 to a container. Accordingly, in some such embodiments, sub-parameter 304B may be assigned a complexity rating that is high, such as a 10 on a scale from 1 to 10. Note that this embodiment is provided merely as an example and is not intended to limit the scope of the present disclosure. In various embodiments, the specific sub-parameters 304 will vary depending on the particular static parameter 302 with which they are associated.
In various embodiments, program code analysis module 106 may parse program code 104 to determine the extent to which various static parameters and sub-parameters are present in software application 102. Program code analysis module 106 may then assign a frequency value 308 (e.g., a numerical value between 1 and 10, or on any other suitable scale) to one or more of the sub-parameters 304 based on the extent to which the sub-parameters 304 are present in the program code 104. For example, if there are many instances of a particular sub-parameter 304 (e.g., sub-parameter 304C) present in the program code 104, program code analysis module 106 may assign a relatively high frequency value 308 (e.g., frequency value 308C, in this example), to the sub-parameter 304. If instead, however, there are few or no instances of a particular sub-parameter present in the program code 104, program code analysis module 106 may assign a relatively low frequency value 308 to the sub-parameter 304.
In various embodiments, program code analysis module 106 is operable to use the frequency values 308 and complexity ratings 306, for each of the sub-parameters 304 associated with static parameter 302, to determine a static parameter score 108 for static parameter 302. This process may be repeated for each of the various static parameters 302 for which the application 102 is being assessed. The manner in which program code analysis module 106 generates the static parameter scores 108 may vary, according to different embodiments. In some embodiments, program code analysis module 106 may generate the static parameter scores 108 as follows:
Where Si is the parameter score for a given parameter i, Cij is the complexity of a given sub-parameter j for a given parameter i, and Vij is the frequency value of the given sub-parameter j for the given parameter i, where the summation is performed over the index value j. For example, based on Equation 1, the static parameter score 108 for static parameter 302 would be as follows: S302=complexity rating 306A*frequency value 308A+complexity rating 306B*frequency value 308B+complexity rating 306C*frequency value 308C, according to some embodiments. Program code analysis module 106 may repeat this process to determine a static parameter score 108 for each of the static parameters for which the software application 102 is being assessed. Note, however, that this embodiment is provided merely as an example and is not intended to limit the scope of the present disclosure. In other embodiments, program code analysis module 106 may generate the static parameter scores 108 using other suitable techniques.
In various embodiments, runtime information analysis module 112 is operable to parse runtime information 110 to determine performance values 316 associated with each of the sub-parameters 312, where the performance values 316 are indicative of the level of software application 102's performance for the runtime sub-parameters 312. Runtime information analysis module 112 may, in various embodiments, use the complexity ratings 314 and performance values 316, for each of the sub-parameters 312 associated with runtime parameter 310, to determine a runtime parameter score 114 for the runtime parameter 310. This process may be repeated for each of the runtime parameters 310 for which the application 102 is being assessed. The manner in which runtime information analysis module 112 generates the runtime parameter scores 114 may vary, according to different embodiments. In some embodiments, runtime information analysis module 112 generate the runtime parameter scores 114 based on Equation 1, provided above. For example, based on Equation 1, the runtime parameter score 114 for runtime parameter 310 would be as follows: S310=complexity rating 314A*performance value 316A+complexity rating 314B*performance value 316B+complexity rating 314C*performance value 316C, according to some embodiments. Runtime information analysis module 112 may repeat this process to determine a runtime parameter score 114 for each of the runtime parameters for which the application 102 is being assessed. Note, however, that this embodiment is provided merely as an example and is not intended to limit the scope of the present disclosure. In other embodiments, runtime information analysis module 112 may generate the runtime parameter scores 114 using other suitable techniques.
Where S is the container-readiness value 118, Si is the parameter score for a given parameter i (e.g., static parameter score 108, runtime parameter score 114, etc.), Wi is the weighting factor for the given parameter i, and the summation is performed over the index i for each of the parameters for which the software application 102 is being assessed. A more detailed example for generating a container-readiness value 118 based on Equations 1 and 2 will be discussed below with reference to
Turning now to
At 402, in the illustrated embodiment, a computer system performs an assessment of the container-readiness of a software application relative to a specified containerization platform. In various embodiments, the assessment is based on a plurality of parameters, such as static parameters and runtime parameters associated with the software application. In various embodiments, assessing the container-readiness of the software application includes elements 404-408. As noted above, however, one or more of elements 404-408 may be omitted in performing the assessment, and additional elements may also be performed as desired.
At 404, in the depicted embodiment, the computer system parses program code associated with the software application to determine, for one or more static parameters, corresponding static parameter score. For example, as discussed above with reference to
At 406, in the depicted embodiment, the computer system analyzes runtime information corresponding to the software application to determine a runtime parameter score for at least one runtime parameter. For example, as discussed above with reference to
In some embodiments, each of the runtime parameters 310 includes one or more sub-parameters 312, and each of the sub-parameters 312 is associated with a complexity rating 314. In various embodiments, determining, for a given runtime parameter 310, a corresponding runtime parameter score 114 includes determining a performance value 316 for each of the one or more sub-parameters, and generating the corresponding runtime parameter score based on the performance values 316 and the complexity ratings 314 for the one or more sub-parameters. In some embodiments, a runtime parameters may correspond to a CPU usage level of a computing device when executing the software application in a test environment. Note, however, that this embodiment is provided merely as an example and, as discussed in more detail below with reference to
At 408, in the depicted embodiment, the computer system generates, based on the runtime parameter score and the static parameter scores, a container-readiness value for the software application. For example, as discussed above with reference to
Note that, in some embodiments, method 400 may further include receiving, by the computer system from a user, input specifying an adjusted weighting factor for at least one of the plurality of parameters. In such embodiments, method 400 may further include generating an updated container-readiness value using the adjusted weighting factor. Additionally, in some embodiments, method 400 may further include receiving, from a user, a definition of a custom static parameter. In some such embodiments, element 404 may further include parsing the program code associated with the software application to determine a custom static parameter score for the custom static parameter, and element 408 may include generating the container-readiness value based on the custom static parameter score.
Further note that, in some embodiments, method 400 may further include initiating containerization operations for the software application using the specified containerization platform in response to the container-readiness value exceeding a predetermined threshold. In one non-limiting embodiment, for example, method 400 may include initiating containerization operations (e.g., modifying aspects of the software application 102 in preparation for deployment via containers) in response to the container-readiness value 118 indicating that the application 102 is over 60% ready for containerization. Note, however, that this embodiment is provided merely as an example and is not intended to limit the scope of the disclosed systems and methods.
Referring now to
In table 500, each of the parameters is associated with a weighting factor. As noted above, these weighting factors may be used, e.g., by container-readiness value generation module 116, to generate the container-readiness value based on one or more parameter scores. Note that, in the depicted embodiment, the weighting factors are designated as either “low,” “medium,” or “high,” rather than being given numerical values. In the depicted embodiment, these relative weighting designations are mapped to numerical values (specifically “1,” “2,” and “3,” respectively), which, as discussed in more detail below with reference to
In
A similar process may be performed (e.g., by program code analysis module 106 or runtime information analysis module 112) to generate the parameter scores for the remaining five parameters provided in table 510. Note, however, that this embodiment is provided merely as an example and is not intended to limit the scope of the present disclosure. In other embodiments, the parameter scores may be generated according to other suitable techniques.
In the depicted embodiment, the weighting factors (shown in table 500) and the parameter scores (shown in table 510) are used to generate a container-readiness value 118 for the particular software application 102 being assessed. The manner in which the container-readiness value 118 is generated may vary according to different embodiments. In some embodiments, the container-readiness value 118 may be generated based on Equation 2 provided above. For example,
Note, however, that the embodiment depicted in
Referring now to
Processor subsystem 620 may include one or more processors or processing units. In various embodiments of computer system 600, multiple instances of processor subsystem 620 may be coupled to interconnect 680. In various embodiments, processor subsystem 620 (or each processor unit within 620) may contain a cache or other form of on-board memory.
System memory 640 is usable to store program instructions executable by processor subsystem 620 to cause system 600 perform various operations described herein. System memory 640 may be implemented using different physical, non-transitory memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system 600 is not limited to primary storage such as system memory 640. Rather, computer system 600 may also include other forms of storage such as cache memory in processor subsystem 620 and secondary storage on I/O devices 670 (e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem 620.
I/O interfaces 660 may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface 660 is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces 660 may be coupled to one or more I/O devices 670 via one or more corresponding buses or other interfaces. Examples of I/O devices 670 include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, I/O devices 670 includes a network interface device (e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.), and computer system 600 is coupled to a network via the network interface device.
Although the embodiments disclosed herein are susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the figures and are described herein in detail. It should be understood, however, that figures and detailed description thereto are not intended to limit the scope of the claims to the particular forms disclosed. Instead, this application is intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosure of the present application as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description.
This disclosure includes references to “one embodiment,” “a particular embodiment,” “some embodiments,” “various embodiments,” “an embodiment,” etc. The appearances of these or similar phrases do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.
As used herein, the term “based on” is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect the determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase “determine A based on B.” This phrase specifies that B is a factor that is used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase “based on” is synonymous with the phrase “based at least in part on.”
As used herein, the phrase “in response to” describes one or more factors that trigger an effect. This phrase does not foreclose the possibility that additional factors may affect or otherwise trigger the effect. That is, an effect may be solely in response to those factors, or may be in response to the specified factors as well as other, unspecified factors. Consider the phrase “perform A in response to B.” This phrase specifies that B is a factor that triggers the performance of A. This phrase does not foreclose that performing A may also be in response to some other factor, such as C. This phrase is also intended to cover an embodiment in which A is performed solely in response to B.
As used herein, the terms “first,” “second,” etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.), unless stated otherwise. When used in the claims, the term “or” is used as an inclusive or and not as an exclusive or. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof (e.g., x and y, but not z).
It is to be understood that the present disclosure is not limited to particular devices or methods, which may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” include singular and plural referents unless the context clearly dictates otherwise. Furthermore, the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, means “including, but not limited to.” The term “coupled” means directly or indirectly connected.
Within this disclosure, different entities (which may variously be referred to as “units,” “circuits,” other components, etc.) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation—[entity] configured to [perform one or more tasks]—is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be “configured to” perform some task even if the structure is not currently being operated. A “memory device configured to store data” is intended to cover, for example, an integrated circuit that has circuitry that performs this function during operation, even if the integrated circuit in question is not currently being used (e.g., a power supply is not connected to it). Thus, an entity described or recited as “configured to” perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible.
The term “configured to” is not intended to mean “configurable to.” An unprogrammed FPGA, for example, would not be considered to be “configured to” perform some specific function, although it may be “configurable to” perform that function after programming.
Reciting in the appended claims that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) for that claim element. Accordingly, none of the claims in this application as filed are intended to be interpreted as having means-plus-function elements. Should Applicant wish to invoke Section 112(f) during prosecution, it will recite claim elements using the “means for” [performing a function] construct.
In this disclosure, various “modules” operable to perform designated functions are shown in the figures and described in detail above (e.g., program code analysis module 106, runtime information analysis module 112, container-readiness value generation module 116, etc.). As used herein, the term “module” refers to circuitry configured to perform specified operations or to physical, non-transitory computer-readable media that stores information (e.g., program instructions) that instructs other circuitry (e.g., a processor) to perform specified operations. Such circuitry may be implemented in multiple ways, including as a hardwired circuit or as a memory having program instructions stored therein that are executable by one or more processors to perform the operations. The hardware circuit may include, for example, custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. A module may also be any suitable form of non-transitory computer readable media storing program instructions executable to perform specified operations.
Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.
The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.