LitwareHR on SSDS - Part I - Multi-tenancy & Flexibility
SSDS's application model and features map quite nicely to our customization and multi-tenancy requirements in LitwareHR.
A significant amount of code in LitwareHR is in the generic, multi-tenant, extensible data access. Our multi-tenant database performance guide, compares different extensibility approaches (XML datatypes, extended tables, fixed columns), their advantages and disadvantages, etc.
All of that is greatly simplified in the version of LitwareHR that uses SSDS because of the built-in support for extensibility and tenant isolation in the service.
The ACE Model:
SSDS model is quite simple actually, it is referred to as the ACE model and it is basically a 3 level containment architecture:
Authority (the top level container) contains zero or more Containers which in turn contain sets of Entities. Entities have properties: intrinsic (like Id, Kind & Version are present in any entity) and custom properties which are user defined. Properties have a type (string, dates, numbers).
This model maps very nicely to LitwareHR requirements:
Authorities & Containers give us out-of-the-box tenant isolation for storage. Entities give us exactly what we need to provide each tenant a different data shape for positions and resumes.
In our current implementation of LitwareHR, there's a single Authority (owned by Litware for LitwareHR) with multiple containers: one for LitwareHR itself where all application metadata is stored (this is the equivalent of the old TenantMetadataStore), and one Container for each tenant that is provisioned.
Here's a subset of this model:
Because LitwareHR allows each tenant to change the shape of the Position entity, instances of this type are all different between tenants.
Notice that SDSS is actually more flexible than how it is used in LitwareHR. SSDS allows instances of any entity to have any set of properties and there's no schema forced into any particular instance. LitwareHR restricts flexibility at the tenant level, so all positions of a given tenant will have the same schema, but each tenant can have any schema they want.
LitwareHR Metadata Container
Entities stored in LitwareHR's metadata container will be used to drive the application: tenant information, UI, menus, views, entities schema for the tenant, etc.
Here's the result of a query against the demo LitwareHR container. You can see various entities stored there, including a serialized recruiting workflow definition:
The URI for this query is http://litwarehr.data.sitka.microsoft.com/v1/LitwareHR?q= which essentially means: "bring me all the contents of container LitwareHR in litwarehr authority" (note the format of the URI: http://<AuthorityId>.data.sitka.microsoft.com/<ContainerId>?q=).
SSDS query language (SLINQ) is a subset of LINQ syntax. For example, the query for retrieving all instances of particular entity type (e.g. "Tenant") would be:
"from e in entities where e.Kind=='Tenant' select e"
SLINQ is a subset and there are many features not available quite yet: projections, grouping, etc.
Currently, SSDS will return the whole entity, even if you just need a part of it. Of course you can still use LINQ on the client side to group, filter, etc. but over the wire the whole thing will be transported.
Quid Pro Quo:
Nothing valuable is free, isn't it? SSDS gives you unlimited storage, tremendous flexibility, geo-aware location. You don't have to worry about backups, operations, disk failures, power, air conditioning, machines, etc. You just use it.
But all this goodness comes at a cost: you don't "own" the database any more, you can't assume the database is "close" to you (too chatty interactions with it, will lead into latency issues) and the programming model you were used to is different: there are no tables, stored procedures, views, joins, etc.
You will have to decide whether these cons, out-weight the benefits in your particular scenario, and hopefully some of the lessons learnt in Litware, although impossible to extrapolate to every scenario, will help you make that decision.
As Nigel mentioned in MIX though, it is highly likely that many more features will be added to SSDS in the upcoming months.
In the next chapters, I will go deeper into LitwareHR on SSDS architecture, the challenges we faced and how we solved them.
