CN104246740A - Test and management for cloud applications - Google Patents

Abstract

A system (100) includes an application model (140) to characterize a given application (110) for deployment on a cloud (130). The deployment manager (120) analyzes application requirements for the given application (110) based on the application model (140) and policies (150) associated with the given application (110) and in the The infrastructure resources (160) in the cloud (130) used to implement the application requirements are substantially matched. A test manager (170) is employed to configure and start a test suite for application deployment via said deployment manager (120) for said given application (110).

Description

Testing and Management for Cloud Applications

Background technique

Cloud computing refers to the delivery of scalable and combined computing, storage, and networking capabilities as a service to a network of end recipients. The name comes from the use of the cloud as an abstraction of the complex infrastructure of the network and associated hardware that can operate within the cloud. For example, cloud computing provides services for users' data, software and computing through the network. Such computing power relies on the sharing of resources to achieve coherence and economies of scale over a network (usually the Internet) similar to that of a utility (such as the electric grid). Applications deployed on cloud-enabled resources currently often have to be deployed manually and that consumes considerable management time. The manual steps of deploying an application include infrastructure provisioning and installation. This requires a sound knowledge link from the installation of the application or the deployment of the image to the deployed infrastructure. Manual deployment typically requires many sequences of steps typically initiated by the user attempting to deploy the application.

Description of drawings

Figure 1 illustrates an example of a system that provides automated test management, staging, and deployment for applications.

Figure 2 illustrates an example of a test manager interface for automated testing and deployment of applications in an environment.

3 illustrates an example system for automated deployment and monitoring of applications.

4 illustrates an example system that utilizes closed-loop feedback for deployment and monitoring of applications.

5 illustrates a flowchart of an example method for automated deployment of applications.

6 illustrates an example deployment system for automated deployment of cloud applications.

Figure 7 illustrates an example of a deployment manager that matches the resource capabilities of the cloud with the application requirements of the application.

Detailed ways

FIG. 1 illustrates an example of a system 100 that facilitates automated test management, staging, and deployment of applications. System 100 can provide automation of application 110 by utilizing deployment manager 120 to determine the infrastructure capabilities of cloud infrastructure 130 (also referred to as cloud 130 ) and also by analyzing application model 140 and policies 150 to determine application requirements for application 110 Deployment and lifecycle management. Although a cloud 130 is shown, deployment, staging, and testing as described herein can also be applied to non-cloud environments (eg, local databases and servers). After such a determination, deployment manager 120 can automatically manage the lifecycle of application 110 on cloud 130 where a match is identified (eg, ideal or best effort - closest match). Based on a measure of match proximity and/or other policy requirements, matches are selected and infrastructure can be provisioned/instantiated.

After such matching (eg, an absolute match or closest match) of resources to application requirements, components of the application 110 can then be deployed on the cloud 130 (or non-cloud-native execution environment). The infrastructure capabilities of the cloud 130 can be determined via resource offerings and metadata 160 associated with the cloud. For example, multiple service providers supporting cloud 130 can provide files specifying what types of resources they make available and describe corresponding resource offerings (e.g., resource offerings for three servers available, where metadata specifies memory size or processor speed , load (if instantiated), location, lease conditions, service level agreements (SLAs), scheduled maintenance, etc.).

A test manager 170 is provided to configure and launch test suites for application deployment for a given application 110 via the deployment manager. Test manager 170 is capable of configuring application 110 with a number of tests associated with a number of different operational deployment scenarios. Ability to manage configurations and resulting application deployment across organizational boundaries to suit various organizational needs. For example, development can have one set of requirements and production can have a separate set of requirements. In some cases, a public deployment for the application is configured and launched, and in other cases a private deployment is launched, such as shown via local testing and storage 180 . In other cases, a combination of public and private deployments is started and deployed via deployment manager 120 as configured by test manager 170 .

For example, test manager 170 enables automated development testing, operationally-oriented development and application security development. Application models 140 can be specified for specific deployments or tests. For example, when selecting which model to use, this can be achieved via selection from a different model in a set of models or via matching of tags associated with different model types as specified in the policy. A matching infrastructure can then be employed to test or facilitate production staging while also running various test suites and at different stages of testing (and/or monitoring in production). For development testing, the test manager 170 allows developers to follow the development of any software that has tests in the cloud 130, where they can deploy and run the software in multiple deployment scenarios and perform targeted testing without the usual delays and costs Use cases to build deployment and testing. After development and testing of software elements (eg, application components), they can then be deployed and operated (and similarly monitored) in production. This also enables testing of the security aspects of the application 110, as security can also be tested in a secure development and production environment, such as on local test and storage 180 . Feedback of vulnerabilities, security breaches, and other detected events can be easily monitored and fed back (eg, via monitor components and listeners) to development agents such as for diagnosis and remediation. When a problem is reported in production, the deployment conditions and context can be reproduced along with the bug/problem report for developer (or support) diagnosis and correction, which can then lead to tests and patches that can then be staged and/or tested /renew.

Test manager 170 and deployment manager 120 can be employed to automate testing in accordance with a user interface (UI) (eg, see FIG. 2 ) for configuration and launch of test suites on deployments provided and deployed by deployment manager 120 . This can include providing an automation application programming interface (API) that can be automated based on monitoring changes into the coder repository and launching/running test suites on deployments provisioned and deployed by the deployment manager 120 . The deployment manager 120 can be used to move from test to production, which can be initiated by policy changes in location (in the production zone) and other production criteria regarding capacity, latency, quality of service (QoS), and the like. Other testing scenarios supported by the test manager 170 can include security development, operational development, and quality assurance that can be supported through monitoring and closed-loop feedback of the configuration of the infrastructure. The results of such development testing for a given application can be utilized by the deployment manager 120 for deployment and lifecycle management for the given application. Continuous integration of application components (eg, integrated with existing applications they are developed and stored in the repository) can be supported as they are developed based on the deployment manager 120 . Continuous delivery of software based on automated actions of the deployment manager 120 can also be supported.

Test Manager 170 provides a centralized application management platform for management and automation within and across application teams and throughout the entire process of developing an application, all within a single workflow. Test manager 170 can support stakeholders responsible for delivering applications as they progress through their lifecycles. It focuses on the core lifecycle from design to readiness for delivery to operations. This can include requirements management, test planning and functional testing, performance testing, developer management, and defect management. Such application lifecycle activities can be connected from a workflow perspective with layers of common management consoles, project tracking and planning, and within a consistent repository with a supporting software development kit (SDK) and an open integration architecture. Build on common software.

As will be described below with respect to FIG. 2, the test manager 170 can be programmed to support various functions. This can include example functionality such as Application Lifecycle Management (ALM) with a unified software platform for accelerating the delivery of secure and reliable applications. This includes development management functions that provide a framework for collaboration between developers, testers, and business analysis delivery applications. The test manager 170 can also enable software requirements to be defined, managed and tracked for respective applications. For example, this can include providing repeatable, scalable, automatable functions to manage technical policies and reusable services. Composite applications are supported via interface components to manage high quality, reliable and secure composite applications across the life cycle. Application lifecycle management includes support for software as a service (SaaS). Quality management functions are also supported for applications and deployments. This includes performance verification, where a set of capabilities is provided to test application performance in project-based scenarios as well as other development modes. Modular testing tools are also provided for rapidly developing automated functional test suites for applications.

Using the test manager 170, specified application requirements guide the development of the application. Application developers and specified requirements can be stored in memory to guide the creation of test cases and test suites. For example, these can be defined in terms of configuration, deployment, and usage scenarios. Different test cases and scenarios can be captured as application models 140 and strategies 150 . Representative deployments can be captured as infrastructure templates. Can be done in one click (eg, via a web site that points to templates, models, policies, artifacts and executes the code) to automatically run the test suite in the target configuration. Periodically or after changes have occurred with the application or via manual or scheduled changes, such changes can be automated via the test manager 170 (such as calling an API to pass new artifacts and run tests). Security testing can also test or enable security challenges at various steps of development. DevOps can be enabled by changing policies to migrate to production with selected or determined deployments.

After the application has been deployed based on matching, the deployment manager 120 is further able to manage other aspects of the application's lifecycle. For example, deployment manager 120 can monitor feedback and adjust infrastructure resources based on such feedback. Additionally or alternatively, deployment manager 120 can dynamically adjust application models and corresponding policies based on such feedback or other detected events. Similarly, this can also include instructions to retire older versions of application components (e.g., code, middleware (MW), database, operating system (OS), etc.) Continued deployment in cloud infrastructure 130 .

Cloud 130 can be hybrid such that it can be a combination of traditional data centers made to behave like infrastructure resources, private clouds (cloud technology developed in-house), public clouds (provided by services provider) and managed cloud configurations (managed on-premises or in a public cloud/virtual private cloud). As used herein, the term application applies to a collection of components. Furthermore, an application can consist of, for each of its components, a set of artifacts (eg, installer, executable, configuration, etc.) and a set of components that are installed and interact with each other (eg, code, middleware (MW) , database, operating system (OS), etc.) to characterize. Also, as used herein, the term determination can include compilation, enumeration, and matching.

As used herein, the term "substantially" is intended to indicate that some variation can occur although the function or result of the term being modified is the desired or intended result. In this context, for example, the term "substantially matching" or variants thereof describes a situation where the resulting analysis and comparison is performed to identify resources as identical; however, in practice a match can correspond to a resource sufficiently similar to such that A set of resources that enables a deployment (identified above as an absolute match or a best-effort match). Where more than one such set of resources may correspond to a match, the deployment manager can select the best matching set of available resources. Other methods for selecting such matches can be utilized.

Application model 140 can be employed to characterize a given application 110 for deployment on cloud infrastructure 130, such as through metadata descriptions for the various components of the application. Deployment manager 120 can be implemented via processor-executable instructions or processor-readable data to analyze the application model 140 and policies 150 (or policies) associated with the given application to analyze the application requirements. As will be described below, policy 150 can be provided to describe additional operational context for application 110 (e.g., operate application after midnight, use east coast only servers, maintain load balancing between servers, deploy on a given within a network domain, ensuring that the load is between specified limits on the server, ensuring that there are no upcoming maintenance within a given window, etc. and matching "measured proximity" techniques). Deployment manager 120 can then determine infrastructure resources in the cloud infrastructure that are sufficient to implement the application requirements of application 110 as specified by model 140 and policy 150 .

In one example, deployment manager 120 can automatically deploy a given application 110 on cloud infrastructure 130 after matching the application requirements of application 110 with the capabilities of the cloud as specified by resource offerings and metadata 160 . In such examples, it generally amounts to executing (possibly by invoking external systems that manage infrastructure and/or application lifecycles) the instructions of the other following examples described below. As used herein, the term "application" (eg, including application 110) can include a set of components to be installed and executed. Examples of such components include multiple layered logic, user interface (UI), middleware (MW), database (DB), operating system (OS) in addition to code to install and configure or uninstall such components . Thus, application 110 refers to these collections of components and artifacts that can also include repositories of such components and artifacts. The application 110 can also be identified by pointers to components and artifacts including pointers to individual components or a set of pointers to components. In another example, deployment manager 120 can generate instructions to notify the system (or user) of how a given application 110 should be deployed on cloud infrastructure 130 . In either example, deployment manager 120 can automatically match the requirements of application 110 as specified by model 140 and policies 150 with the capabilities of cloud 130 as specified by resource offerings and metadata 160 .

The system 100 utilizes a policy and model-driven approach to automate deployment as opposed to the manual process of conventional systems. System 100 is capable of dynamically (or statically) optimizing infrastructure resources (characterized by metadata attributes) and binding infrastructure resources to applications 110 based on models 140 and policies 150 characterizing their requirements in terms of infrastructure attributes. This can include matching application metadata with resource metadata and automating optimized or preferred/flagged deployment of applications and their components/dependencies on cloud 130 taking into account policy and context, again without manual deployment steps. In one example, system 100 allows tracking of instances while also supporting automated management of such instances (eg, automated monitoring and feedback described below). Different techniques are provided to ingest, create and design metadata that can also describe infrastructure templates, application models and policies. Such instances can be stored along with applications 110, application models 140, and policies 150 in a database or repository (not shown).

The system 100 can employ a closed feedback loop for monitoring applications (see FIG. 4 ). Such monitoring applications can be utilized, for example, to scale up or down application execution requirements, and to notify appropriate recipients, such as users or other system applications. In one example, listeners can be installed in various components to capture events from monitoring. Events received by the listeners can trigger handlers that can generate lifecycle management operations on the system 100 . Examples of some lifecycle management operations include scaling up, scaling down, moving, unprovisioning, alerting the user or system, and running another executable, which may involve composition of the systems described herein and other applications.

System 100 can be implemented on one hardware platform or across multiple hardware platforms, where modules in the system can execute on one platform or across multiple platforms. Such modules can run on cloud technologies (various forms and/or hybrid clouds) or be provided as SaaS (Software as a Service) that can be implemented on or off the cloud. Ability to automatically deploy complex applications on required infrastructure resources, again without requiring users to understand how to perform such operations. Policies 150 provide automated instructions for operational guidelines that help administrators mitigate deployment errors. Metadata can also be associated with an application by identifying the type of application (eg, via a UI or API), then the user does not have to understand application characteristics. This approach allows for "best practice", recommended or imposed deployment models for applications based on their association with metadata.

Policies also allow application characteristics to be decoupled from other contextual considerations (eg, about the user, about the application, about the infrastructure, about the context, about this particular user, about a particular application, etc.). This facilitates re-use of application models across many applications. Specialization can also be achieved via policies (eg, specifying a specific set of policies for the relationship of one application to another). This is also eg how the system enforces that a certain set of property values is fixed for a given application or version. For example, the system can apply a generic application model for a web application, while in another case, explicitly specify a different model or specific values for attributes of the model. Resources can also be provided from hybrid clouds (eg, some resources are provided from local databases or servers and some resources are provided from Internet services).

For simplicity of illustration, in the example of FIG. 1 , different components of system 100 are shown and described as performing different functions. However, those of ordinary skill in the art will understand and appreciate that the functions of described components can be performed by different components and that the functionality of several components can be combined and performed on a single component. Components can be implemented, for example, as computer-executable instructions, hardware (eg, an application specific integrated circuit or processing unit), or as a combination of both. In other examples, components can be distributed across a network among remote devices. In one example, a topology can be defined, where an application template can include a topology model of which components should be deployed (eg, what components are to be deployed at which location). In another example, the deployment manager 120 can be provided with a topology model and then determine the best infrastructure resource to match it. In yet another example, a topology instance can be created following provisioning of resources and deployment of application components. As disclosed herein, topology instances can be stored and used for later management, monitoring.

FIG. 2 illustrates an example of a test manager interface 200 (also referred to as interface 200 ) for automated testing and deployment of applications in a cloud environment. The interface 200 includes a selection pane 210 that enables source code modification and design, build and launch of test suites, release and deployment options, multi-platform orchestration (e.g., synchronization of events between application components) and manage, run, and secure the application environment. For example, such a selection pane as described herein can also be exposed to other applications via an application programming interface (API). Service and support options 214 include service governance (eg, financial agreements, capacity, vendor information, etc.). The service marketplace options in service and support options 214 include service store, product store, catalog request for fulfillment, usage data, and chargeback information. The support hub in option 214 can include use case exchange and application management details. Option 214 can also include collaborative use case management, such as reporting and tracking of incidents, problems, defects, requirements, changes, and release data for applications. Information database 220 is capable of storing/exchanging data to/from each of the components described herein with respect to interface 200 .

The application lifecycle manager 224 can include options for designing, modeling, building and testing applications including composite or hybrid applications. The service realization component 230 enables service design composition and realization, application modeling, deployment and workload management, and infrastructure design and realization. The Application Performance Module (APM) enables performance testing, analysis and grading of deployed applications. The service operation and bridging component 240 enables event processing, monitoring, analysis and reporting, and interaction with a real-time service model (RTSM) repository. The infrastructure management component 250 provides options for defining/searching system components, network components, and storage components. This includes options for handling/analyzing faults, analyzing application, network and/or system performance and providing various configuration interfaces for configuration options. The resources pane 260 includes options for specifying how the application is to be deployed, including options for deployment on public clouds, managed clouds, private clouds, virtual operations, and traditional deployments (eg, according to standard deployment scenarios).

Interface 200 and the associated test manager described herein (eg, test manager 170 of FIG. 1 ) enable development testers and security developers to have full automation for deployment of applications under test and associated test suites. This includes model-based automation, which further facilitates and speeds up the development process. Interface 200 facilitates the creation of models and configurations to be employed thereby. This can include hybrid delivery models where testing can be on private cloud, public cloud, or testing can be partially on private cloud and public cloud (e.g. in bursts when test capacity is required (e.g. for load testing) ). Tests can be automatically moved from the private cloud to the public cloud and vice versa.

Operations developers are also provided with full automation for the deployment of applications from development and testing to production. This includes full automation of lifecycle management under operations. Model-based automation enables the construction and reuse of models created from similar applications and/or used in development and testing. This also includes testing of hybrid delivery models including public and/or private cloud deployments as previously described. This can include monitoring source repositories to detect changes and to automatically initiate tests. This can also include options for periodic manual and scheduled testing as well.

FIG. 3 illustrates an example system 300 for automated deployment and monitoring of applications. System 300 includes an execution engine 310 for automated deployment of applications. Such an engine can also include a provisioning manager for establishing service level agreements with service providers and can include a deployment manager as described above. Event handler and scheduler 314 can be used to process application events and schedule tasks associated with the application. As disclosed herein, listeners/handlers can be defined and installed for monitoring events. This can include scheduling provisioning/deployment and subsequent lifecycle management operations (eg, tonight or deployment for the next 2 weeks). Configuration monitor 320 and rules engine can be used to configure monitor component 324 that provides feedback from the application and to apply rules and policies for executing the application. For example, system 300 includes a model database 330 that can include application models, infrastructure models, and artifact pointers.

An instance database 334 can be employed to store implemented target instances of an application. The application user interface 340 can be employed to design the application and configure metadata for operating the application, whereas the infrastructure user interface 244 can be employed to specify the infrastructure requirements for deploying the application in the cloud. For example, deployment component 350 can include a deployment application programming interface (API) and instructions such as may be specified via a deployment recipe. One or more call-outs 354 can specify custom operating instructions for a given application. Provisioning components 360 can include provisioning APIs and plug-ins for interacting with various cloud infrastructure components.

System 300 can be utilized as a designer tool to build/deploy infrastructure and application templates. It also allows application developers, testers, or other administrators or designers to build application models. Similarly, they can design policies and rules for the execution and deployment of applications. Some or all of the infrastructure and application data can be ingested into repositories shown as databases 330 and 340, respectively. Alternatively, such infrastructure or application data can be communicated via an API. Application artifacts (code, executables, installation packages, etc.) can also be ingested or referenced via a database or API. For example, the API or portal user interfaces 340 and 344 can be used to syndicate or upload requests for matching and deployment while also specifying the application templates and policies to use. Such APIs and user interfaces can be implemented as part of a designer tool to define and associate metadata with infrastructure (eg, via infrastructure templates and topologies).

Provisioning and setup of agents and monitoring tools can be provided to enable applications to discover instances (which are instrumented and have agents if required). This can be achieved via instructions/recipes that are utilized to deploy infrastructure and application elements after binding the application and its associated components to the infrastructure resources. Events/reports allow closed feedback loops that can be used to scale up/down or update context/policy for future changes (based on policy) if policy allows and notify appropriate parties or systems (see Figure 4 and description below). As noted above, clouds and resource pools may be hybrid entities where some resources are served locally and some are served remotely. Applications can be self-managing with respect to cloud or hardware resources capable of supporting automatic scaling of assurance/monitoring events, workload management, and processing. Such self-management utilizes feedback, for example, to determine performance, change application requirements, and generate alerts as appropriate.

FIG. 4 illustrates an example system 400 that utilizes closed-loop feedback for deployment and management of applications in a cloud infrastructure. System 400 includes a processing unit 410 (or processor) that executes instructions from memory 414, which includes firmware or other storage media for storing computer-executable instructions associated with a computer. Processing unit 410 and memory 420 can be provided as part of deployment tool 420 that deploys application 430 on cloud infrastructure 440 via deployment manager 450 . As shown, feedback 460 is received from deployed application 430 and processed by monitor component 470 . Such feedback 460 may be a state or event from the deployed application 430 that indicates how the application is executing. In one example, feedback 460 can be employed to adjust operating parameters of deployed application 430 that have been set according to previously determined application requirements. For example, a foreground task may be adjusted so that the task operates for a different number of microseconds than it is currently executing. This can include scaling up or down the operational requirements of the deployed application 430 . In another example, feedback 460 may be employed to adjust the operational infrastructure of cloud infrastructure 440 . For example, service level agreements may be automatically renegotiated with cloud infrastructure service providers to increase or decrease available resources to appropriately meet the operational needs of deployed applications 430 .

Computer 480 is capable of operating one or more interfaces 484 to program application models 490 and store in database 494 . The computer can also interact with the deployment tool 420 to alter the deployment and facilitate life cycle management of the application. Interface 484 is also capable of configuring infrastructure templates, changing operational requirements, configuring monitor components 470 , and interacting with events and alarms generated within system 400 . As previously noted, along with execution on the cloud, the deployed application 430 can be spread across unrelated clouds or provided as part of a hybrid application. For example, deployed application 430 can be executed partially on cloud infrastructure 440 and partially on database 494 which is a distinct entity from the cloud (eg, a local server database versus a network database).

In view of the foregoing structural and functional features described above, an example method will be better understood with reference to FIG. 5 . While the example method of FIG. 5 is shown and described as being performed serially for simplicity of illustration, it is to be understood and appreciated that this example is not limited by the order illustrated, as some actions are performed in other examples. Can occur in different orders and/or simultaneously according to the order shown and described herein. Moreover, it is not necessary that all described acts be performed to implement a methodology. The example method of FIG. 5 can be implemented as machine-readable instructions that can be stored in a non-transitory computer-readable medium, such as may be a computer program product or other form of memory storage. Computer readable instructions corresponding to the method of FIG. 5 can also be accessed from memory and executed by a processor (eg, processing unit 410 of FIG. 4 ).

FIG. 5 illustrates an example method 500 for automated deployment of applications. At 510 , method 500 includes processing application metadata modeling a given application (eg, via deployment manager 120 of FIG. 1 ). Method 500 includes, at 520 , processing resource metadata describing resources for cloud execution of a given application. At 530 , method 500 configures a suite of tests (eg, via test manager 170 of FIG. 1 ) for a given application. At 540, method 500 includes deploying the given application in the cloud based on matching the application metadata with the resource metadata to facilitate execution of the suite of tests. Method 500 can also include automatically deploying a given application on at least one of a public cloud or a private cloud. Method 500 can also include monitoring changes for a given application in the repository and automatically launching a suite of tests based on detection of changes. Method 500 can also include automating changes by passing new application artifacts and running tests on the new application artifacts in a periodic manner after changes have occurred with a given application, either via manual changes or via scheduled changes. The method also includes staging the given application in the first environment and moving the given application to at least one other environment.

Method 500 can be performed automatically as part of a system such as the examples depicted in FIGS. 1 or 4 . The system can include memory for storing computer-executable instructions associated with the computer and a processing unit for accessing the memory, executing the computer-executable instructions, and thereby performing method 500 . Computer-executable instructions can include an application model stored in memory to characterize a given application for deployment on the cloud infrastructure, where the application model can be described by application metadata. A deployment manager stored in memory can analyze application metadata for a given application and policies associated with the given application to determine infrastructure resources in the cloud infrastructure. Infrastructure resources can be specified as resource metadata. The deployment manager can automatically substantially match the application metadata with the resource metadata (eg, identify the closest match) to implement the application requirements. A test manager can be stored in memory to configure and initiate test suites for application deployment in the cloud for a given application via the deployment manager. The monitor component can monitor test conditions according to the deployment of the given application in the cloud and provide feedback corresponding to the monitored test conditions for the given application.

FIG. 6 illustrates an example deployment system 600 for automated deployment of cloud applications. System 600 includes application model 610 to characterize a given application 620 for deployment on a cloud infrastructure such as that shown above with respect to FIG. 1 . The deployment manager 630 analyzes the application requirements for a given application 620 based on the application model 610 and policies 640 associated with the given application to determine the infrastructure resources to use in the cloud infrastructure to implement the application requirements. The test manager 650 is capable of configuring and launching test suites for application deployment for a given application via the deployment manager.

7 illustrates an example of a deployment manager 710 for matching resource capabilities 720 of a cloud 730 with application requirements 740 of an application. Resource capabilities 720 can include resource offerings 750 , which may be from a pool of resource offerings offered by multiple resource providers supporting cloud 730 . For example, such resource offerings can include cloud services (e.g., accessible via corresponding Application Programming Interfaces (APIs), existing systems capable of activating and providing such services, or existing external compositions (with parameters of function calls one or more of the chemical workflows/synthesis scripts). Resource offerings 750 can be compiled/ingested from resource providers. Resource capabilities 720 also include resource metadata 760 associated with each resource offering that characterizes attributes of interest for the resource. For example, such metadata 760 can specify location/topology (e.g., for composite resources), hardware, CPU, memory, all Operating systems, other software aspects, and labels included or supported.

Resource metadata 760 can be associated with any resource designed or added to a resource pool by a resource design or ingestion process. Metadata describing the application model and resource provisioning can be captured via a designer (eg, tools, portal UI, or API) to describe the metadata. Metadata including recipes (eg, corresponding to instructions for deployment and other lifecycle management functions such as undeployment and monitoring) can constitute resource templates. Resource metadata 760 and associated resource offerings 750 specified by the metadata can be provided as part of templates (eg, metadata and data files for the offerings) that can be utilized by other applications.

Application requirements 740 for a given application can be specified via application metadata 770 which can be defined at application design time or after application design. This can include components to be deployed individually (eg, multiple applications in multiple tiers). Application metadata 770 can also specify requirements/preferences regarding resources. This can include generic deployment scripts as a workflow or process (asynchronous or synchronous). The deployment script can further include deployment instructions for each component (eg, scripts to run on allocated resources, instructions for services, etc.). This can include associated instructions to deploy agents or prepare for monitoring and/or management. Ability to apply directives across components. In general, application metadata 770 can represent the application model described above with respect to FIG. 1 . A given application model can be stored in memory and utilized by multiple applications to facilitate their deployment. As noted previously, an application can include multiple cooperating components and artifacts (eg, source or executable and installable) that provide the application utilized by the deployment script.

As shown, an additional policy 780 applicable to the application/infrastructure and referencing the context for operating the application can be provided. For example, a policy may specify the location of the application (e.g., operate only on east coast servers), time (e.g., operate after midnight and before 6 am), processing requirements (e.g., specified processing speed and memory needs) and/or load balancing requirements (e.g. no server will operate at more than 50% load), SLAs, availability requirements (e.g. no scheduled maintenance for next x days, etc.), security (e.g. specific network domain or security area).

The application can be deployed by the deployment manager 710 by retrieving the associated metadata 770 and matching based on the best match (which could be an exact tag if imposed, for example, by policy) and the resource offering 750 available in the resource pool. The matching of resource metadata 760 to application metadata 770 may be based on strict specifications (e.g., a processor must operate at 1 GHZ) or capable of a threshold specification (e.g., any processor operating above 500 MHZ is acceptable). accepted) is matched. Thus, a match may be an absolute match or may be a substantial match where the match is a best fit or close to the desired matching criteria. Recipes can be processed by deployment manager 710 and refer to code/artifacts used for application deployment. For example, such recipes can be made available via known repository locations or referenced via pointers to recipes. For example, a topology corresponding to an application's composite resources can be saved by the deployment manager 710 as a new resource type for reuse when similar application metadata is used by another application. Multiple versions of the same application or similar applications can reuse the same application metadata, but, for example, employ different strategies to refer to the operational context.

What has been described above are examples. It is, of course, not possible to describe every conceivable combination of components or methodologies, but one of ordinary skill in the art will recognize that many additional combinations and permutations are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the scope of this application, including the appended claims. Additionally, where the disclosure or claims recite "a", "an", "first" or "another" element or its equivalent, it should be construed to include one or more such elements, Two or more such elements are neither required nor excluded. As used herein, the term "comprising" means including but not limited to, and the term "comprising" means including but not limited to. The term "based on" means based at least in part on.

Claims (15)

1. A system comprising: an application model, stored in memory, to represent a given application for deployment on the cloud; a deployment manager, corresponding to instructions executable by a processor, to analyze application requirements for the given application based on the application model and policies associated with the given application and to substantially match the infrastructure resources required to implement the application; and A test manager, corresponding to instructions executable by the processor, to configure and launch a test suite for application deployment via the deployment manager for the given application. 2. The system of claim 1, wherein the deployment manager is to automatically deploy the given application on the cloud based on commands from the test manager. 3. The system of claim 1, further comprising an application programming interface (API) to monitor application changes in a repository and initiate the test suite of application deployments via the deployment manager. 4. The system of claim 1, further comprising a user interface to configure and initiate the test suite of application deployments via the deployment manager. 5. The system of claim 4, wherein the user interface is further to instruct the deployment manager to move the given application from test to production. 6. The system of claim 5, wherein the user interface is further to enable specifying a destination location for the movement of the given application, specifying capabilities for the given application, or specifying capabilities for the given application. A policy change specifying at least one of qualities of service (QoS) is applied. 7. The system of claim 4, wherein the user interface provides interface options to configure the test suite for application deployment for at least one of a development test environment, a development security environment, a development operations environment, or a quality assurance environment. 8. The system of claim 4, wherein the user interface includes a selection pane comprising a source code selection user interface element, a build test selection user interface element, a version and deployment selection user interface element, a multi- Platform orchestration selects user interface elements and management, operations, and security selects user interface elements. 9. The system of claim 4, wherein the user interface includes a resource pane including configuration function options for public cloud, private cloud, managed cloud, virtual operations, and traditional configuration. 10. The system of claim 4, wherein the user interface includes an automated tab manager for designing, modeling and building test components, for service design, application modeling, workload management and foundation A service implementation component for facility design, a service and operations bridge for configuring events, performance and analytics, or an infrastructure management component for managing faults, performance and configuration of said infrastructure resources in said cloud. 11. A method comprising: Application metadata used by computer processing to model a given application; processing, by the computer, resource metadata describing resources for cloud execution of the given application; configuring, by the computer, a suite of tests for the given application; and The given application is deployed in the cloud by the computer based on matching the application metadata with the resource metadata in order to perform the suite of tests. 12. The method of claim 11 , further comprising passing in new application artifacts in a periodic manner and updating the New applications run tests to automate changes. 13. The method of claim 11, further comprising staging the given application in a first environment and moving the given application to at least one other environment. 14. A system comprising: memory for storing computer-executable instructions associated with the computer; and a processing unit for accessing the memory and executing the computer-executable instructions, the computer-executable instructions comprising: an application model stored in said memory to characterize a given application for deployment on a cloud, wherein said application model is described by application metadata; a deployment manager stored in the memory to analyze the application metadata for the given application and policies associated with the given application to determine infrastructure resources in the cloud, wherein the infrastructure resources are specified as resource metadata and the deployment manager automatically matches the application metadata with the resource metadata to implement application requirements; and a test manager stored in the memory to configure and start a test suite of application deployments in the cloud for the given application via the deployment manager. 15. The system of claim 14 , further comprising a monitor component to monitor test conditions according to the given application's deployment in the cloud and to provide the given application with the monitored test conditions. Feedback corresponding to the condition.