In my travels speaking with organizations looking to move to the Cloud, I’m often confronted by folks who have an innate distrust of all things Cloud. These folks are easy to deals with; I respect their opinion (despite entirely disagreeing with it) and am happy enough to leave them alone to (eventually) come to rational conclusions themselves.

The other classes of people however are those who are open to looking at new approaches, but who want to hear how to do it, along with some tips and tricks for what to look for in their deliberations. I was stoked to receive an email the other day from Stan Klimoff, Director of Cloud Services for Grid Dynamics. In his email, Klimoff sent through a series of simple tips that he uses when talking to folks about a move to the Cloud.

Without further ado then, here follows Klimoff’s four tips for organizations heading to the Cloud;

1.    Identify business processes that can benefit from using the Cloud. For each business process, one should keep in mind the reason to use the Cloud in the first place. Possible reasons for using the Cloud include:

• Cost
• Business agility
• SLAs

2.    Break down the IT processes and applications that support your business processes identified in the previous steps into classes according to the benefits that you want to receive from transition to the Cloud. Depending on what the goal is, the approach will also vary.

3.    Analyze the following items to avoid potential road blocks.

•    Identify the data that is touched by each IT process. Is there any data that has to stay in-house for security or compliance reasons? You may need to change IT processes so the sensitive data is not affected by the transition.
•    Analyze data access patterns. Data-intensive applications are usually not the best fit for a Cloud, unless you plan to put all of your data in the Cloud.
•    Identify security domains. As with any external provider, one should always treat the Cloud as a separate security domain. What is less obvious is that there are different security domains within Cloud itself. Do you need to satisfy PCI DSS requirements? Can your Cloud provider give you guarantees on the data boundaries?
•    Determine availability and reliability targets. Not all of the Cloud providers provide strict SLAs on availability and even when they do, those can be misunderstood (as happened with the notorious Amazon outage earlier this year). However, applications that are more tolerant to weaker availability SLAs can be a good fit.

4.    Calculate total cost.

It’s a good first step; I’d argue with Klimoff’s focus on total cost however, I’ve long said the value from a move to the Clouds goes well beyond any cost savings. The first three points however are spot on and worth using for organizations considering a move to the Cloud.I’d be interested to hear the tests and processes that others use when talking with organizations making the change – feel free to join in the conversation!

We’re covering these areas of Cloud Computing on an ongoing basis at CloudU, an educational series aimed at increasing the knowledge and skill that SMBs have about the Cloud.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

3 Comments
  • Hi Ben, I often hear clients regurgitating the usual high level goals (i.e. cost, agility, SLA) for every strategic initiative. The winners are the individuals who take time to establish metrics, baselines, and ongoing measurement activities to gauge improvement. What metrics do you or Klimoff consider to be appropriate?

    Also, is there a three-legged stool situation here? For example,
    is there often a tradeoff between cost and SLA. Take the classic Netflix ‘architect for failure’ use case delivering SLA benefits while also driving up development and operational cost.

  • Too simplistic.
    As much as technologists like to persuade based on X number of simplistic rules, the reality is different. For example where You have significant orgranisational intelligence (local and functional knowledge) invested in a complex legacy desktop application it is so easy to fall into the trap of better process wins over cloud while ignoring the obvious i.e. not getting user buy in. Need to ask the question; Better for whom?

  • This is absolutely spot-on. One of the greatest pitfalls organizations fall into is adopting the cloud simply because the cloud is “new” and they see it as a silver bullet for delivering IT.

    It’s highly unlikely that deciding to move a business critical, data and compliance heavy application to the cloud is going to be a positive experience for anyone involved.

    Choosing a workload like dev & test, or computing assets for an R&D organization on the other hand will likely be much more successful and give an organization the confidence they need to expand their usage of the cloud.

    At the end of the day, it’s about evaluating your computing requirements and choosing the right resources to run your applications on.

Leave a Reply to Chris HaddadCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.