The First Step into the Cloud: Which Kinds of Applications Make the Most Sense?

By George Reese
June 23, 2009 | Comments: 2

For the IT organization that has bought into the cloud computing vision, determining how to make that first move into the cloud carries frightening risks. If you pick the wrong application, you could end up costing your company money and putting an important information system at risk. Picking the right system, however, can provide a quick financial win for your organization while delivering a valuable learning experience that you can gradually expand to the rest of your infrastructure.

If you are a small or medium-sized business (SMB), this discussion is moot—it's foolish for an SMB to ever own any servers for any reason. The risks and costs of managing these servers will always exceed the risks and costs associated with leveraging cloud equivalents. It's significantly harder for a larger business with an established IT infrastructure for several reasons:

  • The company likely has hundreds of systems and it would be impossible to move all of them into the cloud at once.
  • Even if you could move them all into the cloud at once, it would be a terrible strategy from a change management perspective since you are introducing an unknown into a proven infrastructure. Your first task with any new technology is to prototype it and to understand how it applies to your environment.
  • Different applications have different risk profiles. The impact of completely mucking up the deployment of a sitelet around a marketing campaign is much less significant than mucking up your fulfillment system.
  • You don't simply need to learn about cloud computing and cloud technologies, but also about how you organization's processes can absorb the tasks necessary to manage a cloud infrastructure.

Most IT professionals I speak with recognize these concerns. Consequently, I am often asked what applications make the most sense as a starting point for playing in the cloud. Here's my short answer: start with the IT annoyances.

What's an IT Annoyance?

Each IT organization has processes and procedures that exist to efficiently operate core business systems and protect the integrity of the data moving through those systems. A health insurance company, for example, has a number of systems that manage patient data. These systems require strict adherence to HIPAA standards. To keep IT costs down, the typical health insurance company will have advanced IT systems, policies, and procedures that guarantee adherence to these standards in a highly efficient manner.

When that same company's marketing department attempts to put up a short-lived web site around a spring marketing campaign, however, those technologies and processes that save the company millions of dollars and untold risk become barriers that limit business flexibility and ultimately cost many times what they otherwise should cost. These systems are the IT annoyances. They are annoyances because they are poorly aligned with IT's core competencies and distract IT from its mission. Such systems are, nevertheless, important to the business.

Identify an Annoyance

One company's annoyance is another company's core system. It's all relative to what your core competencies as an IT organization are. It could be an annoyance because it's in a non-standard technology or because it requires different management processes or non-standard service levels or any other number of reasons. If you examine your systems along three dimensions (efficiency, importance, and risk), you will notice that generally the higher the importance of a system, the higher the risk of its failure and the more efficient your IT department is at managing. On the other hand, annoyances tend to reflect those dimensions in opposition:

  • They are less important to the business as a whole than core systems.
  • They often cost you more to build and maintain than peers for whom the same systems are "more core".
  • The risk of failure associated with these systems is much lower than for core systems.

For most companies, marketing systems tend to fall into the annoyance category for a couple of reasons:

  • Unless you are an ad agency, marketing systems are probably not the most critical systems in your business. Marketing is nearly always a tool that supports the core business and is not itself the core business.
  • As disciplines, IT and marketing occupy opposite ends of the universe and processes for the two disciplines almost never align.
  • IT generally requires planning and structure; marketing must be able to react rapidly to external factors.
  • If a marketing system fails, it's a black eye on the business--it's not a heart attack.

My favorite systems to move first into the cloud are thus marketing systems.

Why the Annoyances?

When you adopt a new process or technology into a business, you generally look for a project that fits the following characteristics:

  • It can provide a quick "win".
  • It can provide practical experience implementing the new process/technology that you can later apply as it gains wider adoption.
  • It can be allowed to "fail" without harming the organization.

By looking at an annoyance as the first cloud project, you are looking at a situation that in which you are almost guaranteed to see cost savings and that won't harm the business if things don't go right. Picking the right annoyance will ensure that you can apply what you learn towards follow-on projects.

Anatomy of the Ideal Project

With all of the generalities out of the way, here are the characteristics I look for in a first cloud computing system for a large business:

  • A database-driven marketing application—ideally one that could benefit from the cloud's ability to dynamically scale (database systems are likely critical to most of your systems, so you need to learn how to deploy them into the cloud)
  • Implementations using Open Source and/or free technologies (LAMP, PostgreSQL, Java/JSP, Ruby on Rails, etc.) (you don't want to deal with a bunch of licensing issues as part of your first deployment)
  • Your team has a solid understand of all the technologies that will support the system (you don't want to be learning cloud computing and PHP and MySQL systems administration all at the same time)
  • You can quantify what the system would cost you to run in your existing infrastructure (you really should be able to prove the success of your first system)
  • Minimal integration requirements (you can figure out how to tie the cloud into your VPN in your second or third project)
  • You can set aside $5,000 to $15,000 in budget for the purpose of prototyping the cloud (the cloud is unfamiliar to you—it will take longer to deploy your first cloud system than it otherwise would take you to deploy in the infrastructure you know and love)

You might also be interested in:

2 Comments

Good points regarding a thoughtful approach to initial cloud deployments.

What about moving moving non-critical data to the cloud for access in the field via mobile applications? As a pilot program it is an entry to both clouds and mobile. I'm working on a project to access Amazon SimpleDB data from Android phones.

It sounds like it would functionally be a good candidate for the Amazon cloud. IN fact, it sounds like an application that's ideal for the cloud.

Keep in mind, however, the first deployment may take longer than you expect as you learn about the realities of operating in the cloud. You never know what you don't know when you are taking on a new technology.

News Topics

Recommended for You

Got a Question?