Data Center
Why an 'Apps' Guy Moved to the Cloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInI have spent most of my career involved in the development of software applications. For the past seven years, I had the honor of leading SolidWorks, the # 1 mainstream 3D CAD company in the world. When I left in 2007 we had over 750,000 users and tens of thousands of companies using our software. They were designing products that you and I use in our everyday lives.
Through a lot of hard work of hundreds of employees and some luck we helped create a lot of value for these customers as well as our investors and business partners. In addition to good luck (which we admittedly had a lot of), we capitalized on a fundamental platform shift: Unix to Windows. This platform shift, combined with a business model shift (direct sales to indirect sales) created a significant amount of value. I sense the same opportunity with the cloud.
After taking some time off, I spent time with some local venture capital firms looking at a lot of new technologies, new products and business ideas. All of the start-ups (not just some, but all) were using the cloud for their infrastructure. Like canaries in a coal mine, this to me validated what I was observing: the cloud really is a new platform. Also, the cloud requires a business model shift in enterprise software sales since cloud services by their nature are low-cost and on-demand – unlike the traditional sales model of large, costly enterprise purchases.
I spent several months more looking at companies in and around the cloud space and became intrigued by the perspective shared by Ellen Rubin and John Considine, founders of CloudSwitch. They had a clear view of how they felt companies would want to take advantage of the cloud. This was evident in their approach: rather than try to take the clouds to the data center (which everyone appears to be doing), they wanted to start from the data center and help them extend out to the cloud.
Combine this simple, yet profound insight with a platform shift and a business model shift and you understand why an apps guy would be so excited to join the CloudSwitch team.
What If You Could Provision in the Cloud Using Your Existing Data Center Tools?
What if you could use your incumbent data center bare metal provisioning tools to create application instances in the cloud?
Today you may be using familiar tools in your data center to build out new application stacks successfully, such as Microsoft ADS or RIS, Kickstart or Autoyast, HP Opsware or BMC BladeLogic, or Altiris. You may have also made a significant additional investment in front-ending these provisioning tools with an in-house developed provisioning portal, or orchestrating these tools with a workflow or Runbook automation tool.
These tools and processes require a significant investment in their deployment and in the authoring and configuration knowledge that is embedded within them. But, as flexible as these tools are in reliably building configurations, they are not usable as-is with compute resources in the cloud. Consider Amazon EC2, for example. How will you get their Xen paravirt network device to PXE broadcast, or route that back to your on premise DHCP/TFTP infrastructure? Till now, the answer is that you can’t.
So, you are faced with having to use another siloed provisioning tool that is designed and built for use with your chosen cloud provider. You need to retrain staff. Reprogram configuration scripts. Maintain parallel systems that are basically doing the same thing.
It’s hard to argue that it’s worth doing all this, outside of the compelling premise that you REALLY want to be able to turn on something for 2 hours, and pay 15 or 16 cents for the use, and then turn it off. The power of that flexibility has been the motivating force behind organizations going against the grain and adopting a separate and purpose-built cloud provisioning tool to take advantage of the elasticity and flexibility of cloud-based servers.
But what if you didn’t have to make that choice? What if you could treat cloud servers EXACTLY as if they were new bare metal blade servers that had come off the loading dock, been racked and stacked, powered on, and started PXE broadcasting? Today, you can import a list of MAC addresses off your asset sheets for these newly powered-on servers into your incumbent bare metal provisioning tool of choice, and start throwing your J2EE stacks onto these servers.
CloudSwitch is committed to the proposition that you can have your cake and eat it too. You can create as many blank servers as you want, using any combination of instances sizes to customize the cores, memory, storage, network, and compute capacity that you need to provision an application stack. The blank servers can be interrogated for generated MACs. You can plug those into your bare metal provisioning systems, just like the good old days when you could go over and see the lights flash for your new server in its rack, and get ILO console access.
Turn them on, let them PXE boot, and let them provision your stack. Use them as long as you need them and throw it away. You won’t have to retire the equipment or plan a server upgrade. Your cloud provider will take care of that for you. You won’t have to change a thing. Everything you have in place will still work. Transparently.
Isn’t that just a basically better idea?
__________________________________________________________________________________
Vote for CloudSwitch! Watch our video and cast your vote on Cloud Connect LaunchPad. Help CloudSwitch advance to the finals.
Opscamp Austin: IT Ops and the Cloud
Going to a conference focused on IT on a Saturday sounds like a really geeky way to spend a weekend, but thanks to an “alternative” venue, the “un conference” format, and a group of really good people, it was a great day. I just got back from Opscamp Austin, a meeting of IT professionals, system administrators, tools vendors, cloud providers, and people who spend their time building and keeping the computing infrastructure of business running. Many thanks to those who built this un-conference especially John Willis, Mark Hinkle, Damon Edwards, and all of the sponsors and presenters – you pulled together a great event.
Opscamp was created to allow an “open exchange of ideas around next generation technologies and strategies for IT Operations.” The big topics at this meeting (as measured by both passion and interest) were Monitoring, Configuration Management, and DevOps. I was particularly interested in these topics because we added the phrase “in cloudy environments” to the sessions.
I came away from this conference with a few conclusions:
1. IT operations is currently messy, and “cloud computing” is exposing some of the problems. One problem is that when the cloud delivers on the notion of allocating resources in minutes, the pressure switches from raw provisioning to the speed of configuration; with the timescale compressed from days to minutes, there is nowhere to hide. The other big issue is the dynamic nature of cloud computing – with servers, networks, and storage showing up and disappearing from your environment, it becomes difficult to model and manage. The manual or loosely connected processes that worked because there was time while you waited for hardware to arrive no longer work in a highly dynamic environment.
2. There are very different views about what monitoring in the cloud should be – deep and consistent with current processes, or “just hide the messy parts,” to quote Amazon. Some wanted the cloud providers to give them deep access to the “normal” monitoring data – think cpu temperatures. Others think that the value in the cloud is getting rid of the support and detailed attention to the infrastructure, so who cares about that data, it is for the infrastructure provider to manage. The issue is that the current cloud offerings are quite opaque about what is happening in the infrastructure.
After talking with Bret Piatt from Rackspace it seems that the problem is not collecting the data (they have to do it anyway), but storing it, processing it, and doling it out to the customers. There is real expense here, and for those customers who don’t want it, they would have to carry the burden of the extra cost in a market that is sensitive to price. The fundamental choice here is whether we are going to carry the current detailed monitoring practices into the cloud, or give up on the low level monitoring of the remote resources. In order to carry forward the current models, the cloud providers will have to provide API’s to get at the internal data. In order to change the model, developers and tool providers will have to increase the capabilities of the applications around fault tolerance and providing useful monitoring data that can be measured from the application level.
3. We are still in the early days of cloud computing. This should not be a surprise to anyone, but since at CloudSwitch, we’ve been so fully integrated with the cloud since the beginning – with everything from our build servers, bug database, large number of QA servers, code repository and web site –it’s easy to think that everyone is already comfortable using the cloud. What became clear in the discussions is that many of the organizations are still working though server virtualization and how to take advantage of the advanced features enabled by that technology.
What was really exciting for me was to see the people who actually have to make IT work thinking through what is needed to build a dynamic data center and integrate with cloud computing. With these guys on the case, I know that cloud computing is taking real steps forward.
Cloud Federation and the Intercloud
Last week’s post explored federation in the cloud, allowing enterprises to move workloads seamlessly across internal and external clouds according to business and application requirements. Advances in federation are good news for companies considering a move to the cloud since deployments no longer need to be custom projects and applications no longer have to be tightly coupled to a particular cloud.
To follow up, there’s been lots of discussion recently about the concept of the “Intercloud,” a direction for cloud computing that is closely related to federation and ties in with much of our work at CloudSwitch. A term introduced by Cisco, the Intercloud refers to a mesh of clouds that are interconnected based on open standards to provide a universal environment for cloud computing. Like the name suggests, it’s similar to the Internet model, where everything is federated in a ubiquitous, multiple-provider infrastructure.
The primary difference between the Intercloud and federation is that the Intercloud is based on future standards and open interfaces, while federation uses a vendor version of the control plane. With the Intercloud vision, all clouds will have a common understanding of how applications should be deployed. Eventually workloads submitted to a cloud will include enough of a definition (resources, security, service level, geo-location, etc.) that the cloud is able to process the request and deploy the application. This will create the true utility model, where all the requirements are met by the definition and the application can execute “as is” in any cloud with the resources to support it.
What shape the Intercloud will take and what standards will emerge to make it work are part of an ongoing debate. Some industry watchers believe it will happen sooner than later. Others believe that discussion of the Intercloud is premature, wary that embracing standards too quickly will hold back innovation, and therefore the Intercloud will remain only a vision for the foreseeable future. When these debates will be resolved is anyone’s guess, but major progress in cloud integration is already underway, so there’s no need for enterprises to put their cloud plans on hold.
At CloudSwitch, we believe that the Intercloud is likely to emerge organically as the result of continuing innovations throughout the cloud ecosystem. Federation is one of the prerequisites toward that goal, providing ongoing improvements in cloud interoperability aimed at giving enterprises many new options from which to choose. The ability to federate identity, access and dataset migration is also one of the key requirements for Intercloud activity. This interoperability at the infrastructure level has to work transparently in order to launch applications into the cloud environment and manage the integration.
The benefits of the Intercloud are in many ways already a practical reality. A significant part of the Intercloud vision can be achieved with a strong federation technology that provides a gateway between different clouds and the internal data center. Users and their companies can avoid lock-in and run workloads in the environment that best matches their needs, based on cost, performance, security, compliance, geography, latency, etc. In short, some of the most important Intercloud goals can be achieved using technology already coming to market.
2010 is the Year of the Federated Cloud
In this first post of 2010, I’d like to look at one of the most important cloud issues that enterprises want to tackle: federation in the cloud — across clouds and between the cloud and the data center. Also known as hybrid clouds, the notion of federation has been around since cloud computing began, but as a long-term vision rather than a working solution. This year that gap is going to close.
What Is Cloud Federation?
Federation brings together different cloud flavors and internal resources so companies can select a computing environment on demand that makes sense for a particular workload. It opens the door to a range of useful scenarios that take advantage of cloud capabilities:
- Using multiple clouds for different applications to match business needs. For example, Amazon AWS or Rackspace could be used for applications that need large horizontal scale, and Savvis or Terremark for applications that need stronger SLAs and higher security. An internal cloud is another federation option for applications that need to live behind the corporate firewall.
- Allocating different elements of an application to different environments, whether internal or external. For example, an application could run in a cloud while accessing data stored internally as a security precaution. (We call this concept “application stretching.”)
- Moving an application to meet requirements at different stages in its lifecycle, whether between public clouds or back to the data center. For example, Amazon or Terremark's vCloud Express could be used for development, and when the application is ready for production it could move to Terremark's Enterprise Cloud or similar clouds. This is also important as applications move towards the end of their lifecycle, where they can be moved to lower-cost cloud infrastructure as their importance and duty-cycle patterns diminish.
Enterprise users don’t typically talk about federation per se; they speak in terms of application-specific and general business requirements. While some applications will always belong in their data center, they may have others (possibly hundreds) that could run more cost-effectively in the right cloud. Our customers and prospects tell us that they would love to take advantage of different clouds to get the computing performance they need, along with the desired service levels, scalability, security and price points. And since they aren’t that clear yet on their cloud requirements, and cloud services are in early stages and will continue to evolve, they want the ability to pick up their applications if necessary and move them to other clouds or back to the data center with minimal effort.
The problem is that the cloud is not a homogenous entity, but covers a broad landscape of computing environments, with no consistency between any of them or with the enterprise data center. Federation is the missing link, providing a structure that bridges these disparate environments so enterprise cloud computing can become as seamless and straightforward as it needs to be. Let’s examine some of the key issues and see what CloudSwitch is doing to make federation work.
Bridging the Differences
An application should to be able to run “as is” in any cloud with the resources to support it. But each cloud has its own server platforms, operating system versions, APIs, network settings, storage options—a whole landscape of varied characteristics. Without federation, each cloud deployment becomes a custom “one-off” exercise to meet the requirements of a particular cloud environment. That’s not acceptable internally, and companies are now demanding the ability to leverage different clouds without the underlying engineering efforts required to make it happen.
A unique capability of CloudSwitch is the ability to integrate at an infrastructure level between the data center and different clouds. We sit in the middle of all of these resources and automatically bridge the differences, regardless of variations in virtualization platforms, operating systems, APIs, storage infrastructures or other characteristics of the different clouds. Both internal and cloud resources appear as if they’re running locally, using a common interface spanning multiple clouds and the local environment.
Setting Consistent Rules
Rules and permissions about what employees can do in the cloud must be consistent with those in the data center. Role-based controls are required, for example, to enable a particular individual or group to create servers but not to delete or modify them. However, in these early days of cloud computing, the standard procedure is to allow cloud users access to the cloud credentials; essentially every user has full control and access to the cloud resources. This not only causes control issues but makes auditing and problem resolution difficult since it is unclear who is responsible for any particular action.
CloudSwitch solves this problem by holding the credentials for external clouds and serving as the gateway to cloud accounts. Rather than users accessing their accounts directly, they interact with the cloud through the gateway, which consolidates permissions for all users and multiple clouds for management by an administrator. The approach provides consistent policies governing user and management roles, whether internal or external.
Streamlining Cloud Management
Federation also means that administrators should be able to manage applications running in one or more clouds as if they were running locally, using their familiar tools and processes for application lifecycle management, monitoring, compliance management, etc. But cloud computing involves a wide assortment of isolated environments to keep track of and manage. Adding to the complexity, cloud providers often have their own management tools that users or administrators need to learn, all different from each other and from what enterprises have internally.
CloudSwitch keeps things simple for the enterprise by replicating the existing IT infrastructure and mapping it to the target cloud. The approach allows current management tools to work seamlessly in the cloud, just as if an application were running locally. Using consistent tools and policies, applications and resources can be managed with the same flexibility, security and control regardless of their location.
Bringing the Vision to Life
Federation is required for cloud computing to be successful, particularly as computing needs continue to expand. Enterprise users want to take advantage of all the capabilities available in the cloud, but without the complexity or risk. The ability to federate this heterogeneous ecosystem—to create a uniform environment spanning external and internal clouds—is going to allow IT organizations to meet user and corporate needs with an agility and economy not previously possible. CloudSwitch is part of an emerging ecosystem that’s making federated cloud a reality.
Making Cloud Computing Secure for the Enterprise
For cloud computing to gain traction in the enterprise, IT and security executives need to be certain that their company’s applications and data are safe. But when security is partly out of enterprise control, it becomes impossible to know if sensitive information has been accessed or compromised.
Today, using a public cloud means moving from an internal environment where a company has complete control of data and processes to an environment where that control belongs to someone else, and is often opaque. Within the cloud, applications run in a multi-tenant virtual environment, sharing physical machines with other customers. Companies considering moving an application to a cloud have legitimate concerns about data being compromised or stolen, including unauthorized access by cloud administrators, exposure in the internet or rogue employees using the cloud to corrupt or leak sensitive information.
One solution is to keep sensitive data within the corporate data center and put the other application tiers in the public cloud. While this approach works well for some use case scenarios, the latency impact of the “reach back” into the data center can be unacceptable for many applications and users. The other option is to move the entire application to the cloud – including the database tier – for better performance and scalability, but this exposes the application to new potential threats such as those mentioned above.
Encryption is a well-known approach to addressing these types of security threats. For protection in the cloud, the enterprise would need to encrypt all data and communications. While it’s not that difficult to add encryption software initially to the application environment, the new configuration requires ongoing management and maintenance. And in order to run the application in the cloud, the enterprise needs to deliver the encryption keys to the cloud to decrypt the data, creating additional security risks by exposing the keys in the operating environment. In the worst case, poor configuration can expose the corporate data center to threats from the cloud.
In developing our security model at CloudSwitch, we worked closely with CSOs and security teams at several large enterprises to understand their requirements. As a result, our architecture addresses three areas of protection required to make cloud computing secure for the enterprise:
- In the data center: Role-based access control protects data and processes from unauthorized access.
- In the Internet: Connections are authenticated and data is encrypted to prevent data in transit from being exposed or compromised.
- In the public cloud: Data is encrypted with keys under enterprise control, and can never be accessed by the cloud provider or unauthorized users.
The CloudSwitch security strategy is a key part of our vision to make the cloud a seamless extension of the corporate data center. Using CloudSwitch technology, companies can move applications and data to a cloud without modification, and back to the data center as needed. Companies can also select the right cloud for a specific application, based on security and compliance levels as well as service offerings and pricing structures. Only with control of applications and data at all times can enterprises take full advantage of cloud resources without sacrificing the security required by customers, internal users, regulators and other stakeholders.
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
Moving to the Cloud: Key Considerations for Cloud Storage
This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.
The true challenges in storage and data management in the cloud result from the diverse and often unfamiliar processes and infrastructures offered by the cloud providers, including: new provisioning methods, storage properties, data population and transfer, and systems for data management (snapshots, clones, replication, backup). The cloud providers define the relationship between servers and storage and often impose constraints on everything from allocation size limits to the ways in which storage is managed. These are just some of the things you’ll want to consider as you start to think about integrating cloud computing into your existing IT environments.
I’d like to focus in detail on the complexity and variability of cloud provisioning and storage properties. There are different models for storage in existing compute clouds, with the most common being an “inclusive” storage model. In this model, each server comes with a certain amount of storage attached to it. The storage is a fixed capacity that is provisioned when you create the server from the pre-existing templates.
For example, Rackspace gives you disk space that is proportional to the memory (RAM) size you select. The smallest memory/disk combination is 256MB of memory with 10GB of disk. With each doubling of memory, the disk space is also doubled until you get to roughly 16GB of memory and 640GB of disk. With the new Terremark vCloud Express, you get a system disk that is predefined for each “template” server you select. For a standard Linux distribution, you get a 10GB system disk, for Windows 2K3 you get a 20GB disk and for W2K8, you get a 40GB disk. Terremark’s vCloud Express allows you to add additional storage as new disks, while others (like Rackspace) allow to “resize” your servers and storage to create a new server with a larger disk and copy your data into it.
Amazon offers several distinct types of storage within EC2. The default storage you get with each server you create in the cloud is called “ephemeral” storage. You then have the option of allocating and attaching Elastic Block Storage (EBS), and there is also an object store system called Simple Storage Service (S3). Ephemeral and EBS are standard “block storage” devices – meaning they are viewed and used as disks attached to your server (/dev/sdg in Linux, D: in Windows) while S3 requires an API or other tools to integrate with your systems. The good part about the EC2 storage offerings is that you have some powerful options as you build for the cloud; the hard part is mapping the proper resources to your applications and integrating this with your existing processes. Specifically, the base storage is ephemeral, which means that if you power-off the server, or it has a hard fault, all the data on that storage is lost. This means that everything on these drives (boot parameters, application updates, user data, logs, etc.) is subject to loss when you power off the machine. There are several methods of handling this situation: 1) Build your servers every time you start them from a formula or other sources such that you don’t depend on the base storage being persistent; 2) Use Amazon or third party tool sets to periodically “bundle” your servers into S3 (effectively taking a snapshot of the server); or 3) Attach EBS storage to your image and store your important data on persistent storage.
Turning to granularity, we find a wide range in the units or increments of available storage in the various cloud providers. There is the “included” storage mentioned above that is often based on the size of the server and the requested OS type. To add storage, we find cloud providers (such as Amazon) allowing 1GB increments up to 1TB, and others (like Flexiscale) allowing only fixed increments of 50GB/100GB/250GB. For Rackspace, you can resize both the server and storage according to the defined fixed ratios, but these are bound to memory and CPU so there is no independent scaling of storage. The bare-metal cloud provider NewServers allows iSCSI storage to be attached to your servers in 250GB increments. In the cloud these varied increments really matter, because you are paying by the GB/month and if you need just a little more storage, you could end up having to purchase 10x more storage than you need, or having to pay for more memory and compute than you need.
The conclusion we can draw is that there are numerous storage configuration options in the cloud, and these options become linked to the server “flavors” defined by individual cloud providers. Because you don’t have the same control or even mechanisms in the cloud as you do in the local data center, the manner in which you allocate, populate and manage data in the cloud will be different. The work you do to understand and map your applications’ requirements into cloud-based storage requires changing your processes to match those of the cloud, and often this work is cloud-specific.
Beyond configuration issues, of course, there are many other concerns. For example, with data management, you have to determine how you will get your data into the system, how to grow your systems and how to protect your data. Right now most clouds use template servers that you have to build up from a pre-installed base operating system using update mechanisms and then re-installing the application components. As for protecting your data, there are also many cloud-specific options available – from RAID-protected EBS in Amazon, to data snapshots and cloning, to backup services offered by companies like Rackspace.
The bottom line is that cloud storage can be simultaneously simple and complex – just like cloud computing in general. It’s simple to use if you just want to try something new; complex if you want to integrate cloud storage into your existing processes and infrastructures.
Next: Networking in the Cloud
Why Cloud is at the Top of the CIO's Priorities
In the most difficult economic climate in decades, CIOs are reevaluating their strategies and looking for new ways to reduce data center costs and overhead while improving responsiveness to business requirements. Cloud computing has emerged as a much more agile and efficient approach than what companies have done in the past: adding more compute, storage and networking capacity or trying to get more out of what they already own.
Cloud computing did not emerge from a vacuum, but has its origins in three technology "megatrends" that most CIOs are already familiar with. These developments were all born out of the same need -- to drive down costs, simplify data center operations and allow IT to be as agile as possible. As these megatrends have become pervasive, they've helped put the cloud in the CIO's strike zone:
The drive to consolidate: Consolidating sprawling data centers has become a top IT priority as companies struggle with out-of-control costs for hardware, power, administration and service. Many companies have seen their data centers grow beyond anything they ever anticipated, with the result that in many cases they're not only running out of space, they're increasingly running out of power and cooling as well. In response, they look for innovative ways to reduce their data center footprints - to move out anything that adds cost and complexity, and takes up extra real estate.
The growth of virtualization: Many organizations now operate in virtualized environments, where applications can be quickly deployed to available resources, rather than assigning them to a specific physical machine. Not only does this optimize utilization of equipment, it allows IT to become much more responsive to the needs of the business.
Emergence of SaaS: The Software as a Service (SaaS) model has become widely accepted, in which applications are hosted by outside service providers that can apply specialized expertise, the right hardware and economies of scale. The idea of running certain apps outside the walls of the organization is recognized as not only acceptable but often preferable, where an external provider delivers the service just as well (if not better) than companies trying to do it themselves.
Cloud computing builds on these megatrends, and goes several steps further, providing new capabilities for enterprise computing:
- Not just consolidating the data center, but creating the optimum environment both within the DC and in the external cloud, to match changing demands for computing resources
- Not just virtualizing applications across internal systems, but across whatever environment is most appropriate and cost effective
- Not just software as a service, but enterprise applications running in the cloud on the cloud provider's infrastructure
The ability to run applications in the cloud promises to radically alter the balance sheet by which IT projects are judged, where initial capital expense and ongoing operating costs are factored against value delivered and how quickly resources become available. CIOs now have the opportunity to do something much more significant than make small incremental improvements -- particularly as new cloud deployment and management tools come to market. That's why more and more IT executives are making cloud computing a top priority as they plan their strategies for 2010 and beyond.
Has Virtualization Solved the Data Center Crisis?
Over the past several years, many IT departments have committed to virtualization as an antidote to the spiraling costs and inflexibility plaguing corporate data centers everywhere. By running applications on virtual servers and consolidating underutilized hardware, data centers can get maximum value from their equipment. Virtualization also makes IT more responsive to the needs of the business: rather than spending weeks or months to provision a physical server, a virtual server can be launched in minutes.
Virtualization was meant to be the solution to today's data center woes - but is it? While it brings much-needed flexibility and efficiency to an environment where these qualities were sorely lacking, virtualization alone doesn't cure the underlying problem and in some ways adds to it. Companies still have large data center infrastructure footprints to maintain, plus virtualization licenses, plus management issues introduced by virtualization - ironically adding cost as they try to reduce cost. Many IT managers report that the technical and management challenges associated with virtualization are hindering them from realizing its full cost benefits. They're still paying huge energy bills (those consolidated servers are working much harder than previously). They're still running out of capacity and need to keep buying more servers and storage. And over half of them are still building new data centers at enormous cost.
We're Not Done Yet
But virtualization is one step toward a larger goal, not the end of the journey. IT is in the middle of a fundamental transition from the rigid, siloed world of traditional data centers toward a more elastic, responsive model where needs are met far faster and more efficiently. And we're not done yet. While virtualization helps companies reduce cost and improve agility, the full promise of the new model plays out with the addition of cloud computing, delivering infrastructure on demand as an easily-accessible, cost-effective service.
Rather than perpetuating a bloated data center, the new model will allow companies to get out of the computing infrastructure business where appropriate, retaining only the portion that is essential to the enterprise. As the cloud environment becomes increasingly agile and secure, provisioning decisions will be framed by asking: Should we be really be doing this ourselves, or can someone else do it better and at lower cost? The majority of companies surveyed that are either using or actively planning to run at least some apps in the public cloud have started asking themselves the same question.
Some companies - particularly larger enterprises with the skills and scale to do it effectively -- are building on their virtualized environments to create private, or internal, clouds that deliver several of the benefits of cloud computing within the enterprise. Private clouds provide users with an elastic computing resource on demand and help make better, more efficient use of existing capacity. But IT departments still face many of the same fundamental challenges - they still need to buy, manage and grow the data center infrastructure on which the private cloud depends. As Gartner Group's Tom Bittman points out, for most enterprises, the private cloud is not the ultimate goal, it's another stepping stone to services available in the public cloud as they become available.
It's All About the Application
The real issue is determining where each application truly belongs. Some apps are simply not suitable for any cloud, while others, at least for the foreseeable future, belong in the private cloud. Some applications are candidates for the public cloud, but the appropriate services aren't ready yet. And some data center applications could be moved to a public cloud now or in the very near future.
While virtualization is a key step toward moving beyond the rigid data center, cloud computing takes you all the way there - which is why it's getting so much attention. With new technology from CloudSwitch under development, it may work for your enterprise faster than you think. Stay tuned.
RSS Feed