Azure Best Practice #4: REST is In, SOAP is Out

Best Practice #4 is to favor REST over SOAP, except for those scenarios that demand SOAP.

When it comes to cloud computing platforms, it's a RESTful world and Azure is no exception. The vast majority of the services in the platform can only be accessed via REST (even if you're using .NET library code, REST is what's happening under the hood). SOAP isn't completely out of the picture, however. For functionality that depends on WS-* protocols (such as federated security) Azure does use SOAP.

Which should you use for your own Azure-hosted web services, REST or SOAP? It makes sense to emulate what the platform itself does and favor REST, except where you must use SOAP. Using SOAP makes sense for compatibility reasons or when you need WS-* functionality. When these conditions don't apply, a RESTful interface is recommended. It's simpler and more in line with "how we do things in the cloud."

The popularity of REST is due to its simplicity and its resource-oriented nature while SOAP has become cumbersome in the opinion of many. There is a good discussion of whether SOAP and REST are complements or competitors on David Chappell's blog.

Azure Best Practice #3: What's Good for SOA is Good for the Cloud

Azure best practice #3 is to apply SOA principles to your cloud applications. The core ideas of SOA apply equally strongly to the cloud:

• Software components are loosely coupled.
  
• Message-based programs do a lot of the work.
  
• Boundaries of communication/reliability/security/transactions are a key consideration in solution architecture.
  
• Use of standard protocols and message formats provides broad interoperability.
  
• Stateless service development is encouraged which facilitates easy load balancing.
  
• Communication is presumed to be expensive.
  
• Coarse-grained interfaces are preferred over chatty interfaces.
  

This isn't a recommendation to use SOAP, however. See Best Practice #4 for a discussion of SOAP vs. REST.

Azure Best Practice #2: Keep Code and Data Close Together

Azure best practice #2 is to keep code and the data it needs close to each other. If the code lives in the enterprise, so should the data it frequently accesses. If the code lives in a cloud data center, that's where its data should be also--and in the same geo-location.

This best practice is simple common sense: going between the enterprise and the cloud over the Internet is not terribly fast, so you want to keep it to a minimum.

This is not an absolute rule, since you may have a perfectly legitimate reason to interconnect enterprise code with cloud data or vice-versa--but you should avoid this kind of cross-traffic when it isn't necessary.

You can use the affinity group setting in the Azure portal to ensure related hosting and storage projects are running in the same geo-location.

Example: you have a cloud-hosted web site and you need to store user profile data. The best location for that user profile data is cloud storage.

Azure Best Practice #1: Always Run at Least 2 Instances of Any Role

Some best practices for the Azure cloud computing platform are starting to emerge, and I'll be blogging them as I discover them. I expect the sources for these will be a combination of Microsoft guidance, personal experience, and experiences shared by others in the community.

Best Practice #1 is to always run at least 2 instances of any role (this applies to both web roles and worker roles). There's a very important reason for this: your application may be highly unavailable if you fail to do so. Why? Because Azure is constantly upgrading your instances with the latest OS patches. From what I understand talking to people on the product teams it's doing this very, very frequently. When you have 2 or more instances of a role running, Azure is careful to keep some of them running through the concept of upgrade domains; but when you're running a single instance you're going to have periods where you can't access your application.

I first encountered this issue when I wrote the Lifetracks demo application last year around Thanksgiving, though I didn't recognize the problem for what it was at first. Lifetracks would work after deploying it, but I noticed after a few days it would be "down" and I'd have to re-deploy it. In February I was at a Microsoft event and mentioned this behavior, which I had chalked up to instability in the platform. When I received the advice to run more instances I was skeptical this would make any difference, but I'm happy to report Lifetracks has stayed up from the moment I did so, over 10 weeks ago. So I can attest this is a best practice from direct personal experience.

Some additional evidence is the 22-hour outage the Azure platform experienced in March 2009. If you read Microsoft's analysis of the problem, you'll note that single-instance applications were primarily affected while multiple-instance applications continued to be available. The guidance to run at least 2 instances is stated there.