Experts recommend that enterprises begin their cloud experience with non-mission-critical applications that take advantage of the cloud's "elasticity" to rapidly provision and deprovision resources. The cloud is ideal for such temporary needs as testing and development, for example, or for scientific simulations that need to run for a couple of weeks, then scale down.
The cloud also works well for cyclical demands, such as sales spikes in retail environments around holidays. It's a reasonable alternative to building new space for infrastructure expansion, a reliable strategy for disaster recovery and a sound spot for old emails. In fact, production email may be the cloud's killer app, with many enterprises moving mailboxes to Google Inc.'s Gmail.
Project-based applications also are a natural fit, according to Errin O'Connor, founder and CEO of EPC Group Inc. in Houston, a systems integrator that has spent the last decade implementing Microsoft's SharePoint Web collaboration application for such clients as Northrop Grumman Corp., Continental Airlines Inc., Chevron Corp. and the U.S. Navy.
"Say a project is six months long, and you need an area for users to collaborate on documents -- that's where the cloud shines," O'Connor said. "For example, an oil and gas company had a huge project to spin up between two organisations, with well drawings, project schedules and task lists. They couldn't just go to IT and say, 'hey, guys, we need a site set up for 7,000 users by Tuesday,'" he said. "But they could call a cloud provider."
The cloud is great for external access by distributed workgroups, O'Connor said, but the external security model of the cloud offering must be robust. "There are a number of different security models that work, but it's most important to match those models to both the internal functional requirements and the specific cloud offerings," he said. EPC Group built its own external security model for SharePoint that allows administrators to open specific and targeted content to external users without putting internal and secure data at risk. Users can register for external access, change their existing password and maintain their individual account information.
Perhaps it makes sense to determine which applications not to move into the cloud. Experts agree that databases, with their high I/O requirements, are better left in a standing server. Also, if an application server is operating at 80% capacity, it might as well be left alone. Most servers, however, are operating at 10% to 15% capacity, a tremendous waste of compute power and capital expense, according to McKinsey & Co., a global consultancy based in New York.
Another inconvenient truth is latency. Before moving an application to the cloud, consider whether it requires microsecond response time. "You're not going to get that over the Internet; it just takes too long," said Michael Salsburg, chief architect for Unisys Cloud Computing in Blue Bell, Pa. "You're going from microsecond speeds on a LAN to milliseconds on the Internet. WAN latency can increase by 500 times," he said. With the wind at your back, you can transfer about a terabyte a day to a server in the cloud; if you have tons of terabytes, you're better off putting them on disks and shipping them, he added.The cloud is not going to replace everything; it's not good for everything. IT is very pragmatic. There are still mainframes.
senior product managerThe Planet
Other truths will indicate whether putting particular applications in the cloud makes sense. Carl Meadows, senior product manager for The Planet, a Houston-based website hosting company with a free public cloud in beta, suggests that CIOs ponder these questions:
- Does the application need to be highly available? "When it comes to IaaS [Infrastructure as a Service], you are buying a virtual instance that exists somewhere. High availability and global distribution is on you; it's not solved just by going to the cloud," Meadows said. CIOs should consider acceptable downtime: You can pay for high availability or recognise that it's an internal application that needs to be very available.
- What elements of a workload can be scaled out? "If you can clone a workload and drop another image in, that's where orchestration on cloud services shines," Meadows said. You can also offload services to better tune a workload, like moving mail off servers.
- What is the demand volatility? With a production workload in the cloud, you're trying to automate peaks; you need to determine the frequency of change, and pay for the most basic unit to support that. Hourly payment structures are great for project workloads and spiky activity, Meadows said, but with a steady-state application, you don't need an hourly rate.
- What are the integration requirements? Does the workload need to integrate with an internal LAN? Is it an extension of a workload or a new workload?
"There's a common misconception that the cloud is going to replace all in-house data centres in the next few years," Meadows said. "The cloud is not going to replace everything; it's not good for everything. IT is very pragmatic. There are still mainframes."
Unisys' Salsburg advises that enterprises align applications with the appropriate cloud: public, for nonsensitive, low-CPU apps, such as storage of old emails; private, for highly sensitive data like financials; and hybrid, for customer-centric applications that use a Web front end tied to back-end data. Workload requirements, such as transactions per second, storage requests, network traffic, among others, need to be evaluated as well.
Let us know what you think about the story; email Laura Smith, Features Writer.