Multitenant app or separate instance for every customer

Question

Suppose you are selling a web app. There is no data or operation that involves more than 1 customer. Each customer is totally separate.

How would you prefer to make the deployments?

1) Deploy one instance for each customer, meaning you are running and managing many small apps on different servers/virtual machines/on the cloud etc.

2) Build a multitenant app that manages different customers itself, manage 1 big app, scale it on the cloud. You are basically selling a username/pass pair.

OR a 3rd approach I am not aware of.

Is the choice clear (like everyone is doing this second way), or are there many considerations, pro-cons between those models?

Answer 1

There are some trade-offs that you'll have to do:

1.Dedicated instances

Advantages:

• No additional development needed nor conceptual work (less time and cost to market the product)
• Every customer is fully independent, which means technical flexibility (you could choose hosting facility depending on location, volume pricing, etc...), customizability (a customer could request a special tailor made version), and increased security (no risk that one customer could access data of other customer, or that damages on one customer, like SQL injection attack, could impact the others.
• You could offer the same product for the customer to install in his own premisses if he wants to

Inconvence:

• No economies of scale: you have to manage all these servers, which means a technical overhead for every new customer (not only install, but also monitoring, security patching, forecasting additional disk space needed, etc.) .
• Expensive maintenance: upgrade procedeure in case of a new release of your product would have to be repeated for each customer.

2. Multitenant architecture

Advantages:

• single software to mainain
• economies of scale for the operations
• so in the end cost effectiveness and cheaper prices for the customer (or higher margins for you).

Inconvenience:

• you are constraint in the customizability for customers.
• a higher initial investment in the development : the multitenancy must be designed (not so easy as it appears), an feature designed must take into consideration portential variants for different customers
• higher operational risks (e.g. scalability and performance management to be ensured considering the bigger volumes + possible hidden bottlenecks + cross-customer security risk + problems might affect all customers in the same time)

3. Other alternative: microservices ?

A third scenario could be to cut your application into smaller microservices. The scalability would be maximized. It would still be up to you to decide whether you split services by customer or if you'd choose multi tenancy, but the whole architecture is designed to make these choices relatively easy. The application would need a complete reengineering .

Recommendation

I think that option 1 is the way to choose if you have a few big customers, or, as a temporary solution in case you have to go to market very quickly.

Option 2 seems to me the more rational choice if you have many clients, and if you want to achieve economies of scale.

Option 3 would be the way to go if you would choose option 2 but if you'd anticipate scalability issues. Go directly to this approach if you expect a huge number of clients

Answer 2

If you build the app to support multiple tenancy, then your future tech reps will have a choice about how to deploy it. If you find a customer who insists on a single-tenant instance, you will be able to support them. Some customers prefer that approach for infosec reasons.

At the same time, you'll be able to run multitenant operations. That will help you scale the application by gathering customers. There are several parts to that.

1. technological scaling. More customers on a single instance will keep you honest about bottlenecks and race conditions, where you might not confront those issues on lots of small instances. You'll also have an easier time with sysadmin and backup work.
2. Business scaling. A multitenant system can handle trials and small customers economically.
3. Scaling upon customer success. What if a customer likes your product so much they want to require all their suppliers to use it? With multitenant, that's a customer-list upload. With single-tenant, that's lots of instance rigging.

Multitenant is the way to go for app design. It keeps choices open.

Answer 3

The choice is not clear at all, and you could easily do a hybrid approach. For example, Atlassian allows to use their tools (Jira, Bitbucket etc) on their server, but also let you install on your own server.

The downside of one instance per customer is that every update needs to be pushed to every customer - but they might have the choice to do it or not. Note that not every customer is happy to have ever-changing applications! You might not have everything under control, though. Think about backups, server operating systems, etc. Dozens of possible conflict points.

For fast-evolving applications, I think a central app makes sense. It will give you just another type of headaches. And if you mess up with something, all your customers are affected at the same time.

Side notes: It might make sense in the central-app-approach to keep your users' data in separate databases. Also, you could go with separate installs for each customer, but in a controlled environment at your data center, so that you still have the full control. Always keep in mind that complexity grows exponentially with the number of options.

Answer 4

I've seen 2 developments happen in every application that I've worked on that was multi-customer but single tenant:

• A feature is only required for one specific customer who wants to pay for it. Even for the most successful startup this feature is hard to resists, so the code bases for the apps do diverge due to time pressures. At some point, they either become unmergeable, which if the multi-tenanted software is successful leaves the single tenancy in the dust. Worse case is that lots of maintenance work is now required to manage multiple pieces of software.
• Even in the smallest economies (mine is New Zealand), you'll quickly come across customers that need some sort of corporate super user that can access all departments records, while multiple tenancies of their subordinates need to be kept separate. This is exactly the same as multi-tenancy application wide, so you end up having to built it in any case.