Handling multiple clients using single application

Question

We are developing an ERP web application using Vaadin framework where each of the potential client companies will have their own data and file storage. Current implementation only allows having one client company per application instance, what consequently requires separate database schema and file storage. Some of the clients may want specific customizations based on their needs.

Having few clients doesn't cause much trouble, but if number of clients would grow, then maintaining dozens of application instances will be a real challenge.

We are reaching that point where we have to choose one these options:

1. Improve our architecture to allow all client companies manage their data on a single application instance and restrict personal customizations to the application;

2. Stick with the current implementation and just keep increasing number of running application instances on the server.

Which of these options is considered better practice and would make the system easier to maintain? Is there a different solution for this kind of situation?

Edit: Application is currently in development stage. The server with all the potential application instances will be run by ourselves. Each instance will be deployed in a WAR package via Apache Tomcat server.

Answer 1

Multitenancy is a hard problem. Very hard. I've seen a lot of companies do it, very few of them having done it well.

To cite just one of the many examples of where multi-tenant systems can fall apart, consider what will happen when one customers wants a data warehouse or ad-hoc reporting database. Can you spin one off relatively easily, or do you have to go through an immensely painful data scrubbing process that takes forever to run, has to drop a bunch of keys and constraints, and often loses data that is technically supposed to be shared?

I've seen the latter scenario happen at least twice. It's not uncommon.

Multi-tenant systems really have to be written as multi-tenant systems from the ground up. If you try to convert a traditional multi-instance farm to a multi-tenant system, you will screw it up for several iterations. And if you choose to rewrite... well, best of luck.

There are a lot of advantages to multi-tenant systems, but contrary to (apparently) popular belief and/or intuition, productivity is not one of them, at least not until such time as you are maintaining dozens or even hundreds of separate instances. It adds a huge amount of complexity, related both to look and feel and to the business logic itself. You'll probably need some kind of rules or workflow engine. And your uptime and support/call-centre performance will suddenly become a lot more sensitive, because any failure you experience will affect all your clients, not just one.

You will also definitely have to reign in the customizations if every customer is on a shared system. You will eventually run into a situation where two different customers have mutually exclusive requirements and will have to choose a victim. If your organization, like so many organizations, has trouble saying "no" to paying customers, this will bite you, hard.

Most of the cost savings that multi-tenancy has historically provided on hardware can also be obtained today with virtualization. With vSphere or similar products it's almost trivially easy and quick to spin up new instances, even if installation is normally very complicated.

What you don't get with virtualization is the simplified deployment (new releases) and the ability to do data mining. Question is, would either of these benefit you right now?

Rolling out 1 update instead of 10 updates might be easier... if you've got really tight QA and are extremely confident in the stability of the product. If not, then that 1 huge update is far riskier than the 10 small updates. Only you (and your company) can decide which applies to you. And as for analytics - if you're not big on analytics now, or privacy laws/regulations prevent you from doing that kind of data mining, then don't assume that a shared database is suddenly going to start benefiting you in the distant future.

Just to be clear, I'm not against multi-tenancy, but you're hardly the first person to ask the question or the first company to go down that path. Don't assume that it's going to be easy to consolidate, and definitely don't assume that it's going to be easier to maintain afterward. It's generally a lot harder; you should only go with that solution if its specific benefits are particularly important to you.

For vendors without a huge number of clients, it's probably better to invest your time in test and release automation. If you've got a full suite of regression tests running every night and can do a promotion in 10-15 minutes (generally parallelizable), the number of instances tends not to matter that much. There's a limit, yes, but... you'll know when you're getting near it.

Answer 2

Maybe you should think about deploying one VM per customer.

Have a few "standard" VMs set up for the most common customer profiles so you can quickly deploy new customers -- deply the VM, configure the IP address and user passwords and its ready for use.

Once deployed the VM instance can be customized to you hearts content.

Cisco, VMWARE et. al. have sophisticated tool sets for handling multiple VMs.

The only gotcha is you need to be very structured in how you handle customization, you need to ensure that can save and re-apply any custom code whenever a VM is configured or upgraded.