How to Get Started With Cloud Computing

Some IT departments want to utilize public cloud infrastructure as a service (IaaS), or Software as a Service (SaaS) but aren’t sure how to get started.  I’ll discuss some ways to use cloud computing as you flesh out how you will use it and integrate into an existing information technology architecture.  If you’re not sure what IaaS is, read my previous article, “Exploring Amazon’s Cloud IaaS & PaaS”.

Testing the water

Like swimming, people investigating cloud computing want to “test the water” before they get in.  For those that want to try IaaS, I suggest setting up a small development and test environment for your team that will allow you to start learning about how to set up and take advantage of IaaS.  While you are at it, you can test features like load balancing and fault tolerance as well as looking for compatibility issues you might run into.  ReadWrite Cloud had an interesting article about WoundVision using EC2 to better understand the possibilities of using IaaS.

Testing the water can be low cost (or zero cost).  For example, as part of AWS’s Free Usage Tier, new AWS customers can get started with Amazon EC2 for free. Upon sign-up, new AWS customers receive the following EC2 services each month for one year:

• 750 hours of EC2 running Linux/Unix Micro instance usage
• 750 hours of Elastic Load Balancing plus 15 GB data processing
• 10 GB of Amazon Elastic Block Storage (EBS) plus 1 million IOs and 1 GB snapshot storage
• 15 GB of bandwidth out aggregated across all AWS services
• 1 GB of Regional Data Transfer

To test SaaS, try implementing a pilot program to try SaaS.  The pilot should be non-critical and low cost but offers real value.  Some are free, like Evernote.com and dropbox.com.  It doesn’t mean that you should toss out evaluation and decision making criteria, but you can still test cloud SaaS approach to software in a low risk way.  The pilot allows IT and users to see SaaS in a real-life scenario.  Nothing beats really using a service to start the process of understanding the benefits and how it could deliver value to what you are doing. In today’s world, many people are already using SaaS but just don’t realize it.  Email is probably the biggest breakout SaaS product.  If you are using something like Gmail, you are already using SaaS.  Given that integration with e-mail system is normally pretty low, consider moving your e-mail service to the cloud by setting up a Google premier domain.

Use the cloud for QA

Using IaaS for quality assurance (fancy way for saying “test system”) is a way to go a little deeper into IaaS and reap some real benefits.  If you can replicate your  computing environment close enough for functionality testing or user BETA testing in the cloud IaaS, you can test the cloud model at the same time.  It’s a low risk way of testing the waters and better understanding the capabilities and return on investment that IaaS might bring.  If your application needs to exchange large amounts of data with other corporate systems, you’ll want to be careful to ensure that your network doesn’t become a performance bottleneck or induce unexpected expenses.  Using IaaS for QA activities allows you to quickly set up that environment, conduct your tests and then dismantle it.  If you take a snapshot of your environment, you can quickly re-deploy it for more testing should that be needed.  This is a perfect example of how IaaS can allow flexibility and speed without all the headache of setting up your own hardware.

Try moving just a portion of your web application to the Cloud

When you are ready to try cloud computing in production but not fully commit, carve out a portion of your application that could reside within the cloud.  Using something like Amazons IaaS or a SaaS will allow you to further test the cloud in real world conditions.  This is a big step though and there are two things that need to happen as part of your planning process.

Take some time to assess what you want to test or achieve as part of this next step that will be used as part of your post-implementation assessment.  Once you have defined your goals, put together a simple way of how you will measure the value at the end.  

In addition, I suggest that there needs to be a thorough understanding of the application architecture before taking this next step.  In some ways, you need to approach this as if you were remodeling your office building.  Before a builder starts knocking down walls, she first develops a set of “as is” architecture drawings so that she doesn’t knock down a load-bearing wall by accident.  Moving any piece of your system to the cloud forces you to understand your application system and business application of that system in its entirety so that you understand the integration points and don’t run into any unexpected business use cases.  You will need to assess all the implications of having processing done somewhere else, like latency and how much data will need to flow over various networks and how you will deal with network failures.   Taking functionality that already exists on your local infrastructure to the cloud may lower the risk so that if things don’t work out as planned , you can redirect that capability back to its original home in your data center.

Use the Cloud for backups

There are several cloud providers that offer backup services for clients and even for the data center.  If you encrypt your data before sending it off-site (which most client based backup solutions do), it’s low risk and gives you immediate access to “off-site” backup capabilities that you may not have today.  Some companies are using Amazon’s AWS S3 storage to host critical company data as part of their disaster recovery plans, which is designed to provide 99.999999999% durability and 99.99% availability of objects over a given year.  See my earlier article on client backup solutions.

Implement a backup data center for high availability and disaster recovery

Another opportunity [available] is to improve your disaster recovery capability by using IaaS as a “backup data center” for partial or complete recovery.  If you’ve determined that you can run your app with no compatibility issues on public IaaS, or excessive security and performance risks, think about using IaaS as a high availability platform.  Once you work out how to keep your data at an acceptable level of currency, you only need to provision enough processing capability in your “backup data center” to enable the data replication processing, thus keeping costs low.  Should your primary processing capability fail, you can quickly scale up at your backup environment to become your primary.  This can completely automated by having a external load balancer detect the failure start to send traffic to the backup site, and (if you use AWS) initiate a pre-programmed auto-scale routine that auto-creates more compute capacity on demand.

There are a growing number of case studies published on the Internet on using AWS as a component of your disaster recovery.  Take a look and evaluate how you might be able to take advantage of this approach.

Going to the cloud doesn’t have to be an all or nothing deal and it makes a lot of sense to play with different models in a low risk way as you evaluate what the right direction for your organization is.

References

• Exploring Amazon’s Cloud IaaS & PaaS
• My experience using Amazon’s AWS
• Advantages of Cloud Computing
• Risks and Challenges of Cloud Computing
• AWS free usage tier
• AWS Case Studies
• A Look Inside Amazon’s Data Centers
• AWS Case Study: What’s Up Interactive
• Oracle DRP using AWS Presentation
• When Amazon’s EC2 Isn’t Potent Enough for Your Cloud Hosting - ReadWrite Cloud by David Strom.

- Chris Claborne