Deploy Sass customers independently each within their own version of the application or as one, application containing all tenants?

The trade-offs when building software as a service (saas) based architectures, especially within the context of open source software.

There's a lot of resources out there about building scalable architectures. Horizontal scalability and independent deployability are key proponents of such systems. But most of these resources focus on single applications or websites. What is missing is a general overview or common understanding of how saas based products might apply these principles.

If there's a desire to independently deploy the software (e.g. on-premise for a customer), how easy is it to take only the application and deploy that without the need for sass-relating bindings (given there are no other tenants).

What's different about SaaS based architectures?

The key difference is multitenancy. With SaaS architectures you have multiple groups of users (customers) who must be kept completely separate (if you care about security), whilst having the same experience of using the software.

Some SaaS architectures don't completely separate customer data and prefer to have one data set without complete separation. This approach has advantages (mostly simplicity & ease of reporting because everything is in one place) but sacrifices things like independent deployability for each customer, and one outage affecting or customers.

Depending on how the architect your SaaS:

• User data may or may not be independently separated

Do you have one big monolithic datastore for all your user data, or is the data for each tenant completely separated?

There are trade-offs in every direction.

Each tenant deployed independently

• Independently upgrade each tenant
• Customer data is kept separate

Independently upgrade each tenant

With independent deploys for each tenant you achieve a clear separation of customer data, which may make it easier to control, and protect privacy and security of the data.

The cost is that you now need a way to upgrade every instance of your independent applications. Reporting and aggregation of data for each of your tenants is more complex as its on each of the tenants, as you're potentially running different versions of the application.

The great thing about having complete separation between your tenants is that you can independently deploy each tenant. However, one of the worst things, is now you have potentially multiple different versions of the application running and you have to develop a strategy to keep them updated.

Completely independent tenants are also a blessing however, because one failed update on one tenant does not cascade to every single tenant. If you take the multitalent approach where all tenants operate within the same application (I would call this monolithic saas), one outage can result in downtime for all of your customers.

Customer data is kept separate

This might give you better security and privacy between each users' data. However, it's harder to aggregate and report on each customer because they're each in a separate deployment. Not impossible though, for example have each deployment send its logs separately, or expose endpoints to (another) system which does the aggregation.

All tenants one deployment (multi-tenant)

• All tenants are updated at the same time
• Customer data is in one place
• An outage of this system affects all customers

Easier to aggregate and report of customers, but as the cost of less separation between customer data.

If data separation isn't important to you, this might simplify your deployment process at least initially. However, if there is just one datastore for all your customers- can it easily scale? Will one customers load impact another customers?

The middle way.

Another approach (which we've found to be useful) is to have a central load balancer which directs traffic to the correct customer, based on hostname. Each customer deployment (data primarily) can be completely seperate, and yet use the same sourcecode.