What’s often missing from discussions about cloud in the arts is whether the underlying architecture is multi- or single-tenant. When you’re comparing cloud-based applications, you really need to understand the difference.
[easy-tweet tweet=”Differences between single and multi-tenant architecture have a huge impact on arts and entertainment companies”]
Multi-tenant basically refers to a single instance of software used by multiple clients or ‘tenants’. In a single-tenant architecture, each tenant accesses a separate instance of the software. When a new tenant comes along, the supplier has to add a new, separate instance.
Those distinctions have a huge impact on arts and entertainment companies when it comes to data, security and customer service.
Data and analytics
There is a perception that single-tenant is superior because it provides data isolation. The multiple customers (or tenants) on multi-tenant software are sharing a single instance of the application, and this increases the risk of data being shared with other tenants – or so the thinking goes.
It isn’t true. There are many options for managing data in a multi-tenant environment which sit on a continuum between isolated databases and shared databases. Whether the data is secure in both single and multi-tenant environments comes down entirely to the quality of the software engineering.
For arts organisations, the isolated database end of the continuum makes most sense, as the tenant databases are usually quite large and because the ability to move databases around between servers makes it easier to handle the peak demands experienced in our industry.
Multi-tenancy and security
So how can a cloud provider guarantee that its multi-tenant architecture handles data securely for different clients? The key is the maturity level of the SaaS architecture.
At level 1, every time there’s a new client, the supplier adds a new instance of the software application which is only accessible by that client. That instance runs independently of other instances and all instances might be running a different version of the software. At level 2, the supplier still runs separate instances but aims to keep them all on the same version. The key word here is “aim”. Keeping all instances of the software on the same version might sound easy in theory, but imagine you have, say, 200 of them, and then consider the time and effort needed to make this happen.
On the other hand, at levels 3 and 4, the supplier can run a small number of instances serving a potentially large number of clients, and changes or fixes can be rolled out far more quickly and efficiently as only a small number of instances of the software need to be maintained.
The difference between levels 3 and 4 SaaS maturity is an important one. Without it, every customer client would always have to be on exactly the same version. This makes it nearly impossible to run a beta program, or hold certain customers back from a new release if they aren’t ready for it.
In a single-tenant architecture, each tenant accesses a separate instance of the software. When a new tenant comes along, the supplier has to add a new, separate instance.
Imagine a multi-tenant vendor with 200 customers but only a small number of instances of the software. Then imagine a single-tenant software provider who also has 200 customers. The single-tenant provider has to create 200 separate instances of its software. Imagine how that impacts areas like:
Security – A multi-tenant SaaS provider can secure its shared instances and spread this cost across all of our clients. This works much better than having to secure each one of 200 instances and keeps costs down.
System resources – Running 200 instances means 200 copies of the application which all have to live in memory on the web servers. Rather than having to buy masses of hardware for 200 instances, multi-tenant software can focus on quality hardware for the small number of shared instances it’s running.
Upgrades – If there’s a hotfix that needs to go out quickly, applying it to each of the shared instances of the software is much more straightforward if the architecture is multi-tenant. A supplier working with single-tenant architecture would need to apply it to each of their 200 instances.
Scalability – Multi-tenant can far more easily handle peaks in demand across the client base. That’s because the instances are not single computers but clusters of servers behaving as one.
Maintenance – Maintaining 200 instances properly costs a lot of money, which is either passed on to the customer or addressed by quietly under-resourcing the maintenance and upgrade frequency.
Why isn’t everyone in the arts embracing multi-tenancy?
Multi-tenant software doesn’t come out-of-the-box like single-tenant, so the jump from level 2 to levels 3 and 4 of SaaS maturity will generally require an entire rebuild from the ground up. I also suspect that there’s a lack of will and/or skill in many of the vendor engineering teams serving the arts industry.
Think about all the successful SaaS businesses out there – Salesforce, Xero, Google Apps, Zendesk – they’re all built on multi-tenant architecture. That’s not a coincidence.
[easy-tweet tweet=”Multi-tenant architecture can far more easily handle peaks in demand across the client base” hashtags=”Cloud, Scalability”]
The downside of multi-tenant is that it requires significant R&D to create and sustain. However in the long term, single-tenant software services for the arts simply won’t be viable if they don’t take the plunge.
Michael Nabarro, Co-founder and CEO of Spektrix
Michael founded Spektrix in 2007 after experiencing the hassle of installing a ticketing system at the ADC Theatre.
As CEO, Michael works with CTO and co-founder Matt Scarisbrick to establish the vision for the entire company, developing a global business plan for Spektrix. Michael is focused on understanding the needs of the arts and entertainment sector, building a long-term product plan to meet these needs as they change.
He has a degree in Computer Science from Cambridge University and previously trained at RADA as a lighting designer. He has lit shows at the National Theatre and Soho Theatre and still does lighting design outside of Spektrix. He also sits on the Council of Management of the Royal Theatrical Support Trust.