Imagine you’ve got a business that relies on multiple websites all of which are similar in terms of their basic functionality but have some general differences too – perhaps in their layout, for example. You could, of course, copy and paste lots of code, assign it with different name spaces and set it for each different website. Or, you could do something much less time consuming and turn to an architectural concept known as multi-tenant architecture.

What is multi-tenant architecture?

A tenant refers to a group of users who share common access with specific privileges. So, when there is multi-tenant architecture, a software application is specifically designed to bring each tenant a share of the instance. This could include configuration, individual functionality, user management, data and non-functional properties.

So, multi-tenant architecture is different from multi-instance architecture because the latter relies on separate examples of software instances, whereas multi-tenant architecture will give each tenant its own share of the instance.

Where did the idea of multi-tenant architecture come from?

Multi-tenant architecture certainly sounds like a brand new concept. However, in reality it has been around in different forms for decades. Effectively these applications combine features from several different types of services.

• Back in the 1960s it was not uncommon for companies to process power and rent space within mainframe computers in an effort to cut their expenses. This process was known as time-sharing and often saw them reuse applications just by using a different log-in screen specific to their identification. This would then mean they could be charged based on their disk usage.
• In the 1990s, the concept expanded further with application service providers emerging that hosted applications for customers. Based on the application’s limitations, ASPs would host applications across different machines or even as different processes. Effectively, multi-tenant applications are a more mature version of this service allowing for lower operational costs.
• A number of web applications designed for customers – including email interfaces like Hotmail – were built as single applications that could serve multiple people. In effect, multi-tenant architecture develops this concept while also offering additional customisation into a group of users that fit within a client organisation.

So what are the advantages of multi-tenant architectures?

So why would you consider multi-tenant architectures? Here are some of the potential advantages:

• Cost savings | Perhaps the most obvious reason to consider multi-tenancy is the potential cost saving it can help you enjoy. If you simply consolidate your IT into one operation then chances are that this will produce a processing and memory overhead which could prove highly expensive when multiplied across a wide customer base. However, with multi-tenant architecture this overhead is cut because you are amortizing over such a wide array of customers. In addition, there can be further cost savings from licensing – because if you are able to run everything on a single application then you may only need one, single software licence.
• Data aggregation | With multi-tenant architecture you no longer need to collect data from multiple sources. Instead, the data is stored in a single database for all customers, potentially making it much easier to spot any trends.
• Release management | In theory, release management should be more straightforward with multi-tenant applications because whereas a traditional release would mean distributing changes to each service machine, with multi-tenancy installations only need to be carried out to one single server, simplifying the process and ensuring that the scale is not dependent on the number of customers anymore.

So what are the disadvantages of multi-tenant architectures?

For all of the advantages listed above, it could also be suggested that there are potential stumbling blocks with multi-tenancy too.

• Cost savings | All of the potential cost savings could be lost as demand grows because enhancing performance can be more complex on a single a server as opposed to if the cost was spread across multiple servers with reduced capacity. In addition, the development associated with multi-tenant architectures is typically more complex meaning more expense associated with security testing. The complexity of the systems can also make them more expensive to maintain with a more significant development effort required.
• Data aggregation | The potential benefits of data aggregation are weakened as it is common to split the mining database and the operational database due to their differing workload characteristics. There is also a need to prevent any potential service provider from accessing customer information.
• Release management | While release management should become much smoother in theory, there are also risks that multitenancy will create problems for newly released versions. As there is just one, single software in place there is the potential for significant downtime for multiple customers even when an update is only requested by one customer. In addition, there is the risk that bugs from applying a new release could creep into another tenant’s application.

So is multi-tenant architecture right for you?

There is no denying the potential of multi-tenant architecture. Successful implementation can be very powerful for business solutions with similar core functionality – indeed it has become a highly effective way to create platform web solutions that share the same functionality across multiple applications. However, there are also several risks involved so it’s important to ensure that the multi-tenant application can be customised to meet your individual organisation’s needs. The costs of redesigning applications for multi-tenant architectures can also be significant and alternatives have emerged too – particularly in the form of virtualisation, which can host multiple instances across one or more servers. So think carefully about whether this is an appropriate step for your business or not.