Designing applications for the cloud is not business as usual. Though it is not rocket science, it has several nuances which are somewhat counterintuitive.

Let me be more specific about what I mean by designing application for cloud. First let me exclude the whole universe of Software-as-a-Service where the applications are ready for use and need not be built. That implies, if you are planning to use Salesforce.com, Google Apps or any other similar service – this post may not be relevant. However, if you are planning to utilize Amazon EC2, Microsoft Azure or Google App Engine then read on…

There are many definition of cloud computing but I like the following definition:

“Cloud Computing is a market place where a computing service provider with large number of networked computer systems allows computing service consumer to use a slice of that processing power and storage and charging only for actual usage“

The interest in cloud computing is primarily because of the “pay for what you use” which also implies “do not pay for idle resources”.

First let us look at what resources you are charged for?

• CPU utilization
  • Amazon EC2 = Machine instance deployed (available in different capacities)
  • Google GAE = CPU cycle used
  • Azure = Instances of application deployed
• Data storage
• Data read-write
• Input-output bandwidth used

Let us look at it from the perspective of Amazon EC2 – which is the most widely use cloud services. So, the first implication is…

1: Your application needs to scale to multiple machines when load increases and has to have the capability to acquire and release machine instances dynamically.

When you are scaling, do you take a small instance or a large instance? You will need to do a balancing act…

2: If you acquire a machine instance but do not fully utilize it, you still pay for it. So, there is a strong case for growing your CPU capacity at smaller increment.

3: Since irrespective of the size of the machine, basic O/S, system software and application software will take the same amount of memory – smaller machine = smaller % of memory available for application. So, there is a strong case for using larger machine instance!

However, remember to best utilize what is available for free…

4: You pay for server power – client power is free. So why not design the application so that you utilize as much of client power as possible? HTML5 may become very useful and allow you to do several things on the client which would have been difficult without it!

Charge for data read-write and usage of I/O bandwidth is on what you actually use, so…

5: Optimizing you application to minimizing bandwidth usage and reducing data read-write will give you direct cost saving.

When you are dealing with multiple machines you are dealing with parallelism. It is not easy to think parallel … will require unlearning and will require diving into new technology area…

6: Understand Map-Reduce … Functional Programming.

7: For specific requirements, there may be more cost effective alternative to RDBMS – look around, there are several alternatives – for example, have you looked at Apache CouchDB?

Finally, what happens if Amazon decides to change the relative costs of the different types of resources? You design trade-off decisions might get questioned like suddenly you might find that the caching that you had done to reduce the data read-write has actually become counterproductive!

8: So what you may need is a flexible design where you can dynamically turn on or turn off certain parts of the code.

Read the original blog entry...