public clouds
The Hidden Costs of Internal Clouds
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInBy Ellen Rubin
A public cloud can provide access to computing resources that many companies would otherwise never be able to afford. The arguments for the cloud are well-known by now, but remain compelling—no up-front costs, virtually unlimited computing power on demand, and highly efficient pricing where customers pay only for resources used. There’s also less pressure on corporate IT departments that are charged with managing the infrastructure and budgeting for new equipment to keep up with demand.
But concerns about security and loss of control in public clouds have led to an alternative model—the internal cloud—that replicates the cloud environment inside the corporate firewall. Within these boundaries, enterprise users can provision computing resources as needed, using the cloud’s self-service capabilities while leveraging data center services. Internal clouds are often referred to as private clouds, but since private clouds can also be found in external environments, the “internal” designation is a more precise term for what we’re talking about here. (RightScale's blog post provides helpful definitions of the different cloud variants.)
With servers, applications and data within the enterprise walls, internal clouds can provide many of the benefits of cloud computing without the potential risks when the computing environment is provided by a third party. Unfortunately, the economics of internal clouds makes them inherently less efficient than the public cloud, especially as new technology makes the public cloud safer and more reliable. Here are some of the reasons why:
- Infrastructure costs: Deploying an internal cloud requires building out the infrastructure to support the needs of all enterprise users. In addition to acquiring the necessary hardware and software, this includes things like configuring the network, allocating storage, paying the electric bill, and providing square footage for the equipment. Plus, all of this infrastructure has to be managed and supported on an ongoing basis.
- Over-provisioning: Just as with traditional IT infrastructure, anticipating resource requirements for an internal cloud is difficult since applications run at varying usage levels. Some applications consume resources fairly steadily while others require occasional bursts of massive computing power. Companies may have no choice but to over-provision, where some equipment sits idle most of the time in order to have resources available for peak periods. (Meeting these short-term usage needs is one example where the elasticity of public clouds really pays off.)
- Building the management plane: As Jon Brodkin points out, building an internal cloud is about more than just virtualization. One of the key benefits of cloud computing is the self-service aspect, where users can access resources as needed via a self-service portal, which then execute in the cloud automatically without administrator intervention. Building this control plane is another substantial step when implementing an internal cloud.
For all of these reasons, the internal cloud carries a cost overhead compared to leveraging the resources and self-service framework already provided by public clouds. Ironically, much the same protection and control offered by internal clouds is becoming increasingly available in an external public environment. So enterprises may find that a public cloud may provide a more cost-effective home for many (or even most) of their applications.
Internal clouds can make sense for the most business-critical requirements or those that need specialized hardware or have regulatory compliance issues. Focusing internal resources on these types of applications would greatly reduce the investment required to build, sustain and grow enterprise infrastructures. While some applications may always need to run internally, many companies have dozens of others that could run more cost-effectively today in a public cloud, providing computing power on demand along with required security, agility and scalability.
At CloudSwitch, we provide technology that allows companies to take full advantage of the resources and savings that the public cloud has to offer, while integrating seamlessly with their internal environments. Applications deploy automatically, are free from lock-in, and stay tied into internal data center services. In short, the enterprise gets the protection and control formerly found only behind the firewall, and can combine the best of internal and external cloud offerings with maximum agility and value.
Moving to the Cloud: Managing your Environment
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: Moving to the Cloud: Series Wrap-Up
RSS Feed