Cross Posted: How I got Multi-Tenant
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.
and...
Today, I confess that I did not implement all details from the beginning
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...
Why I got 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.
What I take from my own confession as learning:
When you start a new software project, think big, but act doing small steps
- 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
- React & ReactJS Jobs: https://reactjsjob.com
- JavaScript Jobs: https://javascriptjob.xyz
- Python Jobs: https://pythonjob.xyz
- Rust Developer Jobs: https://rustjob.xyz
- Golang 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 :-)
Cheers
Stefan
( interested in your own multi-tenant software - contact me through my Full-Stack Developer company)
Top comments (3)
Um... to me multi-tenant suggests tenants are isolated so that you can stamp out new tenants but share the same resources. If you recode your app to add multi-tenancy then you have a single instance and you wont have good resource isolation. If you switch to running containers you can isolate all the tenants in their own containers and share hosting costs and a database server using different schemas. You can them scale then independently.
You then have many copies if the app but that then lets you incrementally roll out upgrades across tenant rather than do big bang. One busy tenant can be moved to dedicated VMs as it grows. Yes you need SSO to allow customers across tenants (boards) yet you may benefit from for breaking up services (when you need it later). There are a lot of good libraries and services to run an open id connect provider that can be a first shared service. Running that in containers will help you move it to its own vm when your load grows.
Apologies for the tangential suggestion if its not appropriate for your project! (We run on kubernetes, I open sourced the automaton scripts that are chatbot driven by slack at github.com/ocd-scm)
Sorry for my late answer. Thank you for your thoughts and suggestions.
Regarding your first comment, I probably could not explain it well enough, but if I got your point correctly, my actual iplementation can handle what you describe.
Regarding SSO OpenId is for sure a good idea, just not yet burning to have it. Main cent of my post should be, to be open for "such topics" with first implementations, but only implement them in detail when there is really a need for. And... From starting time to when it's getting to a point to be implemented, details probably changed anyway. .
Will check your ocd-scm , looks interesting
Hey stefan, checkout our low code platform for building software bitpod.io. I recently completed completing tenantization module in which now every app can be multi tenanted! Let's share notes sometimes. Thanks for twitter rt :)