public clouds
What IT Managers Should Learn from Public Clouds
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Ellen Rubin
Corporate computing is going through a fundamental shift — moving to a world that’s largely cloud-based, self-service, and highly virtual with shared resources. Rather than go through their IT departments like they have for decades, users will simply specify how many cloud servers they need and for how long, and provision their own resources with a few mouse clicks. I recently read an interesting post by Rodrigo Flores, observing that the growing acceptance of public clouds is also changing the role of corporate IT departments, and they’ll have to either adapt or die. I’d like to make a few suggestions about how they can adapt.
First of all, they need to face reality. IT is driven by the need for agility, elasticity and cost-efficiency, and that can be provided most effectively in the public cloud. A year or two ago, most pundits were saying that large-scale adoption was inevitable — now the transition is well underway. Individual users and departments are already making inroads into the cloud to take advantage of agility not available internally. In many cases they’re not waiting for permission or help from corporate IT— they’re moving ahead on their own.
The growing emergence of public clouds creates an alternative to the traditional data center, while lowering the costs of infrastructure services. As cloud computing takes hold, the impact can prove unsettling for corporate IT departments that find themselves increasingly evaluated against the fast service and flexibility provided by public clouds. How will corporate IT departments fit in? How can they maintain their relevance when users can simply go to the cloud and get the servers they need immediately, often with better service than is available internally?
Rather than viewing public clouds as a competitive threat, corporate IT should embrace cloud computing and recognize their new role — serving as a trusted broker for the resources that users need, whether in a public cloud or internally depending on where the application belongs. Corporate IT becomes a much more agile organization, leveraging public clouds and internal clouds within an integrated framework, and IT professionals providing the front-facing infrastructure and support services that make it work.
But corporate IT still has much to learn about how to design and support this new environment, with virtualization being only the first step. To gain this expertise, they need to look to the public cloud — Amazon, Terremark, Savvis, Rackspace, Microsoft, etc. The infrastructure and processes that cloud providers have created at tremendous effort and cost can provide a guide for how corporate IT departments are going to operate in the very near future. It’s an idea that hasn’t yet received much attention from industry observers, but we’ve been hearing it a lot lately from our customers, particularly those thinking strategically about the cloud.
Thus, corporate IT has another incentive (in case they needed one) to take the lead in moving their companies to public clouds. As they plan their own agile environments for internal users, public clouds are where they’ll learn the best practices needed to make it work:
- Building the self-service portal: Corporate IT will need to make self-service for computing resources as simple and robust as it is in the public clouds.
- Managing a multi-tenant environment: Cloud providers deliver rapid provisioning at low cost by supporting large numbers of users on a shared infrastructure. Corporate IT will need to replicate this environment, while providing mechanisms that allow applications to be moved out to a public cloud or back again.
- Scaling efficiently: Cloud providers use several different scaling techniques and policies to keep up with growing demands, and corporate IT can learn a great deal from them about how to make trade-offs and automate wherever possible.
To sum up, corporate IT should look to public clouds as their most valuable resource — often far more agile, elastic, and cost-effective than internal resources. They’re where many enterprise applications (perhaps the majority) will soon run. In addition to their inherent advantages, public clouds also have much to teach. The lessons will come in handy as IT departments discover their new strategic role as champions of a more agile corporate computing environment. CloudSwitch technology makes that new world much easier to build and manage, so corporate IT can drive innovation without losing the security and control they need.
The Hidden Costs of Internal Clouds
By 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
