As some of my followers may know, I am writing and providing a Job Board Software, on which I run since last weekend, 4 different Job Boards.
One of these boards, the Full Stack Developer Job Board I run since the end of February of this year, with the same piece of software. However, back then, the software was not multi-tenant at all. However, the plan that the underlying software has to be Multi-Tenant was always there.
Don't know, what Multi-Tenant means and why it can be good? Good article
Now... Why I did not do it multi-tenant from the beginning....
Good question. The last decades I would do precisely that, and remembering some ex-projects, yeah, they started right there... and yeah... mostly then stuck right there...
No, not because it's impossible and I could not manage it... However, because doing a multi-tenant software add's some levels of complexity to software, which should not be underestimated. Moreover, when you do a new Project as a Maker, you should not loos time to first do something multi-tenant, before you are sure that your product will find customers.
So that's the reason why I started with adding multi-tenancy only the last 3 weeks.
Ok.. 3 week's, working on it only in some very early morning hours and on weekends is not that much for this, but I must confess, that I was always thinking in it when I structured my models, objects, endpoints and even frontend services. Not precisely, how at the end I will implement it, but thinking about where it will be "plugged" later.
So I could implement it +/- fast and today the boardengine.io Software is a SaaS, which can run on the same instance (simplified: 1 DB, 1 backend, 1 frontend piece of code) different job boards, where styling differs, content part differs, data is isolated but can also be shared between tenants and some logic, like filtering, skill-sets etc are configurable per tenant on instance level. I don't have an SSO, but a user can have roles on 1-n tenants etc. The full instance with backend service, 2 http daemons, redis, nsq, arangodb and frontend run in a Rancher 1.6 docker environment. I have the plan (also since the beginning) to move to Kubernetes based environment, but the same way... stay prepared for the move, but do it only, when there is a real need for it.
- Identify the minimal architecture needed for the first iterations
- Have the "plug-in" points in mind, to reach the big goal in the future, but
- Don't do over-engineering from the first moment.
The big picture may change during the time, so even defining a detailed scope makes not much sense IMHO, as this can change. A good point to act small and start early to get feedback from real customers on your first shipped versions of your product is, that you can adjust the big picture and the related scope, before you implement a complex layer. But, as listed above. Having the big picture in mind from the beginning is important, to not close doors in architecture and to avoid "mission nearly impossible" kind of data migrations.
At the end the list of boards, which runs on boardengine.io Job Board Software :
- Full-Stack Developer Jobs: https://fullstackjob.com
- Python Developer Jobs: https://pythonjob.xyz
- Go Developer Jobs: https://golangjob.xyz
If you are interested in a more technical post, how I implemented it, please comment, as if you have any other feedback :-)
( interested in your own multi-tenant software - contact me through my Full-Stack Developer company)