System and method for cloud provisioning and application deployment

Embodiments described herein provide systems and methods for installing or otherwise supporting applications in a cloud environment and systems and methods for provisioning a cloud environment. One embodiment includes abstracting a set of configuration information associated with a first environment into a set of environment independent attributes and a set of environment dependent attributes. A second environment may then be configured using the mapped environment independent attributes and the values for the set of environment dependent attributes. If the second environment is a cloud environment, embodiments described herein can include provisioning the cloud environment by mapping hardware and/or software characteristics of the first environment and/or user selected characteristics to abstractions of the characteristics and sending API calls to a cloud environment interface based on the abstractions of the characteristics to provision a selected target environment in the cloud environment.

TECHNICAL FIELD

Embodiments described in this disclosure relate generally to application deployment and support. More particularly, embodiments described herein related to application deployment and support in a cloud environment.

BACKGROUND

Software lifecycles begin in the development environment in which developers strive to create and perfect the program. As development proceeds various versions of the application evolve on the development server(s) used to code, test, and debug the application. Frequently, each version of the application requires different resources from the server in order to run properly. Likewise, because the environment of each server can differ from the others, the installation of an application on a particular server often requires resources from that server that may be unique to that server. Once the application is operational, each installation in a large scale deployment can be virtually unique thereby creating a nightmare for the support team called upon to deploy the application. These difficulties occur across a wide range of technologies other than application servers including, but not limited to, mobile telecommunication networks, database servers, computing networks (LANs or WANs), web servers, and enterprise service buses.

For instance, Java Platform Enterprise Edition (referred to as J2EE) is a platform for developing and executing distributed, multi-tiered, Java applications. In this case, deployment is the act of installing components for a J2EE application and configuring a J2EE Application Server to run the J2EE application. Deployment of these applications can occur multiple times to multiple targets during the development life cycle and can occur to application servers provided by a multiplicity of vendors. Because each application server may be configured differently, configuring application servers during deployment can be a time consuming and inefficient task.

Current deployment methods include manual deployment, using vendor specific GUI applications (i.e., installation “wizards”), using vendor specific command line tools (e.g., scripting etc.) and creating custom installation utilities. These current methods, however, suffer several shortcomings. Manual deployment is time consuming and error prone during both initial installation at a target and during updating. Furthermore, documentation related to the changes needed for the application server must be manually updated after changes to the application or the application server. Manual installation also provides limited, if any, versioning. Using vendor specific GUI applications also leads to time consuming and error prone installations and updates. Furthermore, installation applications are typically tied to the particular vendor's system, necessitating the purchase of multiple installation applications if the code is to be installed on multiple vendors' servers. Training is also typically required for each vendor's system. Likewise, vendor specific command line tools require developer intervention for changes and are also often tied to a single vendor's system. Thus, changes are difficult to synchronize across multiple vendors' systems. Moreover, vendor specific command line tools are time consuming for the developer, lack versioning, require training and also require manual updates. Similarly, existing custom utilities are generally expensive, time consuming and are not adequately robust to handle a variety of installations on multiple vendors' systems.

SUMMARY OF THE DISCLOSURE

Embodiments provide systems and methods of supporting applications that eliminate, or at least substantially reduce, the shortcomings of prior art systems and methods for supporting applications.

One embodiment makes installing applications (and performing other operations on the application) as easy as installing a desktop application. Today, typical J2EE applications include a configuration document or script, and a set of files that contain the actual program code, property files, and other settings. To install the application, the code and the other files have to be copied to the correct location on the target application server and the appropriate configuration settings made. Embodiments described herein are different from these conventional techniques. Instead of a collection of files and configuration information, one embodiment can include just the binary files and a relatively small XML document that describes how the application should be configured. IT support staff can then copy the files and execute a lightweight program constructed in accordance with the one embodiment to install the application in any environment (e.g., development, test, or production) or application server (for example JBoss, Websphere, or WebLogic) that the code supports. The program can then automatically configure and deploy the application correctly.

In one embodiment, once the developer has written the application and configured the development environment, the developer points the program to the development server. The program analyzes the server configuration and creates a representation of it. The program can take the configuration information it captured and the built application and deploy the application to different environments and to any server type that the application code supports. Furthermore, the program can make all of the necessary configuration translations automatically.

Embodiments described herein offer several advantages over the prior art. First, it is faster than manual deploying the application and requires a fraction of the development time that using custom utilities and other previously available techniques require. As a result, an installation performed in accordance with the one embodiment can take approximately 5% of the time required using previously available techniques.

Second, embodiments described herein can vastly reduce configuration defects in part by automating the deployment process and providing a single application configuration file for all different environments and server platforms. Embodiments described herein can also avoid configuration errors attributable to oversight and human error, that is, unintentional mistakes.

Third, embodiments of the present disclosure make deployment a non-technical task. One can simply double click on the program icon, answer a few questions, and the program can deploy the application to the specified server(s). Developers can therefore spend their time developing applications (a value-added activity), not deploying them (often considered an expense). Additionally, various embodiments allow developers to version, upgrade, and even install applications in ways that the prior art cannot.

Furthermore, embodiments described herein provide a flexible deployment and support architecture. For example, suppose a customer is having a difficult time getting the application installed. Using the provided architecture, the customer can pull down the configuration information of the faulty installation and send that XML file to IT support, where an exact replica of the customer's environment can be built in the support laboratory. In addition, the architecture can also be used to manage licensed software by generating reports on existing or suspected installations thereby allowing the identification of unlicensed installations.

Embodiments described herein provide a method which includes querying a first server program for a first set of configuration information and identifying sets of environment independent and dependent attributes from the configuration information (using, for example, predefined rules). The values for the environment independent attributes are mapped to, and stored in, a user selected format (e.g., XML). Values for the environment dependent attributes are also stored in that format. The method may include querying other server programs and identifying another set of environment dependent attributes. If so, then the environment independent attributes and one of the sets of environment dependent attributes may be used to configure an environment (e.g., a J2EE environment). The configuration (and other operations provided herein) may be wrapped in a transaction which may include a look ahead sub-process. The look ahead process allows the operation to tolerate unexpected conditions that might be encountered during the operation such as the presence of an attribute which is to be installed or the absence of an attribute which is to be deleted. Change logging may occur during these operations and, indeed, state and prospective change reports may be generated to indicate which changes would occur were a given operation to be performed. Version skipping during application installations may also be provided. The method may also provide application un-installations. The environments in which these activities occur may be associated with either operational or development servers among other environments.

Another embodiment also provides a method which includes abstracting a set of configuration information associated with a first environment into a set of environment independent attributes and a set of environment dependent attributes. The environment independent attributes may be mapped to a user selected format whereas the environment dependent attributes are replaced with tokens and then, optionally, with values. A second environment may then be configured using the mapped environment independent attributes and the values for the set of environment dependent attributes.

One embodiment provides a computer readable medium carrying computer-executable program instructions implementing a method which includes abstracting a set of configuration information associated with a first environment into a set of environment independent attributes and a set of environment dependent attributes. The set of environment independent attributes are mapped to a user selected format and the set of environment dependent attributes are replaced with tokens. The mapped attributes and tokens are stored in a memory.

Another embodiment provides a configuration mapping system which includes an interface, a memory, and a processor in communication with the interface and the memory. The processor receives a user selected format and queries a first server program for a set of configuration information via the interface. The processor identifies a set of environment independent attributes and a set of environment dependent attributes from the set of configuration information. It also maps the set of environment independent attributes into the user selected format and creates tokens for the set of environment dependent attributes. The processor then stores the mapped environment independent attributes and the tokens in the memory. Optionally, the interface may include a wide area network which is in communication with a plurality of servers. Thus, the processor can configure each of the servers using the mapped environment independent attributes and the tokens stored in the memory.

In another embodiment, a method of supporting an application is provided. Since applications typically require resources to run due to the server environment and resources which they require regardless of the server on which they are installed, the method of the one embodiment determines a listing of the resources required to support the application due to the server environment. This listing is apart from the listing of resources required by the application itself regardless of the environment. More particularly, to determine how many resources of that type are required for the application, the application server can be queried for each type of resource known to be required for the application. The server can respond by, for instance, returning a JMX object(s) with the requested information. In turn, this object can be converted to an XML document. A rule set can then be used to determine which resources are required due to the server environment and which resources are required due to the application itself. In any event, the listing of server related requirements is then output. Of course, the non server related requirements may also be output and the two listings used as a “state report” for the server. If at a later time, it is desired to learn if any changes have occurred to the server, a second state report can be generated and compared to the first state report. In this way malicious changes can be detected and the server can be restored to the last known good state using the first report.

Where multiple servers have been analyzed, one of the lists of server related resources (and a list of the application related resources) may then be used to install the application on another server(s) or to re-install it on a server where it is already hosted. Of course, if a particular deployment requires installation on multiple servers, a server related resource listing may be selected for each of the servers individually. Optionally, the target server can be either an operational or a development server and the source server can be the other type of server. More particularly, if an operational application requires troubleshooting, the resource listing related to the operational server can be used to configure a development server to re-create the application's operational environmental thereby facilitating the troubleshooting.

Installations performed in accordance with the one embodiment can also be performed automatically even if unexpected situations occur during the installation. For instance, if the installation encounters a required resource that is already configured for the application, the installation may proceed despite what might otherwise cause a script to fail. Likewise, if a resource that ought to be deleted does not exist on the server, the installation may proceed anyway (without failing as scripts often do). Additionally, the installations can be performed as transactions so that, should the transactions fail, the changes made to the servers will be automatically reversed. In a similar manner, an application can be uninstalled by using the resource lists to identify and remove resources particular to the application from the server.

Embodiments described herein also allow for the creation of a prospective change report detailing what should change during an installation (or de-installation). More specifically, an installation transaction can be started on a server, allowed to all but complete, and then aborted. If the changes made to the server are logged during the installation the log can be used to show what needs to be changed on the server. But, because the transaction was aborted, the changes are undone, or rolled back, leaving the server as it was before the change report was generated.

Furthermore, various embodiments allow “version skipping” during application installations. That is, by using a resource list associated with the new version and a resource list for the server, all the resources required to support the new version may be configured without having to first install each intermediate version of the application. Otherwise, at least with many applications, it is possible that skipping a version will cause some configuration procedure associated with an intermediate version to be skipped. The result, of course, can be an inoperable application or, in other words, a failed installation.

In another embodiment, a method of supporting a mobile telecommunication network is provided. The method of the one embodiment includes determining, from a device with a mobile application installed thereon, a listing of the resources required to support the mobile application due to the device environment. The list of device related resources is then output. Optionally, the device may be a handset, a telecommunications network node, or a development platform. Thus applications may be installed on these (and other types of telecommunications equipment) using a list of device related resource requirements and a list of mobile application related requirements.

In yet another embodiment, a method of supporting a network is provided. The method of the one embodiment includes determining, from a device on the network, a listing of the resources required to support an application on the device. The list of device related resources required to support the application is also output in the one embodiment. Still another embodiment provides a method of supporting a database server. In the method of the one embodiment a listing of the server related resources required to support the database is determined and output. In yet another embodiment a method of supporting a web-server is provided. In the one embodiment, a list of server related support resources is determined for the web-server program. The list is then output.

Embodiments described herein also provide for provisioning of cloud environments. One embodiment can comprise: determining a first set of environment characteristics for the first environment, wherein the first set of environment characteristics comprise hardware characteristics; receiving a set of user selected environment characteristics; mapping the first set of environment characteristics and the set of user selected environment characteristics to a set of abstracted characteristics; mapping the set of abstracted characteristics to API calls for a cloud environment, the API calls selected to provision a selected target environment in the cloud environment and interacting with a cloud environment API using the API calls to configure the cloud environment to provide the selected target environment.

Embodiments described herein can provide advantages by significantly reducing the time and knowledge required to provision a cloud environment and install an application.

DETAILED DESCRIPTION

Various embodiments are illustrated in the FIGURES, like-numerals being used to refer to like and corresponding parts of the various drawings.

Embodiments provide systems and methods for supporting applications in a variety of environments including, but not limited to, application servers, mobile telecommunication networks, database servers, computing networks (LANs or WANs), cloud environments, web servers, and enterprise services.

FIG. 1is a block diagram illustrating an embodiment of a system100for deploying an application from a source environment102to a target environment111. Similarly,FIG. 2shows a diagrammatic representation of deploying an application developed in a development environment102to a target environment111. Development environment102can include any number of development systems such as an application server106. Similarly, target environment111can contain any number of target systems such as a target application server117.

Typically, a developer develops an application in a known good environment (such as an application server106, a database server, or other known good environment). Once a developer has written an application in the development environment102(i.e., the known good environment), the configuration of the development environment can be analyzed and mapped to a representation that is not specific to the development environment. For example, the development server106configuration can be analyzed and mapped to an environmentally agnostic, or environmentally independent, representation of the configuration information. The configuration can then be mapped to the target environment.

A deployment system50deploys an application from development environment102to a target environment111. Deployment system50can include any suitable computer or group of computers with processors, memory, and other components running deployment software52. Deployment system50, according to one embodiment, can connect to servers of development environment102and target environment111via a network (e.g., LAN, Internet, wireless network or other network or combination of networks known or developed in the art). Deployment software52can be responsible for mapping configuration information from server106to server117. Deployment software52can include an export engine110and an install engine115. Although shown separately inFIG. 1, export engine110and install engine115can be portions of monolithic code, modules, functions or subroutines of code, separate programs or be implemented in any suitable programming architecture. In some embodiments, the functionality of deployment software52can be distributed. By way of example, but not limitation, export engine110and install engine115can run on different computers.

Export engine110can query server106for configuration information related to a developed application (or other code). In general, the configuration information of an application server for an application can be of two types. First, the configuration information can be information that depends on the server environment such that the configuration information will change from application server to application server. The second type of configuration information does not change based on the server environment, though the format for expressing this information may change. Non-environmental configuration information can be extracted from a source environment and mapped to the information to the target environment. Environmental configuration information can be extracted from the source environment and the information changed appropriately for the target environment. The separation of configuration information into environmentally specific and non-environmentally specific information can greatly increase the efficiency of deployment as described below.

Environment dependent configuration information can be mapped to values specific to target server117while environment independent configuration information will remain equivalent between server106and server117. Install engine115can map environment dependent and environment independent configuration information to the appropriate format used at target server117.

FIG. 2is a diagrammatic representation of one embodiment of deploying an application from a development server to an operational server in a J2EE environment. These two environments can vary widely. For instance, development environment102can be characterized by frequent changes in the application, the resources needed to support the application, and even in the development environment itself. In an operational environment on the other hand relatively few changes occur. However, the operational environment often requires that more and different parameters be tuned to properly configure the environment for the application.

Exporting Configuration Information

The mapping of source requirements to the target environment can begin with exporting an existing set of requirements. Accordingly, in one embodiment, the export functionality is generally a mapping and abstraction functionality. The general location of configuration information on a server is generally known. For example, J2EE servers typically have Mbeans that represent configuration information. An MBean108is a Java object that represents a manageable resource, such as an application, a service, a component, or a device. Thus, identifying the Mbeans associated with an application server's configuration information allows the identification of the resources necessary to operate the application. Depending on the vendor of the J2EE server application the configuration information will be stored in different Mbeans. Knowledge of a particular server application, however, allows a list, a tree, or other structure to be established that specifies the Mbeans that contain configuration information for the application server. For other types of service environments (e.g., database servers), the information on what data structures hold configuration information can similarly be specified based on knowledge of the vendor's database server application. As new data structures are added by a vendor, the data structures can be added to the knowledge base of deployment software52.

In general, export engine110can interface with an application server through the application server's API and query the application server for the configuration information. Taking a J2EE application development server106as an example of a source environment, an export engine110can connect to the source environment106using the source environment API. To determine which MBeans108to export, the export engine110may utilize a series of properties files and an XML Schema Definition (XSD) tree associated with the application server which is typically known beforehand.

More particularly, the export engine110may walk through the XSD tree for the application server106and once it reaches an element type that represents an MBean108, the export engine110can validate the MBean108type against the properties file. If the MBean type is valid and exists in the properties file, the export engine110can retrieve the MBean and create a development server106specific object modeled on the actual MBean object108found at the development server106. All of the specified Mbeans for the server can be retrieved. Optionally, the configuration information from a server can be translated into a generic representation used by deployment program52to facilitate storage, translation, and management of the configuration information. For example, export engine110can translate object108to an XML object112(referred to as a JMX object herein) and persist the JMX object112to an object tree in the form of a generic XML file104.

With reference again toFIG. 2, the various property files for the source environment106define how the attributes of the source environment specific objects108map to the JMX object112. The attribute values of the JMX object112can have any data type.

The mapping of the source environment MBeans to the generic XML file104can occur because, while there may be various types of source environments (such as WebSphere or WebLogic), they typically utilize equivalent information expressed in different formats. Consequently, that information can be mapped to a format that is not dependent on the type of environment from which it came based on knowledge of how the source environment106expresses that information. Therefore, as new source environments106are developed, or existing source environments106are modified, new mappings between the source environments106and the generic objects104can be developed to allow for the exporting of the configuration information from these new sources.

Generating Generic Configurations

The configuration information, as discussed above, can include environment independent and environment specific configuration information. According to one embodiment, whether a particular piece of configuration information is environment dependent or environment agnostic can be identified. This can occur in a variety of manners. For example, it may be known that a particular MBean contains information that should not vary based on target environment, while another MBean contains information that will vary depending on the target environment. Whether a particular piece of information is environmental dependent or environmental independent can be predefined in deployment program52. In other embodiments, a user may review the configuration information or a subset of the configuration information to specify which pieces of configuration information are environment dependent and which are environment agnostic.

According to one embodiment, deployment software can generate a representation of the configuration information. According to one embodiment, the environment agnostic representation can preserve information that is already environment agnostic and tokenize environment specific configuration information. Continuing with the previous example, export engine110can generate an XML configuration file104. XML configuration file104can hold the environment agnostic configuration information as JMX objects112. On the other hand, for the JMX objects112that represent environment specific information, configuration file104can include a token for the attribute values. For example, if the development application server typically accesses a database at one domain name, but target environments use other domain names, the domain name can be represented as a token ${domain name} that indicates the domain name must be set for the target environment. Again, mapping of information from the source environment to an environment agnostic representation can be facilitated by the fact that while the schemas of the source environments102may vary, they generally express equivalent information in known structures.

Initializing a Program to Configure the Target

After the source configuration information is mapped, that information can be used to configure other target environments111and to install the application thereon. In one embodiment, a run time engine115(e.g., a program) uses an installation atomic116to configure and install the application into the target environment(s)111. As shown inFIG. 2, one embodiment of installation atomic116includes three parts. However, the installation atomic116may also be a logical collection. For example, the application binaries120can be located in a remote location such as a shared drive accessible by the target environment111. That being said, the XML configuration file104can also be one of the components of the installation atomic116. The generic configuration file104holds the non-environment related configuration information (such as information defined by the MBeans108and the MBean attributes that are not specific to any environment). Further, it may hold this information in the form of references to environment specific information.

The second component of the installation atomic116can be the environment properties document118. The properties document118can be in the form of a text file, object, or some other format. Typically, the environment properties document118represents environment specific data that supplements the XML Configuration File104during subsequent installations. For instance, an application may need to access a data source provided by its environment but that is specified by the target environment user. Since different users may specify different data sources, the address of the data source can be represented generically rather than being blindly translated from the source environment106. Thus, these particular properties typically represent information that varies depending on the target environment111. These target specific requirements can be represented by tokens such as ${hostname} in configuration file104with a specific value provided for the token in environmental properties118.

The third component of the installation atomic116of the one embodiment may be the compiled binary artifacts120(or in other words the application). In an application server environment, the binary artifacts120are typically EAR (enterprise archive), JAR (java archive), WAR (web archive), or RAR (Resource Adaptor Archive) files. These are typically provided by a SCM (source code management) build solution.

As mentioned previously, the run time engine115may use the installation atomic116to configure the target environment111and install the application thereon. The run time engine115can also uninstall, update, and status the application (and its environment) as well as run reports on the same. Regardless of the operation to be performed, once the run time engine115is initialized, the run time engine115can perform a sanity check on and validate the XML configuration file(s)104, the environment related properties document118, the compiled binaries120, and the target environment111. Since every target environment111may have a different methodology by which to install (and uninstall) the application, the runtime engine115may proceed based on the target's specific requirements. In this sense, the run time engine115can be described as being “target specific.” However, a generic run time engine which can operate on any target environment111by encapsulating the target's111procedures can also be used. Regardless of the type of engine employed (generic or target specific), the run time engine115may then be directed to perform one or more of the following exemplary tasks: install, update, uninstall, status, or report on the application and its configuration.

Configuring and Installing Applications

In one embodiment, the run time engine115may begin an installation by performing a set of directives that encapsulate the process by which the application(s) is to be installed. The run time engine115can then map the configuration information represented in the environment agnostic XML files104(potentially using the environment properties document118) to create target environment specific objects according to the appropriate schema for the target environment111. Again, the generic representation of the configuration properties (or target environment representation) can be mapped to the format used by the target environment because different application servers tend to utilize equivalent information in known structures. Consequently, equivalent information can be mapped from one structure to another. Run time engine115can configure the target environment111accordingly by installing the configuration information in structures used by target environment111. In one embodiment, the process of configuring the target environment111and installing the binaries120can be wrapped in a transaction. Thus, if any part of the installation fails the installation will then be rolled back to the last known good state. Additionally, as with the other functions of the run time engine115, the changes it effects on the target environment111may be logged for reporting to the user at a convenient time (e.g., at the end of the installation).

Updating Applications

The run time engine115can also perform application updates (i.e., installing a more recent version of the application). The update process of the one embodiment is similar to the install process previously discussed. However, a “look ahead” process may be used to verify the ongoing status of the target environment during the update. The look ahead process checks whether particular configuration information is already present at target environment111. For example, the look ahead process checks, before each MBean (or similar object for non J2EE environments) is configured, to determine whether a particular MBean already exists (for cases in which an MBean is being added) and whether a particular MBean is already absent (for cases in which an MBean is being deleted).

While the look ahead process is not required, it does increase the efficiency of the process. Accordingly, each of the functions of the run time engine115can employ a look ahead process. Additionally, for non-transaction based variations of the run time engine115, the look ahead process allows the engine115to detect situations which might abort script based configuration procedures. For instance, when a scripted configuration encounters an MBean that it expects to install (or fails to find one it expects to delete), the script fails resulting in an indeterminate and undesirable state for the target environment111. Thus, the look ahead process avoids this “brittle” nature of scripts.

As an example of the benefits of using the look ahead process, if the run time engine115is to update a specific MBean in the target111, the run time engine115can query the target111to determine the status of that MBean108. If the MBean in question does not exist, but is needed, then the run time engine115will create the MBean and set its attributes accordingly. However, if the MBean already exists, the look ahead process allows the run time engine115to verify the MBean attributes and, if needed, to adjust them accordingly. Preferably, as with the install process, the update process can be wrapped in a transaction. Thus, if the update fails, the target environment111can be rolled back to its last known good state.

Uninstalling Applications

The uninstall process is similar to the install process except it operates in reverse so that configuration information can be deleted using the configuration file101. For example, any MBean listed, or otherwise represented, in the configuration file104can be removed from the target environment111. However, in one embodiment, the run time engine115queries the target environment111to determine if any other application might be using the MBean. If so, the MBean is left as is. Regardless of how MBean deletions are handled, the uninstall process can be wrapped in a transaction too and can log changes it causes for reporting, roll back, and other purposes.

Application Status Reporting

To status an application, the run time engine115may also use a look ahead process similar to the one described previously. One difference between the update and status processes is that objects are not changed in the status process. Instead, the run time engine115runs through the installation without actually executing the installation steps and logs and reports the changes that would otherwise have been made if the current version of the application had been installed. One benefit of this operation is that it allows the user to understand what will change if, and when, the installation does occur.

Reporting Configuration Changes and Differences

The Report Differences process allows the run time engine115to determine differences in a given target environment111that may have occurred over time, regardless of topology. This process may operate by querying a target environment to determine the environment specific and environment agnostic configuration information previously discussed. Then, by comparing the newly acquired configuration information with a previous version of the configuration information, the Report Differences Process may determine whether any differences exist between the two configurations. Regardless of whether the changes were caused by legitimate configuration activity, inadvertence, or malicious attack the process allows any changes in the environment to be identified.

For example, the run time engine115could accomplish this task by performing an export (as discussed herein) coupled with creating an object tree using the information obtained during the export. The configuration of the target environment following the last known operation on the environment (or last known good XML file104) can be used to generate a second object tree. The two object trees can then be compared to identify changes such as the existence of Mbeans108in one environment or differences in the associated attributes or their values. In another embodiment, the run time engine115can create an XML file104for a particular target environment before a change (e.g., install, update, or uninstall) is made and compare it to the XML file104created after the operation. The differences thereby identified can then be committed to other similar target environments111to modify them in a similar manner.

Generally, with reference toFIG. 3, a flowchart illustrating one embodiment of a process of mapping a source environment to a target environment is shown. Application servers such as server106(shown inFIG. 1) can be queried for, configuration information (operation12). The queried configuration information can then be classified depending on whether the information is environmentally dependent (operation14). Each piece of configuration information can be accessed (operation16) and processed. A piece of configuration that is environmentally independent can be mapped to the data structure used by the target environment (operation20). A piece of configuration information that is environmentally dependent can be mapped to the target environment by selecting the value of the parameter for the target environment (operation22) and structuring the information in the format used by the target environment (operation24). Operations20,22, and24can be repeated for each piece of configuration information. Mapping configuration information from a source environment to a target environment can take any number of steps and, as discussed below, can optionally include mapping configuration information to an environmentally agnostic representation as discussed below. The method ofFIG. 3can be repeated as needed or desired.

FIGS. 4 and 5illustrate additional exemplary methods. More particularly,FIG. 4shows a method for mapping source requirements to a generic configuration document104(seeFIG. 2) and a target specific properties document118(seeFIG. 2).FIG. 5shows a method of reconfiguring the target environment111during several types of operations. These operations typically include installing, updating, de-installing (i.e., uninstalling), reporting, and providing status of the application.

The method ofFIG. 4can begin with identifying the environment already existing on the source server106(operation202). Typically, application servers106run server programs such as WebLogic (available from BEA Systems), WebSphere (available from IBM), or other server program which in turn provide mechanisms for the applications running on the server106to access the various resources on the server106. Other readily available server programs such as OAS, JBoss, Tomcat, Apache, Netweaver, and Sun One also fill similar rolls. With the source environment106identified, the method can then proceed with locating the XSD tree associated with the application of interest as shown at operation204.

In operation206, the application server106can be queried for each type of MBean108that might be associated with the application to determine how many MBeans108of that type exist and what properties and attributes they possess (operation208). The query for a particular type of MBean108can continue until all of the MBeans108of the type have been identified and cataloged (along with their attributes)(operation210). The next type of MBean108can then be cataloged until all of the MBeans108have been cataloged (operation212). In operation214, the cataloged MBeans108can then be converted to generic data structures such as JMX objects112(seeFIG. 6).

At operation216, a configuration file can be created that identifies environment dependent and environment agnostic configuration information. For example, XML file104can be created based on the JMX objects112that include the environmental agnostic attributes and provides indicators of the environment dependent attributes. The values for the environment dependent attributes can be stored, for example, as a set of property files. According to one embodiment, XML document104can include all the configuration information. The XML document104is then parsed with a set of rules for determining into which category each piece of configuration information falls. For example, suppose that a particular data source appears in the XML document104as:<DataSource Name=DS1′JNDIName=‘com/domain/datasource/DS1’/>
The JNDI name will possibly change from environment to environment and unless the JNDI name is adjusted for the target environment111the configuration will typically fail. Thus, one rule in the set can be that all JNDI names will be treated as environment related information and will be placed in the environment properties document118. Another example arises from network topology. At times, it may be necessary to configure an application on two different environments. One environment may be a 2-way cluster while the second environment may be a 4-way cluster. Thus, one rule in the set can be that topology information will be treated as environment related information and will be placed in the environment properties document118. Still another example relates to the specific database vendor being used. At times, an application may be deployed in different environments using different database vendors. Thus, one rule in the set can be that database vendor information and appropriate database connection libraries will be treated as environment related information and will be placed in the environment properties document118. Thus, these rules can categorize individual pieces of configuration information and can be predefined based on knowledge of the application servers, the development environment, and/or the target environment. Exceptions and newly needed rules can be handled on a case-by-case basis. To account for the environmental information taken from the generic XML document104, operation217replaces the environmentally related information with a token in the XML document104. As a result of this abstraction, the XML document104becomes generic to the particular application and thus independent of any particular environment. Also, the environmental information can be collected in a separate document of environmental properties118.

Other source environments can be queried to create a library of possible environmental property documents118(operation218). When a new target111is identified, the library can be searched for a matching, or closely matching, set of environmental properties118. The closest match can then be quickly adjusted or tuned to account for the actual target environment111. Target environment properties can be determined based on querying target environment111to create a target environment properties file118. Information can also be provided to target environment property file118by a user.

The collection of binary files120that define the application can be obtained as in operation220. Then, operation222can be used to validate the installation atomic116at a convenient time. Likewise, if desired, operation224can be used to validate the target environment111. In operation226, the user can select which operation (install, update, uninstall, status, or report) to perform on the target environment111. Also, at a convenient time, the run time engine115can encapsulate the procedures that the target environment111uses for the selected operation (or possibly all of the target operations if desired) (operation228).

At this point it is noted that the run time engine115has available to it what will be installed (the application along with the application related generic configuration file104); how to install it (the target environment111related procedures); and details regarding where it will be installed (the properties file118). In other words, the “what,” the “where,” and the “how” have been separated in the abstraction hierarchy of the one embodiment. Thus, the configuration of the target environment111for the application is separated from the implementation of the “how” and the “where” thereby simplifying and facilitating the overall configuration and installation process. Accordingly, the run time engine115can simply execute the selected operation when desired (operation230).

Now with reference toFIG. 5, an embodiment of a method of configuring the target environment111and pushing the application out to the target environment111is illustrated. Initially, the method300can begin by starting a transaction for the selected operation (operation302). Preferably, as the method continues the run time engine115begins looking ahead (operation303) at each specific configuration task before actually implementing it to determine (operation304) if any unusual situations might exist (e.g. a resource to be installed or deleted is already installed or deleted). If the run time engine115determines that such a situation exists, operation305allows the engine115to adjust for the situation without failing (e.g., skipping the installation or deletion). Additionally, the run time engine115can log the configuration changes as they are made as reference306illustrates.

Otherwise, the method continues for each configuration task in the application related configuration document104replacing the tokens with target specific information from the environmental properties document118as it goes (see operation307). If any target specific configuration tasks are found in the environmental properties document118, they too can be executed in operation308. Once the target111is configured, the run time engine115can install, update or delete the binary files116of the application (as determined by the operation selected in operation226ofFIG. 2) and report to the user the changes made as shown by operation312.

If the selected operation is the creation of a prospective change report (to determine what would change if an operation were to be performed), then operation314allows the run time engine115to abort the transaction. Doing so can cause the run time engine115to roll back the changes (operation316) made during method300with the report of operation312optionally serving as the prospective change report. Operation316illustrates the roll back of the changes. Otherwise, the transaction terminates with operation318as shown inFIG. 5.

In some embodiments, the software code comprises computer program instructions which can be stored on one or more computer readable media and executable by a processor. The term “computer-readable media” encompasses all types of data storage media that can be accessed and read by a computer. Examples of computer-readable media include computer memories such as read-only memory (ROM), random access memory (RAM), flash memory, and data storage devices such as floppy disks, disk drives, compact-disc ROM, tape drives, data cartridges, optical disks, or other types of non-transitory computer readable media. Microcontrollers that can be programmed to implement embodiments generally include on-chip memories on which the special software code embodying the automatic ranging algorithm/gain selection routine can be stored.

As shown by the foregoing disclosures, various embodiments accelerate the deployment of J2EE applications as well as many other types of programs such as those used in conjunction with networks, database servers, mobile networks, web-servers, and enterprise service buses. Moreover, practicing the exemplary methods described herein eliminates the error-prone, repetitive heartaches associated with the set up, configuration and migration of software running on web application servers (for example) regardless of the vendors, programs, or program versions involved. Developers and system administrators in particular can use the systems and methods taught herein to reduce errors, save time and reduce overall deployment costs. Additionally, the systems and methods disclosed herein catch and eliminate many more configuration defects than heretofore possible. They can also repeatedly guide the migration of applications between environments (e.g., from development to test to production) and automatically transform configurations for server upgrades. As a result, these systems and methods improve the “time to value” associated with a migration by delivering production-ready systems faster than possible with the prior art. They also make comparing configurations manageable, useful and simple. Software designed in accordance with the described embodiments can also be light-weight, fast, and reliable.

In addition, these embodiments take much of the risk and complexity out of application deployments and help organizations create repeatable and predictable installations, updates and un-installs in any environment and on any server. By automating formerly manual tasks, these systems and methods let IT support staff accomplish more with less, minimizing business risk and eliminating “Frankenstein” deployments. Instead, the techniques described herein allow automated migrations and deployments of application changes across systems and networks from development to test, staging, and production. These embodiments also allow comparisons to be made between configurations in one proprietary environment (e.g., WebLogic) and in another proprietary environment (e.g., WebSphere). The environment comparisons of the one embodiment, in turn, allow application support requirements to be translated during an automatic deployment of the application.

These advantages also accrue throughout all aspects of the typical application lifecycle: install, un-install, update, migrate, rollback, logging and export. Furthermore, the disclosed systems and methods allow support staff to pinpoint problems quickly and to gracefully and efficiently roll back changes to the last state, if necessary. Moreover, the robust logging herein disclosed allows support staff to quickly determine the root cause of errors should they occur.

Another embodiment provides for automatically generated installations from a known good instance (e.g., an operational application server) thereby eliminating the need for configuration and installation documentation. Also, because the configuration(s) can be tied to source control, the one embodiment allows abstract configurations to be automatically generated.

Furthermore, the embodiments presented herein provide strong, flexible solutions for breaking through the obstacles of cost, complexity, delay and risk associated with supporting applications. In other words, they make application deployment repeatable, reliable and dependable and assist support staff in deploying and extending applications with greater speed, less cost, and better accuracy. As an added advantage, these embodiments also take the complexity out of understanding deployment environments and help support staff quickly understand each server configuration, what changes were made, and the impacts of those changes. Moreover, the disclosed embodiments also provide mechanisms to easily deploy an application on any application server and in any environment. The exemplary systems, software programs, and related services constructed, or practiced, in accordance with the foregoing embodiments are available in BMC BladeLogic Application Release Automation by BMC Software of Houston, Tex.

Provisioning a Cloud Environment

It can be understand from the foregoing description that embodiments of applications can be deployed to and from a number of physical, virtual and cloud environments. A “cloud”, for purposes of this application, is a scalable computer system or network that can be provisioned to create or mimic a desired hardware and software environment. Because many cloud environments can be provisioned to provide a scalable environment or an environment that can be created on demand, cloud computing is becoming increasingly popular for scalable applications or temporary events. Examples of clouds include, but are not limited to, Amazon Web Services' Elastic Compute Cloud (“EC2”), Vmware vCloud, Rackspace managed clouds, and other publicly available clouds. Embodiments described herein can also be applied to other virtual machine environments.

While cloud environments provide flexibility and scalability, they add a degree of complexity when installing applications because the cloud environment must be provisioned to provide a desired target environment prior to installing the application. Typically, the cloud is configured using an API made available by the cloud provider. A user can configure the cloud to provide an environment having particular processor, memory, network and application specifications. Once the environment is configured, the application can be deployed, versioned, uninstalled, etc. as described above. Many cloud APIs, however, require familiarity with the API that most developers do not have. Consequently, provisioning the cloud is a time consuming process. Once the cloud environment is provisioned, an application can be installed, updated, etc. as described above.

Embodiments described herein can be used to more efficiently provision a cloud environment. A snapshot of a specific environment can be taken and the characteristics of the environment mapped to abstractions of the characteristics. Additional characteristics can be provided by a user to change or augment the characteristics from the snapshot. A user can be led through the process of taking a snapshot and specifying environmental characteristics in a manner that does not require knowledge of the API. The characteristics or abstractions for the specified environment can be mapped to particular API calls to form a machine image that is used by the cloud provider to instantiate a desired target environment. When the target environment is running in the cloud, an application can be deployed.

FIG. 7is a diagrammatic representation of deploying applications from a source environment605to a cloud environment610with a deployment system615. Cloud environment610can provide a system of computers (potentially distributed across the globe) that can be provisioned to provide an environment with desired hardware and software characteristics. The provider of cloud environment610will often provide an API612for provisioning cloud environment610. API612can be used to specify a machine image, which is a set of specifications that can be used to instantiate a desired target environment614in cloud environment610.

API612can allow a user to specify hardware for target environment614including, but not limited to, a CPU, memory, storage, the number bits for the platform (e.g., 32 bit or 64 bit application platforms), I/O resources and other hardware information. API612can also allow for selection of software including, but not limited to, operating systems, database server applications, batch processing applications, web hosting applications, application development environments, application servers, media servers and other software. In some cases, a specific version of the operating system or other software can be selected. Rather than requiring selection of each hardware resource, however, some API's allow selection of an image type (e.g., small, large, extra large, etc.) that has a predefined machine image with a specified CPU, memory, storage, platform, and I/O resources. The predefined machine image can be modified to include selected software or other resources. When the selection of hardware, operating system and software is complete, the machine image can be stored as a file, in a database, or according to any suitable data storage scheme. The provider of cloud environment610can instantiate the machine image to provide an instance of the desired target environment614.

Amazon Web Services, LLC, for example, provides the Amazon EC2 API that allows a user define an Amazon Machine Image (“AMI”) that specifies all the information necessary to create an application server or environment instance in the EC2 Cloud. The EC2 API allows a user to select an image type with a set hardware configuration, operating system and software or create a custom AMI. The AMI can be stored on a server and instantiated as needed to create an instance of a target environment in the EC2 Cloud. Multiple instances of the machine image can be instantiated to scale target environment614as needed.

In operation, deployment system615can be used to provision cloud environment610to provide target environment614and deploy applications from source environment605to target environment614. Source environment605can be a physical, virtual, cloud or other environment (e.g., as illustrated by source environment615and virtual environment617). Applications620and625can be developed in or already be deployed in physical environment615and/or virtual environment617. According to one embodiment, an integrated development environment (“IDE”)630can be used to develop applications620and625.

Deployment system615can run a deployment program635to deploy applications from IDE630. In one embodiment, the deployment program635can be implemented as a plug-in to IDE630. In other embodiments, deployment program635can be implemented as a separate program, as a portion of IDE630, a portion of another program, as multiple programs or according to another suitable software architecture. The advantage of providing at least portions of deployment program635as a plug-in is that a developer can both develop an application and prepare the application for deployment in a single application environment.

Deployment program635can extract non-environmental configuration information for applications620and625and provide a user interface640to allow a user to specify environmentally dependent configuration information to create an installation atomic645and installation atomic650for applications620and625. In some cases, the environmentally dependent configuration information can be set based on dynamic information from an instance of the target environment. For example, environmentally dependent configuration information may include the IP address of the target, the available memory of the target or other information established when the target environment is provisioned.

If an instance of a target environment614is already provisioned in cloud environment610, installation atomic645and installation atomic650can be deployed to target environment614. However, provisioning cloud environment610can be a time consuming task as many APIs612are complex and unfamiliar to those who do not often use them. To aid in deployment of applications into cloud environment610, deployment program635provides for provisioning of cloud environment610into desired target environment614in a manner that reduces the complexity to the user.

According to one embodiment, deployment program635can take a snapshot of the hardware in source environment605or another specified environment. This can be done through the use of APIs, system administration tools or from IDE630. Deployment program635can use the snapshot to determine hardware characteristics such as CPU, memory, storage, I/O resources, platform (number of bit platform) or other hardware characteristics. While in some embodiments, the snapshot may only include hardware characteristics, in other embodiments deployment program635can also determine an operating systems, application servers, database servers and other software information that can be used to provision cloud environment610. The hardware and software characteristics) can be abstracted into classes of hardware, hardware requirements, classes of software, software requirements or other abstraction that can be mapped to API612.

Deployment software can present a user interface655to allow a user to select various characteristics for provisioning cloud environment610including any of the hardware or software characteristics, topology, how the application should be metered or monitored or other characteristics. The user can be given the option to change all or some of the hardware or software information determined from the snapshot. According to one embodiment, user provided configuration information can be collected through configuration wizards that present cloud configuration options in an understandable format without requiring that the user have knowledge of API612. The configuration information that can be selected by a user varies with cloud environment610. Some cloud environments, for example, allow a user to select whether instances of target environment614should run on clustered servers in one or more regions of the world, while other cloud environments may not include this option. Thus, the options available to the user may depend on the cloud environment into which an application will be installed. Additionally, deployment program635may only allow the user to select a subset of options that could otherwise be configured through API612.

Deployment program635can store the desired environment hardware and software characteristics or abstractions of the characteristics in cloud configuration information660. This information can be stored in any suitable data storage format including, but not limited to one or more XML files having a schema, a database, a text file or other data storage format.

Deployment program635can interact with API612to provision target environment614. In cases in which there is not an exact correspondence between the configuration information660and the available resources through API612, deployment program635can apply rules to determine how to provision target environment614. For example, if API612only makes available machine image types with preselected hardware and does not allow a user to specify a particular CPU and memory, deployment program635can treat hardware information in cloud configuration information660as minimum requirements and interact with API612to select an image type meeting those minimum requirements. Similarly, if cloud configuration information660specifies a particular version of an application server but that version is not available in cloud environment610, deployment program635can include rules to select a compatible application server in cloud environment610using API612. Any number or types of rules can be provided to provision cloud environment from cloud configuration information660.

In another embodiment, deployment program635can map abstractions of hardware or software in cloud configuration information660to appropriate interactions with API612. As an example, assume CPUs in cloud configuration information are represented by an abstraction of processing power (e.g., small, medium or large). Deployment program can be configured to make particular API calls to API612based on whether the processor is specified as small, medium or large. The machine image formed will specify an appropriate processor for the abstraction while not necessarily being the same processor that appeared in the original environment. It should be noted that while in the simple example above the abstraction represents a single hardware resource, an abstraction may represent multiple resources, an environment as a whole, or a subset of specifications of a resource. Furthermore, the mapping between cloud configuration information660and API612may depend on multiple pieces of information. The use of abstractions reduces the complexity of deployment program635, eases expandability for new APIs and makes updating deployment program635to account for changes in APIs612more efficient.

When an image for target environment614is provisioned, deployment program635can return any necessary information to a user, such as log-in information, the storage location of machine image files or other information. Additionally, deployment program635can set environment dependent parameters for installation atomic645and650. As just one example of this, if target environment614includes a database domain name, and the database domain name is an environment dependent parameter for application620, deployment program635can set the database domain name in environment properties118(seeFIG. 2) for application620.

Deployment program635can use API612to cause an instance of target environment614to be instantiated in cloud environment610. Once target environment614is running, applications620and625can be installed as described previously.

While deployment program635is represented as a single program inFIG. 7, it should be understood that deployment program635can be distributed so that different systems, entities or users can control particular functionality.

FIG. 8is a diagrammatic representation of one embodiment of installing an application620from source environment605to cloud environment610. In the embodiment ofFIG. 7, deployment functionally is divided into multiple programs. According to one embodiment, a plug-in735to IDE630can be used to extract application and cloud configuration information. An export engine740can extract environment dependent and independent parameters and allow a user to set environment dependent parameters as described above. In some cases, the environment dependent parameters can be changed later if the values for these parameters change based on provisioning cloud environment610. The application configuration information745can be stored as an installation atomic or according to another suitable data storage scheme.

Snapshot engine750can take a snapshot of a specified hardware environment (e.g., source environment605or another environment) and output hardware and software characteristics of the environment. While snapshot engine750can collect any amount of configuration information, it can also be configured to collect a snapshot of only information that is useful in configuring cloud environment610. According to one embodiment, snapshot engine750can take the specific hardware and software configuration of an environment and create abstracted hardware and software configuration information for the target environment. A user can specify additional configuration information through user interface737or adjust the hardware or software information determined by snapshot engine750. Plug-in735can store a set of cloud configuration information660based on the snapshot and user input. The application configuration information745can be passed to a runtime engine755and cloud configuration information660can be passed to a provisioning engine760.

Provisioning engine760uses the cloud configuration information660to make appropriate API calls to API612to provision cloud environment610. In some cases this may include using or modifying existing machine images765that were established by the provider of cloud environment610or were previously defined. Amazon Web Services LLC, for example, provides a number of baseline AMIs for the EC2 and users can store their own template AMIs. Existing machine images765can include any number or granularity of machine images. The existing machine images can be stored in cloud environment610or another location.

Provisioning engine760can map cloud configuration information660to an existing machine image765and modify it as needed based on cloud configuration information660. As an example, provisioning engine760can map abstractions in cloud configuration information to API calls for a particular machine image having a specified hardware configuration, operating system and application server, and also interact with API612to adjust the amount of storage for the image and the version of the application server. The modified image can be stored as a machine image for target environment614. Alternatively, provisioning engine760can interact with API612to build a new machine image from scratch. Once a machine image is established (represented at770) any number of instances of the machine image can be invoked in cloud environment610to create a desired target environment614.

Provisioning engine760can provide information to runtime engine755, export engine740or other component based on the dynamic environment of the cloud. For example, provisioning engine760can determine the IP address of an instance of a machine image and provide that to runtime engine755. In another example, if the installation of an application depends on the amount of memory available, provisioning engine760can provide the amount of member to runtime engine755so that runtime engine755can perform the correct installation. Thus, provisioning engine can provide dynamic information for the cloud target environment that can be used by the application installation components. Such dynamic information can also be used during other operations such as updating, uninstalling, rolling back or otherwise changing applications in the target environment.

In the example ofFIG. 8, runtime engine755can receive application configuration information745and deploy the application to the target environment through API612or through another API to the target environment614. If needed, some environment dependent variables may be adjusted to account for the target environment614as provisioned in cloud environment610prior to deployment.

Turning briefly to the next figure,FIG. 9is a flow chart illustrating one embodiment of provisioning a cloud environment. At step802, a user selects an environment to snapshot. At step804, a snapshot engine can take a snapshot of the physical environment. The user, at step806, can provide additional configuration information. This can be done through the use of wizards that do not require that the user understand the API for the cloud environment to which an application will be deployed. The snapshot engine or other program can abstract information from the physical environment and user inputs into abstractions that are stored as cloud configuration information (step808). A provisioning engine can map the cloud configuration information to appropriate API calls to establish a machine image (step810) and instantiate an instance or number of instances of the machine image to establish a target environment in the cloud environment (step812). Once the target environment is running, applications can be deployed to the target environment. The steps ofFIG. 9can be repeated as needed or desired.

Returning toFIG. 8, in addition to provisioning the target environment, embodiments described herein can ease administration of the target environment. A user can be presented with wizards or other user interface to specify metering and monitoring rules. The user specifications can be mapped, either directly or through an abstraction, to API interactions to meter and monitor the target environment. A cloud administration engine780can interact with API612to enforce metering and utilization rules established by a user.

The previously provided embodiments are provided by way of example and it should be understood that embodiments described herein are provided for illustration. Application deployment and cloud provisioning can be implemented according to a variety software and hardware architectures. For example, while shown as a plug-in, export engine740and snapshot engine750may be separate from IDE630and may be separate programs from each other. Similarly, various portions of a deployment program can be implemented on different systems, so that, for example, provisioning engine760is remote from snapshot engine750, export engine740is remote from runtime engine755and so on.FIG. 10, for example, illustrates that there can be a number of systems to achieve application deployment and cloud provisioning. In the example ofFIG. 10, there is an application configuration extraction system910, hardware configuration information extraction system915, application deployment system920, cloud provisioning system925, metering system930and monitoring system935. Each of these systems can include hardware, software, and/or firmware as needed to perform functions to deploy an application, provision cloud environment610and administer cloud environment610. These systems can be provided on any number of computers and can be combined on a single computer. Similarly, deployment and provisioning can be implemented using any number of different programs. Furthermore, other operations including updating, uninstalling, etc. can be performed as described above.

One embodiment can be implemented as a set of instructions stored on a computer readable media.FIG. 11, illustrates a deployment system1000having a processor1005, memory1010and a set of instructions1015stored on the computer readable media1020(RAM, ROM, hard drive, optical drive or other computer readable media). A network interface1030can provide for communication over a wired or wireless network. Instructions1015can be executed by processor1005to perform application deployment, cloud provisioning and cloud administration. Deployment system1000can include any additional software including, but not limited to, operating systems, IDE applications or other programs. While shown on a single computer, instructions1015can be distributed as needed or desired.

Although embodiments have been described in detail herein, it should be understood that the description is by way of example only and is not to be construed in a limiting sense. It is to be further understood, therefore, that numerous changes in the details of the embodiments and additional embodiments will be apparent, and may be made by, persons of ordinary skill in the art having reference to this description. It is contemplated that all such changes and additional embodiments are within scope of the claims.