Buying a cloud service isn't just about the nuts and bolts of computing and storage, cautions Dave Powers, associate information consultant at Eli Lilly & Co., which has been using Amazon Web Services (AWS) since April 2008. "It's about all of the Web services and capabilities built on top of the cloud that makes being able to spin up some computing, do some storage and then tear it all down very low-friction."

Before committing to a cloud services provider, IT execs should understand exactly what resources they have on hand, what they're buying, and how running on a public, shared server infrastructure will affect applications and business processes.

Tony Bishop, CEO of Adaptivity, a consulting firm specializing in next-generation IT infrastructure, puts it this way: "As much as cloud does away with the limitations of hardwired infrastructure, it doesn't alleviate the need for proper planning and IT integration discipline. It amplifies it."

Here are some practical guidelines on issues to consider and questions to ask when buying cloud services. IT technologies, the top priority is figuring out whether an application needs modifications or a complete re-architecting for use in the cloud. "In some cases, your application architecture could even constrain your cloud options," he says. Golden uses this simplistic case as an example: "Say you have something running on an Alpha chip-based computer. You're not going to find a cloud service that can run Alpha binaries."

Failure to rethink an application might even defeat the purpose of using a cloud service, says Eli Lilly's Powers. This was one of the company's first lessons learned as an Amazon Web Services user, he adds.

"At first, we literally picked up a workflow from our internal grid environment and dropped it into the cloud. While that worked, we learned that we had constrained ourselves. In the cloud, we had this infinite amount of compute and storage, but our application, designed to run inside Eli Lilly's fixed-size computing environment, couldn't take advantage of it," Powers says.

Now, the Eli Lilly team might chunk up an application and move data into and out of the cloud in smaller, more consumable pieces, or it might store some data in the cloud, so an application doesn't have to retrieve it from the enterprise datacenter, Powers explains.

And, Powers makes sure every cloud-destined application accounts for fault tolerance. "If you're buying infrastructure as a service, you have to understand that a machine can go down at any time, and your application design needs to consider that," he adds.

Tom Nolle, CEO of CIMI, a high-tech consulting firm, advises that developers work through the deployment process before committing to a cloud. "You need a little flow diagram: Here's the cloud. Here's my application inquiry going into the cloud. Here are the data sources needed to fulfill that request and here's where they flow and how they get moved. Now I can see everyplace I have data flowing around, I have a vulnerability to network behavior and I can begin to manage the vulnerability."

Latency, response times, throughput -- these are watch points across the network. As Powers says, "We wouldn't want to be moving terabytes of data at a time in an interactive session for scientists; they wouldn't get the response times from the cloud they're accustomed to on the Eli Lilly network."

Related Articles

• Cloud Security: The basics
• Six Misconceptions About Cloud Apps
• How Not to Build a Cloud
• Cloud Computing can help Enterprises Save Big
• Where is Your Cloud? Four Compliance Best Practices

Latest Articles

• The Quiet Threat: Cyber Spies are Already in your Systems
• Responding to Security Questions Successfully
• Security Secrets the Bad Guys Don't Want You to Know
• Don't Wait for Adobe Sandboxing to Secure PDF Viewing
• The 4 Tiers of a Secure B2B Framework