Automating the deployment and runtime management of large application deployments running on multiple cloud resources across various cloud providers is a challenging problem.  Managing remote resources is not a new problem the big difference is that in cloud the resources are added and removed dynamically and at a larger scale.  Before cloud, people built management systems using two approaches:

1. Agent
2. Agentless
   

Historically the major trade-off between the agent and agentless approaches has been control vs. rollout time and maintenance costs.  You usually get more control with the agent approach compared to the agentless approach.  Whereas, the agentless approach is easy to deploy and manage as it doesn’t require rolling out new agents and maintaining their versions.

At Kaavo, for deploying software and performing runtime configuration management we chose to use SSH instead of requiring proprietary agents to be installed on the managed cloud resources.  Some of the design considerations for our decision are as follows:

• Easier Rollout and Ongoing Maintenance:  Using SSH for management gives you the same or more control and security when compared to an agent-based approach, without the overhead of deploying and maintaining proprietary agents on all images across all supported datacenters.

• Better Security:  Both the agent and agentless (SSH) approaches require communication between the group of manager servers and the servers/resources being managed.  As a result, you have to manage the firewall rules on the communication ports (for incoming and outgoing packets) properly on the cloud servers/resources to avoid holes for potential intruders to exploit.  However, since the SSH protocol has been around for a while and has been well-tested on a large scale, it is less likely to have any unknown security vulnerability compared to writing your own proprietary agent or protocol.
  

• Greater Control and Flexibility:  In an agent-based approach, the agent code that is executed on the servers or the server-side scripts can’t be changed on the fly in case there is any unexpected change in the environment.  Whereas in our agentless approach, we generate the configuration scripts and files just-in-time and send them to the servers for execution.  This on-demand just-in-time generation of scripts gives us greater flexibility and control in managing cloud resources.
  

To rollout a scalable agentless approach for cloud management we had to solve some interesting complex problems like managing firewall rules automatically for managed servers in a dynamic cloud environment, handling distributed event queues, and handling execution order dependencies for parallel processes.  We solved these hard problems because we didn’t want to compromise and take the easy way out by using configuration agents.  If you have any further questions about this or want to learn more about why we choose an agentless approach for cloud management, please contact us.

It is interesting to follow Oracle’s journey to the Cloud, starting in 2008 with Larry Ellison's rant about “What the hell is Cloud Computing?” to Oracle’s effort to sell servers as “Cloud in a Box” aka Exalogic Elastic Cloud in 2010.  Finally with the last week’s Oracle’s Infrastructure as a Service (aka Oracle Public Cloud) announcement it seems like Oracle is finally getting what Cloud Computing is all about and is getting serious about it.  Infrastructure as a Service layer is the key innovation on top of the virtualization layer.  From the IT service delivery perspective, IaaS is the foundation needed for achieving the promised time to market and cost benefits of the Cloud.

Last week there was also unnecessary controversy around who has the right Cloud between Salesforce and Oracle, specifically between Marc Benioff and Larry Ellison.  The fact that the airtime was given to the controversy reflects the confusion and lack of understanding about what Cloud Computing is and how various offerings and players fit in the ecosystem.  Salesforce has done a great job in evangelizing SaaS among enterprise customers and making it an acceptable alternative to on-premise software.  However, the fact is, Salesforce.com runs on the legacy infrastructure and doesn’t take advantage of the Cloud itself for delivering the SaaS solution.  The reason is that Salesforce was launched before the IaaS innovation was available.  Almost all new SaaS and PaaS offerings these days are running on top of the IaaS layer and leveraging the benefits of Cloud Computing. E.g. Heroku, a PaaS solution owned by Salesforce, itself runs on Amazon EC2 (IaaS).

Oracle Public Cloud (IaaS) service is not live yet so the jury is still out on how good it will be compared to other Public Cloud offerings by IBM, Amazon, or other players.  At the very minimum one must give credit to Oracle for recognizing that IaaS is the key Cloud Computing innovation and it is needed to deliver optimal higher-end SaaS or PaaS offerings.  Also IaaS is a must for providing flexibility to enterprise customers for running their proprietary enterprise applications.  In comparison Salesforce has yet to deliver any real IaaS innovation, even for running their own PaaS offering (Heroku) , Salesforce team is relying on the IaaS offering delivered by Amazon (AWS EC2).

For more information on Cloud ecosystem and how various players fit in watch this 5 minute video, also checkout my earlier blog on SaaS vs. IaaS: Key trade-off has nothing to do with vendor lock.  Newbies to Cloud Computing can checkout this presentation for the quick overview.

Running cloud applications is the end-game; acquiring cloud servers is only the beginning

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.

It is amazing how I continue to hear people talk about how they are still not familiar with “cloud”, what it is and how it will help their specific business. Just the other day I spoke to a customer prospect who believed they had a private cloud – as it turns out they had a virtual server farm which still could not be accessed through a self-service portal.  But I am not surprised – after years of “cloud-washing” incumbent IT management solutions that cost a lot of money, time, and resources to implement, vendors have dictated how YOU should use the cloud. But, you need to figure out how the cloud actually applies to your specific business.

Several popular websites and companies were impacted by the recent Amazon cloud outage.  It was quite surprising to see that so many of the companies had no backup plans to restore their applications at an alternate location.  Just because we are using cloud doesn’t mean that we should forget all the lessons we have learned over the years in managing IT risks.  There are several ways companies can mitigate their risk exposure due to these types of outages.  For example one of Kaavo’s customers runs their application across Amazon and Rackspace cloud using Kaavo IMOD; a total outage by one provider wouldn’t bring their application down, their virtual servers at each cloud provider runs around fifty to sixty percent capacity.  It is not always advisable to split the application deployment across multiple clouds, e.g. stateful or transactional applications can’t be split due to network latency.  Our own Kaavo IMOD application runs on Amazon, we have a backup plan to bring back our entire application and restore the data from the last backup within minutes on Rackspace cloud using a bootstrap instance of IMOD.  Using Kaavo System Definition File we have captured all the deployment, runtime management, and data-backup/restore information in one place.  Kaavo IMOD takes this information and automatically executes all the steps required to fully restore the application.

Any of the companies who suffered the recent outage could have significantly reduced the downtime and impact of the outage by having a backup plan for automatically restoring their applications.  Large complex deployments have several configurations and tasks that have to be performed to fully restore the application, e.g. restoring the database from backup, configuring DNS entries, starting processes in a specific order, etc.  During my time in enterprise IT, I have been thru several DR test drills.  Almost always, it is very easy to recover the storage servers etc. in the backup datacenters.  However, after bringing back the servers, storage, etc. there are always a list of long painful steps of going thru the DR manuals and executing several tasks manually to restore specific applications.  At the very minimum, companies using cloud should have  a DR plan for restoring their applications at alternate cloud providers.   Using Kaavo IMOD the process for application recovery can be fully automated and executed in a short period of time at alternate site/s without human intervention.  Please contact us if you want to learn more on how Kaavo IMOD can fully automate application recovery in the cloud.