软件即服务 (SaaS) 的应用程序设计

Question

So I'm currently designing SaaS application. I'm having small problem with the design. Let's say I deploy an application under www.mycompany.com. User buys a subscription and therefore gets an access to the application. Now what I'd like to have is a 'way' to create a new instance of this application whenever a user buys subscription eg:

John owns company Vega. When he buys a license for accessing/using my application a new instance is created that would be accessible through www.vega.mycompany.com. Once his account is created a new instance of the application is being deployed, new DB created and linked with the newly created instance of my application.

The reasons behind that are:

1. John might generate big amount of data, hence having multiple smaller DBs is better than having one for serving each customer.
2. John might store sensitive data which he wouldn't like to store in the same DB as other users.

I want to develop the application in Java. The admin application through which I would create new instances of the SaaS application will be also developed in Java. Now my questions:

1. How do I actually achieve that? Do I simply deploy the same WAR file in application container (say Tomcat) whenever new account is created?
2. How do I create the 'vega' subdomain from the administrators application - is that even possible?
3. If there's a bug or I want to simply update something and I have 1000 instances of this application how do I do it smoothly?

Answer 1

I'm working on a similar problem/solution right now, although it's written in C#, it will be running in linux with mono and I believe my solution is language agnostic.

First of all - to develop a SaaS application like you and me have it - which needs a new instance for every new customer is not really best practice (to the best of my knowledge). Due to the problems you mentioned - setting up a new environment and also handling many concurrent instances, which would include updates or possibly moving them to a different server/infrastructure.

For me the decision was due to a bad initial design of the application, simpler data design and in the end better security, as now it's possible to give every customer only permissions to his small subset of the database, and no SQL Injection or other bug on my side can change this - as the permissions are enforced on database level. (you still could have bugs there, I'm fully aware of that)

My Solution:

Use docker containers . It is much more lightweight than a traditional VM, gives you additional abstraction and security in case, for instance, the users are allowed to upload files, … Also deploying a new container is fairly trivial and quick so you can do it within seconds after the user signed up.

I'm using an Nginx server on the host, as a reverse proxy, which forwards the requests to the corresponding container for each customer. The problem here is to restart Nginx after you updated the configuration file, without loosing any traffic, that's a bit tricky.

Updating the application is also easy, as you only need to publish a new version of the image, stop all running containers and restart them with the new image. However to be able to do this, the containers can't be holding any data, keep that in mind. - Here the problem is again to update it in a way, the user wouldn't notice, for me - as I've customers only in one timezone it's easy - just schedule it for 4am and fingers crossed nobody is crazy enough to be awake and working at that time :)

This doesn't give you probably 99,999% availability but this isn't something I'm aiming for and it's a great tradeoff for the ease of managing those containers. Additional advantages are - you can test the production environment on any linux machine, and you can move the code anywhere you want, just change the Nginx reverse proxy-configuration.