Cloudonomics Journal

This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.

One of the advantages of cloud computing is that someone else is managing the infrastructure – including the servers, network devices and storage systems, not to mention the data center power conditioning, cooling and fire suppression equipment.  One of the costs of offloading this infrastructure is that the cloud becomes something different and separate from your data center.  In most deployments today, the cloud is almost completely isolated from your data center, and this often requires changes in how you manage and interact with your applications.

So what does “management” mean in this context?  I look at it in terms of provisioning resources and managing the infrastructure, operating systems and applications.  Over the years a remarkable set of tools and processes has been developed to handle these tasks in the data center, and the challenge now is how you integrate all this investment with the new cloud deployments.

For provisioning, the cloud has a model similar to a data center virtualized environment, in that you can provision virtual resources from a pool of physical resources.  However, the definition of these resources is dictated by the cloud provider, which means you have to adjust your processes to account for the capabilities and limitations imposed by the cloud, specifically CPU, memory and storage resources.  To be successful in the cloud, you need to match the resources required for your application to the capabilities of the cloud (i.e., pick enough CPU/memory/etc. to meet your application’s requirements while balancing the costs of the cloud resources).  If you already have a provisioning system, you need to expand and modify it to account for the cloud (e.g., add parameters to account for cloud capabilities, build connectors to the cloud API, tie into the cloud account mechanism, etc.).  If you don’t have a system in place, you need to build a new process to access the cloud resources.  The overriding issue for either approach is that there are no standards yet for cloud provisioning, so the work you do to tie into a cloud provider is not portable to another cloud.  The promise of cloud products which offer multi-cloud capabilities is that they can connect you to different clouds using a common set of interfaces.

Managing your cloud infrastructure can be a lot of work.  You need to integrate with an architecture defined by the cloud provider, using its specific primitives for working with cloud components.  This requires tying into the cloud APIs for configuring IP addresses, subnets and firewalls, as well as data service functions for your storage.  Because control of these functions is based on the cloud provider’s infrastructure and services, you also have to modify your internal processes and control systems to integrate with the cloud infrastructure management.

Even managing your operating systems as part of a cloud deployment presents challenges.  Many cloud services provide “base servers” or templates that contain a simple distribution or OS, which are then used to build up your specific server/OS/application.  This approach works well when the provider has the exact base server you want to start from, and you have a process in place to build from a running server.  The challenge is that when you build up a server based on a gold image, it  may: a) not match the base cloud OS version, b) be built from a non-running or base OS versus a fully-running OS (as required by most clouds), and c) use internal resources (boot servers, internal repositories, etc.) that are not available in the cloud.  From a maintenance perspective, many organizations use central controls for updates (like WSUS for windows), and these services depend on access to data center networks and services.  Since public clouds are running external to your data center, these services either won’t work, or need to be altered to run the hybrid environment.

Finally, the cloud creates additional complexity for managing applications.  You almost always need to modify applications to accommodate cloud differences (virtual environment, networks and storage), which means that the applications in the cloud diverge from the “original” or base applications in your data center.  You may also use third-party tools to help with integration into the cloud (such as VPN software, integration scripts, encryption software, etc.), which then need to be maintained.  Each of these software elements has it its own lifecycle and update management, most of which apply to every image deployed into the cloud.

The management problems introduced by including the cloud in your infrastructure all have their source in the same issue – the cloud is something separate and different from your data center.  This separation becomes clear when you consider the integration and management issues that span everything from provisioning to reengineering your applications to changes in lifecycle management.  At CloudSwitch we’re streamlining and automating cloud management to eliminate most of these issues, and bridge the separation between the cloud and your data center.

Next: Key Considerations for Cloud Performance

Read the original blog entry...