The growing use of Infrastructure as a Service to run custom applications, SaaS, and PaaS offerings is increasing the demand of management solutions to leverage the automation offered by IaaS.  One of the biggest advantages of IaaS is the ability to automate tasks which were not possible before.  E.g. a crashed server can be restored with an API call by launching a new instance.  Effective use of the IaaS APIs can dramatically reduce the time and resources it takes to deploy and provide production support for services and applications.

Various solutions and standards are available for automating the application management tasks which are usually performed manually.  Before looking at various solutions and standards, let’s take a look at what is needed to fully automate the deployment and runtime management of applications and business services on IaaS.

1. Low level orchestration for configuring cloud resources.  E.g. launching cloud servers and configuring them via dynamic scripting, performing lifecycle tasks.
   

2. High level orchestration for handling complex workflows and long running processes. E.g. ability to bring up an entire multi-tier application stack with a single click, performing dependent workflows spanning across multiple application tiers and distributed components.

Some of the common tools and approaches which handle low level orchestration are solutions like Puppet, Chef, RightScripts along with RightScale Server Templates, etc.  In Kaavo IMOD, we handle this type of automation using Actions which dynamically generate scripts or configuration files.  The files are generated and copied on the servers just in time using the Velocity Template Engine and the available deployment application metadata.  Unlike other approaches, Kaavo Actions don’t require software agents, see my blog on agent vs. agentless cloud management approach.

A very basic use case for High-level orchestration is the  ability to bring up an entire complex multi-tier application stack with all dependent resources and services with a single click.  Standards and solutions addressing this are Amazon CloudFormation Service, Kaavo IMOD / Kaavo System Definition, OVF, and TOSCA. OVF is one of the early standards which tried to tackle this basic use case using custom images and using startup time delays for ordering the boot sequence for servers (e.g. bring up application server 60 seconds after the database server).  OVF standard is from the pre-cloud virtualization days when there was no IaaS and hasn’t kept up with new developments, e.g. there is no concept of dynamic configuration or runtime maintenance workflows for an application.  Also, maintaining images for all the dependent servers as a part of the OVF package makes it difficult to apply and maintain patches on a running application.  In Kaavo IMOD, we do support OVF by providing the ability to bring up vApps as part of our integration with vCloud Director.

Amazon CloudFormation Service captures the higher level orchestration for bringing up the entire service stack; however, you need to use it with your own custom scripts or external low level orchestration solution like Chef or Puppet to properly configure the resources.  Kaavo IMOD handles the high-level orchestration using a workflow engine.  Kaavo System Definition captures both high level and low level orchestration information in one XML file and then Kaavo engine uses the information in the System Definition (XML) to automate both the deployment and runtime management of the application or service.  For more on comparison of Amazon CloudFormation Service and Kaavo IMOD please refer to my earlier blog on the subject.

Topology and Orchestration Specification for Cloud Applications (TOSCA) is an interesting emerging standard, it is in very early stages and there is no working implementation for TOSCA.  Version 1.0 draft of the specification was recently published.  At a high-level, TOSCA vision is very similar to what we are doing at Kaavo, i.e. capture the deployment and operational behavior of a service or application in one template to not only achieve automation but also to achieve portability of an application across various clouds.  We believe that the biggest benefit of using cloud will come from leveraging cloud to automate the operational processes for deployment and production support of applications.

Interestingly, similar to Kaavo, TOSCA is using XML to capture the deployment and management information for any given application.  The major difference between TOSCA and Kaavo System definition is that TOSCA calls for using BPEL (Business Process Execution Language) for specifying the operational behavior of the services.  At Kaavo, we allow users to define workflows by sequencing one or multiple actions in response to any event.  So for example, if you have to shut-down a database cluster, as a part of the shut-down process you may have to run vendor provided scripts or tools to take a backup of the database before shut-down. You can’t do these types of tasks using BPEL as most of the current software and middleware packages don’t provide web services api for performing this type of low level orchestration work and we have to use the tried and tested command-line tools.  We will keep an eye on TOSCA as it evolves and matures.  At Kaavo we have already have an implementation which is very close to TOSCA vision, to learn more about how we have done it, checkout IBM Developerworks article on Application Centric Cloud Management.  Also checkout the guide for Kaavo System Definition.