Although the application UI was treated with a welcomed ‘facelift’ (we were told that LitwareHR UI was "too 1990s"), the main effort for this release was to move from local storage infrastructure (SQL Server) to ‘cloud storage’ in the form of SQL Server Data Services (SSDS).
Our intent was to extract the architectural challenges and best practices related to cloud storage in the context of line of business (LoB) applications. After having learned a lot through this exercise, I can safely say that, from an architecture perspective, the decision between local storage (SQL) or cloud storage (SSDS) will not be a no-brainer. As with pretty much all architectural decisions, it is all about trade off. The choice that will make most sense for your application will mostly depend on (a) the type of application you are building and (b) which are the challenges you want to own and which are the challenges you want to push to the underlying platform.
For example, in the specific context of LitwareHR, SSDS greatly simplified the multi-tenancy and customization aspects of the data layer; i.e. a lot of ‘plumbing’ code related to entity customization went away thanks to the flexible entity model natively offered by SSDS. On the other hands, the data model as well as the querying code had to be modified since SQL (used in our previous implementation) and SSDS do not share the same programming model (at least not at this stage). Also, SSDS not supporting JOIN required some new type of plumbing code e.g. cross-container search. The management of transactions had also to be rethought. Another example is the need of a better caching strategy on the business logic side of LitwareHR as the data layer (being in the cloud) is across a wide area network from the business logic, on the other hands we did not have to worry about the growth, scalability and availability of the storage subsystem anymore. From a hypothetical business model perspective, there would be changes as well, since on premise SQL server or licensed under SPLA would have a different cost curve from how SSDS would charged us. Specific comparison and analysis was not possible as SSDS has not disclosed its pricing model yet; but again, I do not expect being a no-brainer either and will depend on your storage access patterns, variability of access etc.
For those of you interested in deeper architectural challenges, trade offs and solutions chosen, I can only highly recommend you to read Eugenio’s mini-series:
Also, for those of you wanting the see the goods, before investigating further, a screencast showing this release of LitwareHR is available (with sexy Argentinean accent) here.
For those of you wanting to experiment with SSDS, you can register for a beta account with this service here.
Probable next steps will be to do a similar effort around ‘cloud Identity’ and implement some of the concepts described here by my good friend Vittorio (a.k.a Dr. Identity Maximus) using the BizTalk Services Identity Provider; but let’s not get too much ahead of ourselves and let’s start digesting (and enjoying?) this new release of LitwareHR embracing cloud storage for part of its architecture.
This overall exercise was extremely valuable to us and allowed us to better understand aspects of cloud infrastructure in the context of a LoB application (as opposed to a more consumer oriented / social application), hopefully what we are sharing with you today (code, guidance etc.) will be as valuable to you in your investigation or implementation of cloud infrastructure based solutions.