In Part I, I talked about how it is important to think about cloud use from the application's point of view. We need to digitally centralize our best-practice institutional knowledge so that it can be used to easily replicate application environments from development to test, and then on towards production. Centralizing these steps helps you manage and automate what used to be manual labor. But how do you go from securing VMs within the cloud to actually deploying applications and their environments in the cloud with a single click?

Transformation never happens overnight, and must involve systematic change (a roadmap). Many large organizations and small businesses still do not have battle-tested processes in place governing areas such as change management and disaster recovery. Now we've all heard of best practice frameworks such as ITIL and COBIT. If you peel back the onion, you will see that the idea of making sure your house is in order to enable business agility and transformation is the common theme of those frameworks. Deploying and managing applications in the cloud will undoubtedly force you to do exactly that - get your IT house in order - so that you can capitalize on an agile platform that is the cloud. You may have been able to get away with it on-premise, but the speed of the cloud will enable you to correct the flaws.

Many of you have already virtualized to some degree the infrastructure underneath your applications. The optimizations come through establishing best practices for areas such as: change management, lifecycle management (development --> testing --> production), hardware independence & VM configuration, responses to dynamic events (overutilization, underutilization, server recovery, etc.), and timely responses for application health (e.g. the need to restart a particular component due to memory leak issues). In addition, household tasks such as backups and replication batch jobs must be implemented and working. Let's also not forget security at the user and group level. Even if you perform some of these tasks by hand, it's important to document everything so that if you are unable to perform these duties someone else can pick up the baton. If you have Disaster Recovery plans (which you should), the documentation of these steps helps toward this critical business function. You may even be able to lift a lot of these steps from those plans, especially the ORDER in which you execute these steps. Make sure you have also captured the steps to bring your application up from scratch on top of vanilla compute/storage/network resources; for example, what middleware needs to be installed and where can you get those packages from, and what specific software/security configurations do you need to enable your application. As you gain confidence in these best practices, you can then implement automation to execute some of these tasks.

Not all applications can actually take advantage of the cloud. A very good article which I found here captures the basic tenets of a cloud application:

• Periodic Processing - "end of the month" type of processing
• Start Small, Grow Fast - exponential growth of application use
• Unpredictable Burst - on-demand increase in application use
• Predictable Burst - scheduled increase in application use

Remember that moving an application to the cloud does have to be done in one swoop, especially if you are dealing with a multi-tier deployment. Start with the lowest tier and duplicate the steps required to lay down its environment, test it to make sure it is set up for your specific application requirements (connectivity, configuration, etc.), and then move onto the next tier. Using Kaavo IMOD as an example, let's quickly walk through how we can do this.

This is a representation of a 3-tier application's deployment stack, after we have defined the configuration (OS, memory, disk space, etc.) of each of the VMs within each tier based upon their role. You could easily scale this down to start with only the bottom tier (in this example we will look at the db_tier), so that you are focusing only on a particular environment.

IMOD allows you to organize the steps you've captured into logical actions. In this example, the "install-mysql-manager" action contains the steps necessary to stand up MySQL cluster manager; this includes grabbing the software from a particular location, installing a prerequisite package, and then installing the actual product. To the right, you'll see that this particular action applies to the db_tier, where the server role is of type "manager". IMOD will call out to the cloud provider (in this case it is Amazon EC2) and request the type of VM that we configured. When it is time to execute this action, IMOD will connect to the VM securely through SSH, inject the mysql-cluster-gpl.sh script into /root, and then run the script to perform the appropriate steps.

Actions are not limited to executable steps. In the "create-manager-config" action, we will create the config.ini file for MySQL within this same server role in the database tier. You may also want to set up an action to configure your security firewall rules. Note at the bottom right that we can also pass parameters as reference to these actions. In the cloud, you do not know server information ahead of time and so it is important to have the ability to share this information at run-time to configuration tasks.

In IMOD, events are a sequence of actions that will execute for a given cause. In the example above, the "db_tier (tier) startup" event will start up the database tier by executing the actions listed to the right in this exact order. I can now go back to the "RUN TIME" tab and start up the database tier by clicking on the "Start" button. This will grab the appropriate VMs and automate the best-practice steps you just captured to stand up the database environment.

As you implement subsequent tiers to include within this deployment, you will then be able to start the entire application environment with a single click. You may even want to just set up a shell of an environment where only servers are started up and there are no post-configuration tasks to execute, so that you can directly work on the vanilla VMs themselves to understand how on-premise configuration tasks map to the cloud environment; once you've done that, you can then capture them in IMOD as actions and subsequently events. IMOD does not have any direct hooks into any one application, giving you the freedom to describe any application's deployment and then subsequently automate its startup.

You may have noted during all of this that the amount of visibility into the intricacies of standing up an application is very important. By spending time and capturing those steps while moving to the cloud, you will then be able to automate their execution in a standard and repeatable manner. This is important when you think about development lifecycle management, as you should have a consistent cloud environment cloned for development and test, and then ultimately for production. IMOD comes with sample System Definition files, but there is no magic tool to automatically take your custom deployment of a particular application and move it to the cloud. However, by following a methodological approach, you too can get to the point where you can bring up a complex application in the cloud with a single click. Solutions such as Kaavo IMOD can help simplify your use of the cloud, one application at a time.

• CloudPronto Brings Reliability, Affordability to Cloud Servers
• “Lights Out” in the Cloud
• Red Hat's Brian Stevens Explores the Evolution of the Cloud at 1st International Cloud Computing Conference & Expo