Recently, I came across a few good research papers on Cloud and Multi-tenancy design patterns. Typically, the primary audience for such articles is architects and technologists working for service providers (IaaS, PaaS, SaaS, BPaaS…) or software vendors. However, enterprise architects can also apply these architectural principles and patterns to build more
cost-effective and easier-to-maintain shared solutions.
In this post, I won’t bore you with an introduction of different Cloud services and taxonomy. I assume you’ve heard it all already. If not, have a look
here or just google “Cloud Computing”. My intention is to explain multi-tenancy and key characteristics, review some of the patterns and organize them in logical groups, and provide some references for further examination.
Background
For the last decade, large multi-national enterprises have progressively consolidated IT organizations / functions into Global Shared Services. This is a common strategy to reduce costs by eliminating redundancies, improve operational efficiencies by reducing technology stacks, vendors, and required skills through portfolio rationalization and standardization.
In such organizations, Enterprise Architects are routinely involved in building cost-effective shared solutions. These solutions are used by different business units around the globe requiring BU-specific look & feel, application behavior, and compliance with local customs & regulations.
In the enterprise, a common approach to building shared solutions involves deploying
multiple instances of an application or package to accommodate BU-specific functional customizations and non-functional requirements (i.e. load, performance, security…) on a shared infrastructure.
Instances are typically separated in different logical partitions or virtual machines, have their own dedicated resources (application server, middleware, database…), and are configured to meet BU-specific requirements.
Over time, what started out as a common code-base application supporting all BUs diverges into multiple code branches, sometimes so different, that they essentially become different applications. In this case, while infrastructure costs are contained, operational and maintenance complexities and costs grow.
There is a better approach. If applications are designed based on multi-tenancy, the level of “sharedness“ moves higher in the stack. The higher it moves, the better efficiency and asset utilization is gained.
It should be noted that this is appropriate for those organizations that operate at a higher level of IT maturity, as change and release management, and availability and scalability, get more complex.
What is a multi-tenant application?
A multi-tenant application is a shared solution (i.e. CRM) used by different
tenants (organizations, BUs). It is a
single application with
scalable resources to meet the performance demands of tenants.
As each tenant has its own specific functional requirements, the single multi-tenant application can support
tenant specific customization at different layers of the architecture (persistence, workflow, component integration, security, UI).
Since multi-tenant applications run on shared infrastructure, it is important to
isolate tenants from each other to protect information security, and prevent rogue actions or failure in one tenant’s execution environment does not impact other tenants’ availability.
Finally, since we’re talking about a single code-base running in shared environment,
maintenance and updates must be continuously performed without requiring any downtime.
[Note: These are the key concepts behind multi-tenant applications. I am not going to include things like subscription-based licensing or utilization-based billing. Those are in the realm of Software-as-a-Service offering and operation.]
So, the main idea behind multi-tenancy is to provide a single code-base, polymorphic application that is customizable and scalable to meet the demands of different tenants:
In the diagram above, on the left (A) we have a single code-base, single instance, and single DB application supporting different tenants. On the right (B), we have a single code-base and single DB, but multiple instances supporting different tenants. This is not the same as an enterprise deploying multiple instances in their shared solution implementation.
In this case, the reason for “multiple instances” is related to the underlying infrastructure hosting the multi-tenant application. It is related to how its request handling, provisioning, and scalability strategies have been implemented.
In A, there is probably a cluster or grid of compute nodes powering the application. In B, as new application requests arrive, the underlying infrastructure provisions an execution environment (i.e. servlet container) and dispatches the request to the container to run the requests.
Here are some references which you might find useful:
·
http://www.computer.org/portal/web/csdl/doi/10.1109/CEC-EEE.2007.4
·
https://www6.software.ibm.com/developerworks/offers/techbriefings/cc4d-replays/session2_dcarew.pdf
·
http://www.ibm.com/developerworks/webservices/library/ws-multitenantpart2/index.html
Multi-Tenancy Design Patterns & Realization
In this section, I am going to describe some of the key multi-tenancy design patterns and organize them into logical order:
| Requirement | Description | Patterns, Approach, and Techniques |
Tenant Isolation
(Infrastructure) | Tenant isolation is quite broad and multi-dimensional. It is primarily motivated by security and tenant availability and performance. | At the infrastructure layer, tenant execution environment may be separated by virtual machines
Higher up, in the application server layer, each tenants may get their own server (Take a look at this WSO2 paper)
In the future, OSGi bundles? (See OSGi4C – RFP 133)
SOA provides a natural choice for multi-tenant and cloud applications (i.e. reusable components, composite apps). Take a look at this paper by Frank Leymann, et al on combining different multi-tenancy patterns in Service-Oriented applications. |
Tenant Isolation
(Data) | In a multi-tenant environment, a single database contains data from multiple customers. Tenants should only be able to see their own data. | SQL operations are qualified using tenant_id to return only tenant-specific data.
For added security & audit, another field such as user may be required to for authorization and logging.
References:
http://msdn.microsoft.com/en-us/library/aa479086.aspx |
| Customization | As previously discussed, the single code-base multi-tenant application must provide some degree of customization and use extension to facilitate adoption. The customizable configuration items range from UI to workflow to database schema. For different layers, different techniques are applied to make the changes.
Here is a good reference on approach / methodology including assessing customization needs for a multi-tenant application. | Most SaaS solutions offer a metadata repository and a configuration service. A self-service UI panel is provided to the administrator on the tenant side to make the configuration changes.
Wizards are also provided to constrain / guide configuration changes. For most configuration items, change is automatic.
On the fly code generation techniques (i.e. templates), and dependency injection are also used to create tenant-specific code at runtime. |
| Maintenance & Upgrade | Applying patches or system upgrades for a single instance multi-tenant solution running on a shared platform gets quite complex.
In the enterprise, change management and release strategies must factor in availability SLAs. | The same principles and best practices as continuous integration and delivery apply here
Force.com development lifecycle offers good best practices for release testing and promotion which can also be applied to a multi-tenant solution in the enterprise.
Obviously, it is important to be able to roll back to a previous stable point if things go wrong, so here are some general tips:
· An on-demand provisioning infrastructure provides an important capability for multi-tenant operation and management. Now, for an enterprise it doesn’t have to get as sophisticated as Amazon or Google, but try to understand the gaps, build a business case, and take appropriate steps.
· Similarly, investment in a CMDB solution also plays an important role in developing capabilities to manage change requests effectively and reduce deployment errors and others…
· Template-based configuration and deployment…This is an important configuration and change management best practice.
· Regular incremental backups (i.e. system snapshots) are also important to enable recovery in the event of rollbacks…. |
The above have direct linkage to the solutions that are built in enterprise shared services. BUs must be isolated for both technical operational and regulatory reasons. Enterprise architects must find ways to design solutions that share more and cost less in ongoing operation and maintenance. And, the systems typically have high availability requirements.
What’s also important to note is that the there is often no reference model for building shared solutions. This is a big gap. Multi-tenancy patterns and principles can be a big help.
Final thoughts
This is quite a fluid area. Multi-tenancy is still relatively a new concept. The ideas There are a lot of open questions from design -> operation. Enterprise Architects should have this on their radar, as they engage with new projects – or – refactor old implementations.
What do you think?
