Theres a few rules that I've learned while working with Salesforce/Azure/Amazon Web Service/Google App Engine that everyone should follow:

1. Manage your DB read/writes - It may seem beneficial to do a write then a read for the latest data, but manage the data in cache so you don't waste precious resources. Many Cloud providers lock down your DB read/writes, keep those limits in mind.
2. Be mindful of memory - All of the cloud providers, especially Google App Engine and Salesforce have limits on Heap size. Refresh your lists, make sure your heap time is properly managed. Everyone provides some form of garbage collection, but they won't watch your resource limit for you. 
3. Always cache your public pages - All of the provides have a hard limit on bandwidth. If you don't have proper caching, you'll hit your limits and lose money when you don't need to. 
4. Make "More Hardware" your last resort - As software engineers we usually prefer to say "Toss a few boxes on, cluster it, and boom were golden". When it comes to the Cloud resources = money. Unroll loops, deallocate memory how you can (clear list and maps OUT after they aren't needed), and be mindful of memory leaks. 
5. Triage scheduled jobs - Scheduled jobs are those special processes that happen when you need them to happen but be very careful. If the cloud goes down and your needed job doesn't happen, you could be in a heap of trouble. If its REALLY necessary then have a manual process or a servlet setup that can be run later on to make up for that missed job. 
6. PAY ATTENTION TO ENVIRONMENT UPDATES! - When your Cloud provider releases a new SDK, updates your environmental variables, or makes a change in any way, KNOW ABOUT IT. Cloud providers are constantly upgrading their product, and since its in the Cloud they will update it and you will need to deal with it. There is no "OK this app works with Tomcat 5.5, so we don't really need 6.0." No, they will give you 6.0, and your application could crash and burn. You may need to make some changes but so what, get with the program or get off the Cloud. 
7. Someone else built your security - Every cloud provider has their own security setup. Now you don't have to build one, great! But it keeps changing, not so great! How your provider chooses to manage your apps security, authenticated or unauthenticated, can and will change. Like before, pay attention to security updates. Make sure your app is XSS and XSRF safe even if your provider makes that guarantee. 
8. Is your application Cloud Ready? - Your Java application uses Struts. You wan't to use either Google App Engine or VMware's vSphere. Uh-oh, GAE Java uses Spring(sort of) and vSphere uses SpringSource. OK, should you rebuild your app or go over to another provider such as Amazon Web Services? Know this before you start refactoring.
9. Know your costs - If your app needs to grow, the Cloud can accommodate………….at a cost. Its hard for a developer to see dollar signs when they need something done but you need to learn that with great power comes great responsibility. If you want to start your own Cloud ISV, make sure your income statement keeps those growing Cloud costs in check. 
10. Remember: You're Sharing - You could have three boxes, you could be with three other people on a single box, you do not know. Keep in mind that if you screw up big, it can affect alot of people. Safe virtualization techniques by your Cloud providers can prevent this from happening from the most part, but take some of your own precautions. Most cloud providers don't allow for any real multi-threading, but if they do remember the following: avoid deadlocks and race conditions. These aren't just kernel issues, they're hardware issues and can do some real damage to other peoples applications. 

Nearly all of my recommendations are the the same as if you were designing a C application for a router. Be safe, be secure, and watch the expenditure of money and resources. Keep these things in mind and you will have a great experience in the Cloud. 

If ever there was a ringing endorsement for the cloud computing model, it’s when the two 800-lb gorillas of computing join the game. What was considered a joke to most just 10 years ago became a very serious battle for cloud supremacy when Microsoft and IBM announced their entrance.

Microsoft is well known in business circles for its Office and server applications, but hasn’t done much in cloud computing. After a few secretive years of development under the code name Red Dog, Microsoft pulled the covers off of the finished product, “Windows Azure.” 

Much of the same can be said of IBM. Big Blue has been historically known for providing mainframes, servers, and data centers for large enterprises to run their businesses on, but didn’t have much in the way of a platform as a service. That’s now changed with IBM’s large push into cloud computing.