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)
I work as CPO for a Swiss Telco/Messaging Platform Company.
My real passion is developing in Golang, Vue-Nuxt/ReactJs/Angular with Redis, Nsq/RabbitMQ, ArangoDB, MongoDB and Sql
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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