A discussion around cloud development for Software as a Service (SAAS) offerings is quite clear cut; there are gains to be made using the cloud. Both in speed of delivery and cost. How this is done is much more complex and confusing. Finding organisations that want to share how they do it is rare. This is to be expected, as it is part of their competitive edge. However, based on the general discussion on architecture approaches for multi-tenanted solutions there are the two major options; dedicated resource models and metadata driven models. Two organisations that are forthcoming with their models are Salesforce.com and Atlassian. They are examples of each approach.

Dedicated Resource

The dedicated resource approach is basically one stack per customer. Resources can be shared where appropriate, such as security, but the model is centred on simplicity and optimisation. Atlassian is a supporter of this model. They discuss their drivers for going this route here and describe their architecture here. In a nutshell, they found that the enterprise software they build did not fit a true multi-tenanted solution. They consider that an enterprise will want more control that that usually provided by a pure SAAS and that designing for multi-tenancy adds a lot of development complexity. Cost savings can be achieved by running multiple stacks in containers on the same machines. Atlassian spends a lot of time on benchmarking and optimisation to make the most of the resources available.

Metadata Driven

Metadata driven models are what most people consider a SAAS architecture. This is where users share the same interface and the separation of customers is driven with filtering. Salesforce use this model where multiple users share the same instance of Salesforce. All their data is tagged by an Organisation ID. Multiple checks are put in place to ensure that data does not leek between customers. A detailed description of their architecture can be found here. Salesforce still partition customers into particular Instances of their software to maintain performance. They also mention the complexity and importance of ensuring the logical separation between customers.

The Optimal Way

The challenge OptimalBI faces when developing products is that our solutions are a blend of in-house and third party components. In-house components we have complete control over so can be built with the appropriate controls for multi-tenancy. Third party products are limited to their design. Wrappers can be written around these tools, but this adds complexity and may break over time. In considering which architecture approach should be taken things to be considered are:

• Are third party products used and what level of multi-tenancy support to they provide? If there is none then the following needs to be considered:
• What level of complexity of is there in developing a wrapper to achieve logical separation?
• Will it scale for true multi-tenancy?
• What type of product are we building?
• Is this a mass market or more niche enterprise tool?
• Is there a market for on-site deployments?

In our latest product development, currently called P1030, Neo4J in a critical component of the solution. It is not designed for multi-tenancy in any aspect. Exposing the Neo4J query language Cypher would require us to parse and apply filters by changing the any queries the user submits. The features of a true multi-tenanted cloud solution such as high availability, performance scaling are only part of the Enterprise version of Neo4J. This doesn’t match our desire to keep costs down for a product with a small initial user base.
These considerations would lead me to believe a dedicated resource model is more appropriate.
Thanks, Ben