Cloud computing, it is now another one of the buzz words that is being used like crazy.  However, in talking to some of my other CTO counterparts it is obvious a lot of people don't really understand what it means to move their services into the cloud.There are lots of articles talking about the benefits of cloud computing.  This one by Slate does a good job articulating the findings from McKinsey & Co on the benefits for small business particularly around peak traffic, lack of contracts and only paying for resources that you use. The thing is that in order to really reap most of the benefits of cloud computing your software needs to be designed to take advantage of the cloud.Here are some best practices to consider when thinking about designing an application for the cloud:(Note, I don't have extensive experience operating on several different cloud computing platforms, primarily Amazon's EC2 -- you can read about some of the other's in this Information Week article)

1. Assume your instances are going to go down. You can't ever assume an instance will be available and your system better have enough redundancy to handle and fail over if something becomes unavailable.  This means making sure you know how to persist state if pertinent. (war story: In the early EC2 days we used to have instances go down all the time, sometimes 2-3 at a time. This doesn't seem to be the case anymore, but unlike hosted environments where you have a dedicated piece of hardware you can't make the same availability assumptions with cloud services)
2. Think about your data.  Make sure you think through how to make your data available and how to propagate changes to your data.  This will help you design your services as autonomously as possible, placing caching where it is needed, and make sure there are clear defined interfaces for interacting with that data.
3. Deploying to the cloud is different.  No longer are the days when you need to worry about log files filling up the disks (you can just store everything perpetually on a cloud storage solution like Amazon's S3), but now you have a different set of worries.  The software and tools required to deploy to the cloud are different.  And a system administrator is not necessarily the best person to manage the software int he cloud.  In some ways there is a new job--a cloud engineer--that understands the system internals but is also very capable of writing code.  However where one system admin could manage a couple handfuls of boxes, one cloud engineer can manage 100s or even 1000s with the right set of scripts and monitoring.
4. Have monitoring and lots of it.  This should be true of any application, but having good monitoring and diagnostics will help you figure out problems quickly.
5. Isolate your development environment, from your test/staging environment, from your production environment.  This should also allow you to do more realistic testing when your test environment can be spun up and down as needed for testing--and it can look exactly like your production environment.  But keep them separate to ensure good testing.  This will also allow you to do things like accurate load testing and performance testing.
6. Think about your points-of-failure. It could be a gateway handling incoming requests, it could be DNS, or it could be your application servers.  Know what the weak-links are, and accept that vulnerability or devote resources to it.
7. Make sure you have the tools/automation in place to take advantage of "peak" scaling.  This is touted as one of the "benefits" of cloud computing but it will only be an benefit if you can make it automated (at least mostly automated--for the services that spin up 3,000 instances up and down you can probably get away with some manual intervention).  Build the logic and instrumentation into your services to make sure that you spin up and tear down new instances as you necessary.

What are your best practices when designing your applications that run in the cloud?