We've been discussing how to implement Multitenancy in the Authoring Tool. We've got a couple of technical solutions but we need a bit more clarity on what we actually mean by Multitenancy.
I have the following definition in mind.
A multitenanted install is a single deployed codebase available to all users at a single URL. Users do not need to select their tenant from a list. When they log in, they are presented with a system that implies they are the only group using the system.
I've tried to remove as much technical detail as possible from that definition. Our implementation approach is flexible depending on the definition...
I have also defined the following requirements for the initial release of the Authoring Tool. My desire would be to reduce the size of this list rather than to add to it (my intention would be to remove the tenant-level admin privilege for the initial software release)
1. users can be assigned to groups
2. there exists a group type called a tenancy
3. a user is a member of only one tenancy
4. a set of projects can be edited by a group of people
5. a set of (binary) assets are shared by a group of people
6. a member of the group has admin privileges
7. an admin of the group can add people to the group
8. an admin of the group can remove people from the group
9. a user can create a project and it is available to the whole group by default
10. an admin for the group can "delete" a project
11. any member of the group can "publish" a project
So the question. Does the definition above match your expectations? Particularly the single URL approach. Are there any initial requirements that are MUST HAVE for release 1 in early 2014?
Note that the definition above means having a separate URL per tenant isn't multitenanting, nor does providing a tenant select option on the login screen.
Hi Ryan,
thanks for putting up a definition. I wanted to get back quickly for now but will also attempt a more detailed answer later on.
In summary, I think that if we removed the tenant-level admin privilege, we won't have a multi tenanted system and would run the risk of implementing half a solution with the difficult bits to add later on (which will cause major issues in my experience).
It probably needs further analysis and explanation but as it stands, I would advise against removing this from the scope of the MVP (if we really want to achieve it).
Definition:
The key defining factors for MT for me are:
- single codebase
- tenant level admin functionality
- full data separation between tenants
- super admin privileges
Conversely, I don't think that the URL comes into play. I have seen (and designed in part) MT system implementations, which feature multiple URLs, e.g. to achieve the feeling of a separate system and bring in tenant-specific branding.
Explanation:
Single codebase is self explanatory but it's worth highlighting that the database infrastructure may not be a single one. I.e. I think having multiple databases used by the same codebase is valid and permissible (although it's often a workaround for a less well designed system or retrofitted MT).
Tenant-level admin. The crux (hardest part) of multi tenancy is achieving the data separation for admin level access. This is where non-true MT systems will fall down. If we store this up for later, we run the risk of getting it wrong now. My sense was also that by going with a node.js and from scratch approach we would stand the best chance of solving this issue and build solid foundations. Should scope & timelines be the underlying issue, I therefore recommend taking the approach of developing less admin functionality but making all of it 'true MT' (= solid foundations).
Achieving full data separation between tenants is at the heart of achieving true MT, i.e it's the reason for going with MT in the first place. So rather than dividing up system functionality into the examples given above (users, projects/courses etc), the aim should be 'the whole system'. We have learnt this on fitting MT into Moodle / Totara and I'd be keen to share examples of the issues we have seen with this if that would help. One of these examples is that unless you have full-system MT out of the box, you will have to base additional functionality on items like groups, which means interweaving functionality which will make writing code much more complex and prone to error / performance issues. I also think that users could (not should) in time have access to multiple tenants - the example here is basecamp and a real life thought might be that a content producing services company (like Kineo or Learning Pool) could run/host a tool for our clients and our internal staff may need access to multiple tenants to work across projects for different clients.
The presence of a super admin or tenant admin account is a further sign of a true MT system. This would be to manage global system config (e.g. to do with the underlying infrastructure config) and to administer tenants, quotas and the like. This account would be disconnected from any regular use of the tool.
I hope this makes sense. As I say, thanks for posting this and it's a very important debate to have at this stage.
Thanks, Sven
PS: I'll try to engage with the other items and questions raised in a further post.
Thanks Sven, a great response.
Taking your points in turn.
I agree that the tenant-level admin role is important. In fact, the approach that we have in mind will make it straightforward to deliver that role. I wanted to set it aside initially as it's not (in my view) on the critical path for getting a useful product. If a super-admin role has to manage tenants in the early stages then I'm ok with that (we'll just need to make sure that it is only for a short while).
This has highlighted the need for a product roadmap beyond an initial release (I'm deliberately avoiding using MVP). I think Dennis and I are working on a draft of that this week.
Your definition is interesting. I don't think it's very far from my thinking (phew!)
A single codebase could be multiple installations of the same code, I guess you don't mean that? Any reason why having one installed application is significant? There are strong arguments on both sides for a single shared application vs. tenant-specific applications (and significant technical implications!)
When you talk about full data separation are you referring to the system level or the application level? And what do you mean by full? Systems level would require a separate database for each tenant, and no shared user database. Application Level wouldn't make that technical requirement but would require that when a user is logged in they aren't aware that they're on a shared system. For me, Application Level is a given, whereas system level isn't a definite requirement (yet). Perhaps you are referring to "full data" (i.e. content, users and config) rather than "full separation" (trivial separate backup and restore)
I'm afraid I'm not sure what you mean when you compare the initial requirements with "the whole system" - perhaps I've missed something significant from my list? My assumption is that release 1 will have very little config in it. I've just noticed on re-reading my post that I didn't say that the requirements were solely related to the MT behaviour. There will be other requirements!
Could you share some of the examples you mention? It would certainly be worthwhile to learn from past experiences.
We are very keen to ensure we build the simplest system possible - to quote Kevlin Henney "favor something that is simple and correct over something that is complicated and correct, because, whatever our aspirations, the latter is less likely to be or to remain correct"
Looking forward to your more detailed post!
Ryan
I have posted a document outlining the approach we intend to take for Multitenanting. You can see it on github (https://github.com/adaptlearning/documentation/pull/1)
I don't believe it is entirely correct yet, but is a stake in the ground for us to work towards the right solution.
I'd appreciate your comments on the pull request, and I'll incorporate any feedback made there before merging into the main repository.