I read this article entitled Microsoft Commerce Server in the Cloud: a threat to Amazon? and this was after I saw at least 10 tweets on the subject in my Twitter feed. Given my proximity to the product and some pretty in depth details of Commerce Server 2009, I thought I would post my thoughts on the subject.
The new Commerce Server architecture exposes platform functionality through a new services layer, theoretically supporting a cloud based implementation. Unfortunately, there is also a check to ensure that all calls through the API are made in-process rendering this scenario unsupportable at this time.

Services
Let’s assume for a minute that we could make calls to theses new services using some sort of framework (like this Service Invocation Framework). I would install a complete instance of Commerce Server 2009 on a cloud computing platform, like Microsoft Azure or Amazon EC2, and make sure my services were properly exposed. Configuring the instances and exposing this new service layer would allow for applications to consume and render Commerce Server functionality. An example of one of these applications could be an ASP.Net website, a Silverlight application or even a mobile application – and not necessarily a mobile browser either! (think iPhone application)
One important point to mention is that Azure does not currently support the ability to install applications. You’d need to compile and deploy your code directly to their cloud computing environment. For testing purposes, I have begun to create an AMI running on Amazon EC2 and will provide more details in a follow-up post.
Content Distribution & Performance
So what if we did have this scenario running in a production environment? What are some of the other concerns? Performance certainly comes to mind. Overall server performance wouldn’t be much of an issue if you’re using a service like Amazon who provide multiple edge servers in different regions across the globe. But what about the performance of the eCommerce functionality? For this, Commerce Server provides internal methods for caching data that is used frequently, like catalog and product data. Commerce Server content is stored in datasets and is persisted in the cache using .Net caching (System.Web.Caching.Cache). This caching is divided up into 6 different areas and can be configured independently of one another to allow greater flexibility. The idea is to cache the items that change less for a longer period of time, like product descriptions for example. Pricing and inventory would be cached for a shorter amount of time, if at all, depending on your business rules.
In addition to caching, the new API is more efficient as well. By creating an instance of CommerceQuery, you can now attach sequence components to retrieve related items, such as cross-sells or up-sells or get inventory details all with one call to the API. This allows for less direct calls, and subsequently less calls to the database layer resulting in far better page performance.
Conclusion, Next Steps and Additional Links
Microsoft is already beginning to release many cloud based services such as SQL Data Services and SharePoint Services. It is not impossible to imagine cloud based eCommerce Services exposed via the cloud as well. Combine that with data managed by SQL Data Services and content management using SharePoint Services and we’ve got ourselves a viable cloud-based eCommerce platform.
Keep an eye out for part II of this post, where I will have results and samples from a proof-of-concept.
Microsoft Azure
Amazon EC2
Commerce Server 2009 Documentation