Data Center
P2C: A Funny Thing Happened on the Way to the Cloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Ellen Rubin
As IT organizations move forward with their virtualization initiatives, consolidating operations and shrinking provisioning times, the cloud has come along as an even more compelling option. In the cloud, companies can build capacity on-demand without having to own or manage the computing infrastructure. As companies review their application portfolios, they’ve started to realize that many of their not-yet-virtualized apps could easily be run in the cloud. In particular, applications that are characterized by spikey, cyclical, or seasonal usage could benefit the most from the cloud’s economics and scalability — but a significant percentage aren’t even getting the benefits of virtualization.
So what’s the delay in going “P2V” (physical to virtual)? As with the cloud, virtualization has typically percolated from the bottom up. In many cases it crept into organizations, led by developers and technology evangelists who recognized the efficiency and cost advantages of virtualization and simply started using it. While many enterprise customers have started expanding their virtual footprints it can be a long and complex process. Although technically it’s quite easy to virtualize an application, using a number of well-known P2V tools such as VMWare Converter from VMware or Platespin (now owned by Novell), the harder part of the process is often agreeing which applications to virtualize and understanding the inter-dependencies between these apps and other data center services.
As corporate IT has slowly adopted virtualization as a strategic imperative, the cloud has come along with paradigm-changing flexibility and elasticity. We’re now seeing enterprise customers and prospects ask what they can do with applications that aren’t yet virtualized and are still sitting on dedicated servers, recognizing that the cloud is likely to be their ultimate home. Thus we’re seeing the emergence of a new model — “P2C” (physical to cloud), with virtualization in the data center becoming a stepping stone to the ultimate destination of the cloud. As discussed in a previous blog, the cloud has become a catalyst that is prompting companies to broaden their virtualization efforts.
Customers and prospects have told us that the P2C model is far preferable to simply performing a virtualization project in a vacuum and figuring out later which applications really belong in the cloud and how to get them there. In contrast, P2C is all about planning for the cloud from the outset, starting with virtualization and moving to the cloud as a natural progression. The P2C approach can also lead enterprises to alter their virtualization strategy compared to pure P2V. In some cases, they may want to use the cloud as a temporary home for applications that need to migrate between data centers, to support satellite offices or in the case of an acquisition. In other cases, they may keep the application permanently in the cloud and be able to budget for far fewer internal resources.
Thus, we encourage customers to consider P2C as a valuable strategy, since for many applications, the cloud will deliver far greater self-service and on-demand computing power than available internally. By planning for this ultimate goal and designing their infrastructure accordingly, customers can also potentially save a great deal of time and money. Ultimately, a single integrated environment will span the virtualized data center and multiple clouds, using the same tools and providing the same simplicity of experience. CloudSwitch is working with our customers and partners to make it easy to use the cloud, regardless of the starting point.
Data Center in a Box
By Damon Miller
Years ago I had the privilege of helping to grow Bladelogic from early-stage startup to a profitable organization of over 300 people. In the early days one of my first challenges was figuring out how to show our product to prospective customers effectively. I needed to show our ability to manage a large IT infrastructure but I had to do so without actually dragging a data center to each of our sales calls. (My first attempt involved renting a fleet of trucks but visitor parking turned out to be a real challenge.) As I look back on that situation now, I realize that CloudSwitch offers a perfect solution to this “data center in a box” problem. In this article I’ll walk through the use case and describe a new CloudSwitch feature, Sample VMs, which makes this possible.
The first step toward a virtual data center is to use virtualization, of course. In late 2001 VMware released the third major version of their Workstation product. Given my demonstration requirement, I bought a copy of Workstation, found the biggest “mainstream” laptop available at the time, filled it with memory, and deployed as many VMs as it would run without completely falling over. Depending on the end user’s patience, that number was somewhere between four and six. While not exactly a world-class data center, the end result served us well for demonstration purposes. It was, however, limited in capacity, slow, expensive, and difficult to maintain.
In retrospect, what we really needed was a way to:
- Quickly start new servers and turn them off when finished;
- Use existing, internal virtual servers or public server images; and
- Connect to these servers as if they were on the local network.
Fast-forward nearly ten years and the first of these points—utility capacity on demand—is all but ubiquitous courtesy of providers like Amazon and Terremark. We of course know this as “the cloud” and companies use it every day for a variety of reasons. The second two points are more interesting.
Today’s cloud providers have implemented their platforms on a particular virtualization solution—and in many cases they’ve customized these solutions to suit the needs of their product offering. This is of course perfectly natural, however one practical effect is that end users cannot simply take their own virtual machines and expect to run them within a given cloud provider’s environment. The reasons vary—different virtualization solution, different underlying hardware, different capabilities—but the end result is always the same: cloud providers will not allow end users to upload custom VMs and run them. For this, CloudSwitch is needed.
One of CloudSwitch’s fundamental benefits is the ability to run customers’ virtual servers in whichever cloud provider is most appropriate, regardless of the underlying implementation details. After deploying our appliance, users can select virtual servers within their internal VMware environment and migrate them to a public cloud provider such as Amazon or Terremark without being forced to modify those servers in any way. No additional software or configuration change is required for this to work. Users literally “point and click” to migrate virtual servers from their data center into a cloud provider.
In many cases, users want to leverage the cloud but don’t want to migrate existing servers. CloudSwitch supports this approach as well. With the recent GA release, CloudSwitch allows customers to select from a set of public “Sample VMs” for access to cloud capacity. Customers can use these sample VMs for a variety of purposes—evaluation, production, or anything in between. Further, since these machines have already been moved into the cloud, starting them is quick and efficient. Current Sample VMs include a stock Centos 5.4 base image, SugarCRM, and BugZilla running on a Windows OS. We’re expanding the list of Sample VMs based on a range of customer use cases, and have plans to include many open source and partner products.
The final point—seamless connectivity—speaks to the way cloud providers offer connectivity to their instances. Today, each provider has chosen a particular network architecture for delivery of their services. For example, if you start a Linux instance in Amazon’s EC2 service and run “ifconfig eth0” you will likely see a 10.x.x.x IP address assigned to the interface. This is because Amazon has chosen the 10.0.0.0/8 private address space for connectivity to customer instances. Other cloud providers use different addressing schemes but regardless these are different and disconnected from what customers are using within their own data centers. Further, secure connectivity to these instances is not convenient and in many cases is not possible. CloudSwitch addresses this problem as well.
As part of the deployment process, CloudSwitch automatically creates a secure overlay network within the chosen cloud provider’s environment. This overlay network extends a customer’s internal data center into the cloud so the cloud-based servers are part of the customer’s data center network. When migrating existing servers into the cloud, end users see no difference; they can SSH or RDP to migrated instances without even realizing that their servers are no longer running within the data center.
So, CloudSwitch offers a way to leverage the power of the public cloud without forcing end users to change the way their infrastructure is configured. We also offer a set of sample content customers can use if they simply want to establish a footprint in the cloud without migrating existing servers. Finally, end users connect to cloud servers just as if they were running within the data center network. The implication for my “data center in a box” use case is probably obvious: I could have installed the CloudSwitch Appliance on my sales engineers’ laptops, created a set of demo servers in the public cloud, and used these for field sales activity. We would have saved money on the laptops but more importantly my team would have been more effective.
Ultimately the cloud is about better service delivery. Better can certainly mean less expensive but in my case better would have meant more effectively expressing the value of our product to prospective customers. Regardless of the definition, CloudSwitch offers a simple, secure, and effective way to leverage the cloud. Since the early startup days in 2001 my goal hasn’t really changed much; I still want the opportunity to show you how our product can make you more effective. The difference is I finally have my “data center in a box” to prove it to you (and I don’t have to take up all of your visitor parking spots).
Three Ways to Do Web Apps in the Cloud
By Ellen Rubin
Web apps were born to run in the cloud. With endless flexibility, on-demand scaling and great pricing, the cloud meets the business and technical needs of many enterprises’ web-based applications for e-commerce, collaboration, marketing, CRM and dozens of other functions. With their ‘spikey’ needs for compute resources around peak periods, web apps are often corporate data center hogs and/or hosted at colos and MSPs at high cost.
As we work with many enterprise customers, we consistently hear the desire to host web apps in the cloud to reduce data center costs, footprints and headaches. There seem to be three major use cases emerging in the cloud market, reflecting the ways in which specific web apps are architected, and the comfort levels of the customer in exposing some or all of their app stacks outside the corporate firewall:
- Build the entire web application to run in the cloud. Launch some raw servers in the cloud and create your application using simple templates so that all tiers (user-facing, business logic, and database) run in the cloud. If you are putting up a new public web site, this is a great way to get into the cloud, and is particularly useful if you do not need to access data or systems that already exist within your data center. Many new companies and start-ups already also use this approach since they don’t have any legacy infrastructure to integrate with!
- Move parts of the application to the cloud. Keep some of the app components internal and move others to the cloud. For example, put the user-facing portion of the application stack in the cloud for scaling and access by large numbers of users, and let it reach back to the data center to access your business logic and/or database tiers. Some of our customers put the user-facing and business logic in the cloud and reach back for the main database, while others put just the public access portions into the cloud. The key considerations are what kind of data the application needs to access, how much data is required, and the application’s sensitivity to latency between the tiers. If data is very sensitive, the pull is to keep it in the data center, but if the application is susceptible to database latency, the desire is to move data to the cloud to be near the computation servers. Even when all tiers are moved to the cloud, there is often a need to access data center resources (for management, user validation, or ancillary data).
- Use the cloud for peak-period scaling. This approach involves scaling portions of the web application into the cloud during peak periods, such as for a Mother’s Day sale or when the tax filing deadline approaches. Based on a peak-workload trigger, move base images of the app into the cloud and let them scale away. Add the new cloud resources to your load balancers to keep response times low during peak usage. When you need occasional access to massive compute resources, the cloud provides a great alternative to buying and maintaining expensive equipment. The cloud essentially becomes an extension of your data center for on-demand scenarios.
Which of these approaches will work best for you? Many enterprises are testing more than one approach with different web applications as they define their cloud strategies. CloudSwitch technology lets you get started now with no risk, moving applications (or selected portions) to the right cloud, and keeping cloud resources in seamless integration with your data center. Put your web apps where they belong and free yourself from endless infrastructure heavy-lifting.
Private Clouds: Old Wine in a New Bottle
By John McEleney
I recently read a Bank of America Merrill Lynch report about cloud computing, and they described private clouds as "old wine in a new bottle." I think they nailed it!
The report points out that a typical private cloud set-up looks much the same as the infrastructure components currently found in a corporate data center, with virtualization added to the mix. While the virtualization provides somewhat better server utilization, the elasticity and efficiency available in the public cloud has private clouds beat by a mile.
In short, the term "private cloud" is usually just a buzzword for virtualized internal environments that have been around for years. By replicating existing data center architectures, they also recreate the same cost and maintenance issues that cloud computing aims to alleviate.
Despite their limitations, there is still a lot of industry talk about creating internal private clouds using equipment running inside a company’s data center. So why do people consider building private clouds anyway?
To answer this question, you have to step back and examine some of the fundamental reasons why people are looking to cloud computing:
- The current infrastructure is not flexible enough to meet business needs
- Users of IT services have to wait too long to get access to additional computing resources
- CFOs and CIOs are tightening budgets, and they prefer operational expenses (tied directly to business performance) vs. capital expenses (allocated to business units)
In every case, the public cloud option outperforms the private cloud. Let’s examine each point:
- Flexibility – the ability to access essentially unlimited computing resources as you need them provides the ultimate level of flexibility. The scale of a public cloud like Amazon’s EC2 cannot possibly be replicated by a single enterprise. And that’s just one cloud – there are many others, allowing you to choose a range of providers according to your needs.
- Timeframes – to gain immediate access to public cloud compute resources, you only need an active account (and of course the appropriate corporate credentials). With a private cloud, users have to wait until the IT department completes the build out of the private cloud infrastructure. They are essentially subject to the same procurement and deployment challenges that had them looking at the public cloud in the first place.
- Budgets – everyone knows that the economic environment has brought a new level of scrutiny on expenses. In particular, capital budgets have been slashed. Approving millions of dollars (at least) to acquire, maintain and scale a private cloud sufficient for enterprise needs is becoming harder and harder to justify — especially when the "pay as you go" approach of public clouds is much more cost-effective.
There are many legitimate concerns that people have with the public cloud, including security, application migration and vendor lock-in. It is for these reasons and more that we created CloudSwitch. We’ve eliminated these previous barriers, so enterprises can take immediate advantage of the elasticity and economies of scale available in multi-tenant public clouds. Our technology is available now, and combines end-to-end security with point-and-click simplicity to revolutionize the way organizations deploy and manage their applications in public clouds.
Sir Isaac Newton may not have dreamed about clouds, but his first Law of Motion, "a body at rest tends to stay at rest", has been a good harbinger of cloud adoption until now. It is fair to expect that people will grasp for private clouds simply because it’s more comfortable (it’s the status quo). However, the rationale for public cloud adoption is so compelling that a majority of organizations will choose to embrace the likes of Amazon, Terremark, and other clouds. As adoption increases, private clouds will be used only for select applications, thus requiring far fewer resources than they currently demand. We’re also seeing the emergence of “hybrid” clouds that allow customers to toggle compute workloads between private and public clouds on an as-needed basis.
In the end, we will have new wine and it will be in a new bottle. With CloudSwitch technology, 2010 is shaping up to be a great vintage.
Cloud Computing Compliance: Exploring Data Security in the Cloud
By Guest Author, David Mortman
David Mortman, Director of Operations and Security at C3 and former CISO at Siebel Systems, has a proven track record in leading security teams and setting security strategy at several companies, including C3, Siebel Systems, Network Associates, Securosis and Echelon One. David is a regular presenter at RSA and Black Hat and has also presented at SOURCE Boston, Information Security Decisions and the CSO World Congress.
Amid an ever-increasing bevy of regulations that enterprises need to worry about -- from SOX and PCI DSS to HIPAA/HITECH and the FTC's Red Flags Rules -- and a growing number of cloud service providers to choose from, enterprises have a lot of options and a lot of questions to consider concerning cloud computing compliance.
While migrating services to the cloud may provide many benefits, it does not absolve an enterprise of certain responsibilities. Most notably, the enterprise is still required to remain compliant with the assorted regulations and laws that it would fall under had it retained that service inside the company.
In some cases, as with PCI DSS, there is definite potential to reduce a company's compliance scope by outsourcing certain services. Most notably, by wholesale outsourcing the credit card processing to a third-party provider, an organization's PCI scope will be significantly smaller (though not go away completely). With the FTC's Red Flags Rules, however, that is not the case, as the FTC has mandated that any outsourcing must entail equivalent or better security than the enterprise would have implemented internally.
As you start to investigate moving services to the cloud, it's important to ask several cloud computing compliance questions:
- Does this data that will be moving to the cloud fall under any compliance-related regulations or requirements? This includes data such as Personally Identifiable Information (PII), Personal Health Information (PHI), or corporate finance-related information.
- If the answer to question one is yes, which regulations does it fall under and what controls are necessary?
- Can the cloud provider actually offer the identified or equivalent controls that your organization's data requires?
- Does the cloud provider have the necessary policies, processes and procedures to properly maintain those controls?
- Does the provider have appropriate disaster recovery and business continuity processes to meet your organization's business needs?
- What happens if the cloud provider goes bankrupt? Can the enterprise's data be sold to a creditor or at auction as a provider's asset?
- Should I decide to change providers, is there an easy way to export my data in a useable format?
- Is the provider willing to alter its default terms of service in order to guarantee or provide service level agreements (SLAs) around questions 3-7?
That last question is particularly important, as many cloud providers refuse to use anything other than their default contract language. As a result, they have effectively eliminated themselves from being potential providers of compliance data-related services. Several of the compliance regulations, most notably HIPAA/HITECH and the FTC Red Flags Rules, specifically mandate that an enterprise must have contracts with its service providers mandating appropriate controls, processes and procedures in accordance with each regulation's guidelines.
Similarly, if the providers can't meet the requirements of questions 3-7, they should also be eliminated from contention for your company's business. Lack of ability to meet requirements is a problem especially when it comes to PCI DSS and HIPAA/HITECH. Thus, you will quickly find that your options for cloud service providers are limited -- at least in the short term -- though rumor has it that several of the larger cloud providers are working on retooling their systems to meet these compliance needs. There are a handful of cloud providers on the healthcare side that have built applications specifically to meet the needs of the healthcare industry, but I have not yet seen any security evaluations of these applications to determine their effectiveness.
In the meantime, I recommend passing the above questions to providers that you're evaluating, much like you would pass them a request for information (RFI )for any other outsourcing project, and then choose the provider that can best meet your needs.
Alternately, if none can, investigate ways of removing or obfuscating the relevant data (such as hashing or encrypting information prior to moving it to the cloud), so your organization can still get the business benefits of the cloud.
Hear more from David Mortman in this recorded CloudSwitch webinar:
Title: “How to Secure the Public Cloud for the Enterprise: Making the Public Cloud Work Like a Private Cloud”
WATCH ON DEMAND >
Cloud Expo 2010: Virtualization Steals the Spotlight
By Ellen Rubin
At first glance, cloud computing can appear to be “virtualization taken to its logical conclusion.” After all, if the main benefit of virtualization is to consolidate data center resources and increase the speed of provisioning, then cloud is the ultimate pay-off: don’t own the resources at all and cut provisioning down to a few minutes with instant self-service gratification.
But upon further thought, and as was highly visible at the Cloud Computing Expo this week in NYC, cloud seems to be giving virtualization a return to the spotlight. A recent Gartner study noted that cloud computing is the number 2 priority for CIOs – trumped only by…virtualization. And most of the sessions at the Cloud Expo made some mention of the benefits of extending virtualization footprints within the data center and starting to turn these into internal clouds, or at least “cloud-like” environments.
So is virtualization what’s old but new again? Remember that most enterprises have adopted virtualization in some way, but are only about 20% virtualized so far. So there’s plenty of room left to penetrate, and there’s still lots of opportunity for optimization and better management. Virtualization has primarily been used for consolidation, not for optimizing workload management and self-service. And many companies have large investments in existing hardware and virtualization licenses that they’d like to use more efficiently. In many ways, cloud computing has emerged on the scene as a disruptive force while virtualization is still an evolution in progress.
As at other recent shows, the common wisdom at the Cloud Expo was that “hybrid” environments are key to the emerging IT infrastructure. Some resources will stay behind the firewall and others can be moved to outside cloud environments. Some applications may need to be split between the data center and external clouds, especially where the database needs to stay inside. In this hybrid world, some enterprises will want to focus on growing the internal virtualization footprint and starting to build capabilities for provisioning, charge-back, orchestration, role-based access, etc. This may require significant investment in additional hardware and software. It will also require enterprise IT to develop a new perspective on managing their virt investments, learning from the cloud providers about best practices and from companies like CloudSwitch about how to combine external cloud services with their own environments securely and transparently.
It’s also true that many of the major technology vendors (as well as some IT departments) have a bias towards focusing the cloud revolution on known and existing technologies. It’s still somewhat scary to think about moving things outside the data center and cloud technologies are in relatively early stages. And external cloud services (in particular public clouds) are pushing the envelope in terms of customer expectations and placing new, challenging demands on virtualization.
But virtualization will have to step up to these demands now that the cloud revolution has raised the bar. Many of the emerging capabilities will need to be at the management plane: a broad range of self-service functions, for sure, but also the ability to route workloads to the appropriate environments based on business and technical requirements, and to federate across multiple and diverse environments both on-prem and externally. So maybe cloud computing turns out to be not only the logical extension of virtualization, but the catalyst that helps virtualization move to the next level.
Why an 'Apps' Guy Moved to the Cloud
I 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.
