|Cloud-Style Alfresco Multi Tenancy
||[Sep. 16th, 2013|01:21 am]
In the first part of this Alfresco Multi-Tenancy series, I tried to cover what MT is, and how Alfresco implements it, concentrating on the On-Premise / One / Community / Enterprise versions of Alfresco. In this part, I'll try to explain a little of what changed with the Cloud version of Alfresco.
Let us consider again our situation from the end of part 1. Each team / department / company / etc has their own tenant within our single managed HA install of Alfresco. Each one has their own set of users, and are fully isolated from each other. Our setup looks a little like:
At this point, User 1 asks User 4 to help out with a document in Repository 1. Maybe it's a cross-team project, and they need to collaborate on the presentation to give to management. Maybe User 1 has been working a press release, and needs to get User 4 in from the PR team to sign it off. Maybe Users 1 and 2 are a company, and they've hired in freelancer User 4 to help with some work. There are many reasons, but what to do?
Well, one option is to email the document over, or copy it on a USB stick or something. This wouldn't be much fun, creates a tracking nightmare, and hey - didn't you buy this Content Management thing to avoid that sort of nasty mess in the first place? Clearly this isn't what we want...
Hmm, well, Alfresco supports Replication and Transfers, could we maybe use that? Let's see how that would work:
The problem here is that we still have two copies. That means two lots of hassle, constant issues with working out which version to use, who has the latest changes, what filename to use, how to keep in sync, all that sort of thing. In short, you've recreated most of the problems that drove you to a Content Repository in the first place!
Well, what instead if we gave User 4 an account on our Repository 1 tenant? Wouldn't that work?
Now, our first issue is how to let them log in. Normally, Alfresco uses the domain part of the username to identify the tenant, so we can't just let email@example.com log into @company.example.org as the domain is wrong. This means we either have to use non-emails (eg firstname.lastname@example.org and jim@company), or we have to play with a load of settings, or both. Next up, what about poor Jane and where to go? If she logs into his normal account, she can't see this Press Release she's supposed to work on. Then she remembers and logs in with a different, unusual account, and accesses the Company tenant with the thing to work on. In here, she can't see her normal content, can't see her normal changes, can't easily access her stock content in her site, and is generally confused about where she is (it looks the same but isn't!). The upshot is user confusion, annoyance, people rarely logging into some systems due to the faff, and a lot of admin overhead (creating all those duplicate accounts). This just doesn't fit how people work today.
At this point in our story - enter Alfresco Cloud! A triumph of vision over a lot of things... The Alfresco Cloud version is built on top of the regular Alfresco Enterprise codebase (ish...), with customisations to both the underlying services, and the UI. Part of what it changes / introduces is a brand new model of Multi-Tenancy.
When someone talks about Alfresco Cloud-Style Multi-Tenancy, or Cloud MT, or something like that, there's one key bit they're probably referring to. Well, two related bits. But first, two screenshots:
Leaving aside for a moment that one is using a largely-stock Alfresco 4.1 theme, and the other is using a the very snazy new 4.2 one, there are two things to see. Firstly, the URL. In the local version, we have a common URL, with just a user's email in the final part of the URL for their dashboard. For the cloud one, we see the domain (tenant) included in the URL. Secondly, on the local one, there's no way to pick a tenant. On the cloud one, we see our tenant listed at the top. Clicking that...
We then have the option to access additional (secondary) tenants to which we have been invited to. Not all tenants on the system, mind you, just the ones to which access has been granted. Also, not all resources within those secondary tenants, only sites to which we have been invited. (In your home tenant, you can access all public sites by default, in secondary tenants you can only access sites to which you have explicitly been granted access, and no others)
The practical upshot of all this - modern style collaboration can work, and can work well! We can largely maintain the required "silos" between data, each group (tenant) can manage things for their own team / department / company / etc, but they can invite specific people to collaborate with them on one specific thing (and only that). The invited user can access that small subset using their existing login, without needing to do anything special, can see what's going on, can work on that document alongside their own ones, and it's all good!
Before we end this post, a little bit on the technical side. (Note - I didn't write any of the Cloud-Style MT code, but I have been to talks on it)
What exactly is involved in the cloud-style multi-tenancy, from a coding side? I'd say the main things are:
- Ability to specify the tenant of interest independent of the login (so you can pick an invited tenant)
- Store/check/retrieve/manage additional (secondary) tenants for a given user
- Different permissions when in an invited (secondary) tenant to your home one (can't see non-invited sites, search users etc)
- Cross-tenant invitations
- A whole bunch of tenant creation stuff, self sign-up, tenant management, billing, metrics etc (required to run the cloud scale service)
I'll largely ignore the last one, as that's specific to running The Alfresco Cloud, as opposed to running something like the Alfresco Cloud. (This part is pretty much independent of the rest, and while important for the Alfresco Cloud, has no interest to anyone else.)
So, what's the scope of these changes? The first one was actually the one that took much of the work. The WebScript framework on both end needed changes, these had to be fed down to the Tenant Service, and the URLs changed too. Since people can be in multiple tenants, you can't just auto-detect their active tenant from their username. Instead, the URLs hold the current tenant of interest, and change based on the tenant you're in.
An extended Tenant Service was also needed, to hold the details of the additional / secondary / etc tenants for a user, allow querying of them, management of them etc. This part is quite small. Then, you need some logic that pulls out the requested tenant from the URL / webscripts, checks it's allowed for the user, and sets of the context for the request. You also need to change some permissions things, as someone who's only a guest in a tenant (accessing it as a secondary tenant) shouldn't be able to do everything as in their own tenant. We also need to have the support for inviting someone to a different tenant, so you can invite User 4 to join a site in Repository 1 with the tenant change happening inside the invite transaction stuff. Oh, and you need to maintain this whole set of Multi-Tenancy code alongside the existing On-Premise single MT code, bug fix and enhance both etc...
All of this is hard, tricky, and took a lot of work! However, it's also all done... Alfresco have tackled the problem, and come out victorious! Yey for the Alfresco Engineers!
In the final part, we'll look at why other people might want all of this lovely thing not in the Cloud