Last week I wrote about the fact that IT organizations are now executing an "and" cloud computing strategy, in the sense that their future plans include (most likely) an internal cloud based on VMware and an external cloud (most likely Amazon Web Services).
I pointed out that the traditional model of managing virtual machines--creating a VM template that contains all the software components that the VM contains--is inappropriate in a world in which applications may be deployed internally, externally, across both internal and external clouds, and even transferred between internal and external clouds. This is due to the fact that the virtual machine images are typically incompatible across deployment environments.
V2C Outdated For Today's Cloud Application Lifecycle
One solution often proffered is to put a template image through a conversion process (commonly referred to as virtual-to-cloud, or V2C) to make it able to run in another environment. There are two problems with this solution, however.
While V2C is efficient for a one-time, one-way conversion, it's a nightmare in an environment in which images must be run in multiple places. Trying to repetitively convert images is labor-intensive and error-prone.
Even more challenging is the fact that the mental model of conversions is increasingly outdated in today's IT world. The vision underlying the conversion process is that of a stable image with static software components that rarely change. The reality is that today's applications are constantly evolving with changes going on continuously. The entire agile movement is directed against large, static releases, recognizing the fact that the "Big Bang" release theory too often delivers obsolete code well past deadline.
The new model is frequent small code releases with small amounts of incremental functionality. In fact, there's a name for this approach: continuous integration. This process lets you constantly check progress and make quick course corrections long before you're lost and becalmed. This agile approach militates against the "one and done" conversion approach.
Given these two issues, an operations approach that is based on transferring large static templates around is doomed. Simply put, the speed of application evolution finds the plodding pace of template conversion and movement intolerable.
Some IT organizations seek to segregate development from deployment, applying agile development to create software releases that are then moved into a traditional production operations model. The thinking is to evolve the software rapidly in development and then manage the rollout according to time-tested operations principles. The common outcome of this is dissatisfaction and conflict between development and operations.
DevOps Brings Agile Approach
The simple truth is that applications are increasingly being assembled from many small components, which are aggregated into an integrated collection that operates as a single deliverable. The development and deployment approach must support constant change in individual components and continuous integration of all components into the final deliverable.
Instead, there needs to be an approach to development and operations across all phases of an application to achieve application agility, which enables business agility. That need is intuitively obvious once one accepts that rapid application evolution is never-ending, not an occasional exception or irritating interruption.
The solution to the cloud application lifecycle challenge is clear: An approach to application assembly, delivery and deployment that can support continuous development and integration and that is used by all parties in the IT delivery chain. The shorthand phrase used to describe this collaboration with development and operations is DevOps, and it affects every technical group within IT.
The key feature of DevOps to focus on here is what this solution implies for application assembly and deployment in a cloud environment--especially a cloud environment in which the final image must be capable of running in dissimilar cloud environments.
Rather than the traditional two-step approach--creation of a large template that is then deployed in the runtime environment--this approach implies a three-step process, each managed by a different tool that cooperates to automate the entire process.
Step 1: Resource Manager
In the figure, the Resource Manager is the cloud orchestration stack. The manager's core task is to automatically combine, or orchestrate, the resources necessary to create the right virtual machine. For example, this manager coordinates putting together a virtual machine with 4 GB of RAM, a network connection with a particular IP address and 360 GB of disk storage.
Part of the virtual machine this manager installs is the image operating system. Unlike the legacy approach of each image containing an entire software payload, in this environment the image is a stripped-down operating environment, just enough to boot up a basic operating system. This operating environment is sometimes referred to as JeOS, for Just Enough Operating System. Its purpose is to provide a runtime environment for the application payload--the software packages that implement the functionality that the cloud virtual machine is supposed to provide. Each deployment environment, whether internal or external, will have one of the stripped-down JeOSs for every necessary OS; for example, the internal and external cloud environments will each have a Windows 2008 virtual machine, a RHEL virtual machine and so on.
Step 2: Configuration Manager
The Configuration Manager, meanwhile, injects the appropriate software packages that transform the JeOS into the right execution environment. Configuration management is a key step in this application approach, since each VM "personality" is comprised of numerous packages and configuration settings, all of which must be implemented correctly for the virtual machine to operate properly.
Moreover, given the frequency of change due to application evolution, not to mention the large numbers of VMs due to application scale, the configuration step must be consistent and avoid errors. If humans were to execute this step, misconfigurations would be constant; by using a Configuration Manager, the execution is consistent and flawless.
Configuration management is an area of high interest right now for IT shops, with names such as Chef, Puppet and CFEngine on everyone's lips. To be clear, automated configuration that can be quickly, repetitively and consistently executed will be a core skill to address tomorrow's cloud application lifecycles.
Step 3: Cloud Manager
The Cloud Manager is the final Manager in this process. Cloud users interact with this tool to kick off the entire provisioning process. Key features of the Cloud Manager include the following:
a portal for end user interaction (self-service)
application definition (what types of VMs are needed for the app and are therefore provisioned by the Resource Manager and configured by the Configuration Manager)
application deployment
Critically, this layer directs the deployment process, guiding the two other managers as to what cloud environment the application virtual machines will run in and how the different servers within the application should be deployed. Additionally, this layer controls the configuration of the application itself--communicating to each virtual machine the IP addresses of the other servers in the application, for example.
A less obvious implication of the need to frequently adjust application deployments between different cloud environments is the need for a management tool that can subsume the requirements to deploy to different clouds and automate the process, hiding the syntactic and semantic differences among them.
Many people question the need for a Cloud Manager when they first consider deploying applications into the cloud. As with many other types of IT automation, the need only becomes clear when the number of applications to be managed grows from a handful to tens or dozens. Complex cloud configurations can be extremely difficult to manage, and trying to juggle many of them taxes operations groups to the breaking point. Just as the need to support complex server configuration gave rise to configuration managers, so, too, will the need to support complex cloud application deployments impose the need for sophisticated cloud management capabilities.
Common Approach to Cloud Application Lifecycle Won't Work
Last week I wrote, "The reality is that every IT organization is going to have an 'and strategy: Infrastructure will be a mix of private and public cloud computing. For most, that will mean some mix of private resources and Amazon Web Services." I summed up the inadequacies of the established approach to this "and" hybrid cloud requirement thusly: "The solution must be capable of taking software components and creating an appropriate image for any target environment. The common approach of creating virtual machine templates does not support this solution."
Examining the implications of the requirements of agile application lifecycle and deployment in a malleable hybrid cloud environment makes it clear that a new approach to application management is necessary. Linking resource, configuration, and cloud management will be key for enterprises going forward.
Bernard Golden is the vice president of Enterprise Solutions for enStratus Networks, a cloud management software company. He is the author of three books on virtualization and cloud computing, including Virtualization for Dummies. Follow Bernard Golden on Twitter @bernardgolden. Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.