|Alfresco Multi Tenancy - An Introduction
||[Sep. 15th, 2013|11:40 pm]
Alfresco has supported Multi Tenancy for a number of years now. A little over a year ago, Alfresco added support to the Cloud version which expanded the MT support, but thus far hasn't brought those improvements back to the On-Premise (One) version. In this series of blog posts, I'll try to explain what the traditional Alfresco MT does (and doesn't) do, what new things the Cloud MT handles, and finally why I feel everyone would benefit from from the Cloud MT on-premise.
Right, so, Multi Tenancy, what is it? The Alfresco Enterprise Documentation covers part, and the Wiki has a lot of details. Neither of them seem to cover much of the basics, which can cause some confusion (it certainly has when I've tried to explain it to others). I'll try to give a quick intro, feel free to skip the next few paragraphs if it's all known to you already!
With a simple content store system, you typically have a single installation, which hosts a single set of content. One set of users, one set of files, everything in together. Works just fine for your team / department / company / etc. Something like:
Your new system is great, and everyone wants in! You start adding accounts for a couple of people from another team / department / etc, so they can use your system. You create them their own sites to collaborate in, but it's still your system, and you retain full control. After a while, they decide they want their own system, which they themselves have full control over. To do this, they install their own brand new copy of the system, set it up, create their own set of users and sites, grant permissions, tell people the new URL etc. You now have two independent installations, each holding their own independent repository stores.
Having two independent systems may seem great to start with, as each team / department / company etc has their own area. They can do whatever they want, they have full control over their own things, they don't have to worry about checking permissions to prevent someone in one team having access to another team's things, there's a nice big gap between them. Then, you start needing to upgrade, to apply customisations, to develop new in-house features. Suddenly, there's two different systems that both need to be updated, both need to be tested and validated. Two different systems need to be maintained, two different systems need two sets of resources, twice the monitoring, more IT work, more co-ordination. Trying to add some more teams / departments / companies / etc in is going to make this even worse. Federation / common interfaces / CMIS can help a little with the common access, but the work grows....
At this point, some bright spark starts asking for Multi Tenancy. Instead of having one complete install for each individual group, why not have them share a common one, but have the system pretend to them that each one is independent? From a maintenance and resourcing perspective, you pretty much just have the one system to look after. From a user's perspective, they each have their own totally independent content / users / permissions / admins / etc, as before, but it's simpler and cheaper to run.
In this model, there's generally a "super-admin" somewhere who can create or delete new tenants within the common (multi-tenant) system, and who can reset admin passwords within each tenant. Otherwise, each sub-part of the system (each tenant) is independent of each other, doing their own things in blissful ignorance and fully protected from what's going on in the other tenants. The cost of hosting / maintaining is shared, so everyone wins on cost. It isn't quite a fully independent system, as things have to be the same until you have identified which tenant you belong to (perhaps by a URL, or more commonly based on your username on login), but for old-style working this was fine.
This sort of multi-tenant model was very popular with hosting companies, and large companies with strong divisions. Each team / department / company had their own sub-area that they could work in, that was "theirs" which they had full control of, but there's only one installation. For big setups, you could also get extra resilience and availability, since rather than 3 teams each having their own one server, they could club together and get a HA cluster with 3 machines in it that they all shared.
As previously mentioned, Alfresco has supported this style of Multi-Tenancy for quite some time. (I believe there was one big OEM deal that funded a lot of the initial work on it, but there had been plenty of call for it from the field before this). It used to be a little fiddly to set up, but as of 4.0.2 it is pretty simple to get going. There's information on the wiki and in the enterprise docs. Let's have a go at enabling it for our Enterprise 4.1 install to see!
First, log into the Repo (Explorer) interface as an admin. Next, go to the tenant admin console at http://localhost:8080/alfresco/faces/jsp/admin/tenantadmin-console.jsp (assuming a default install). You should see a very simple Explorer console / shell thingy to interact with:
When we run
show tenants we see that we have no tenants by default. Let's create one! Type in
create example.org adminpass and wait while it churns away. (Your first tenant is a little slow, as a load of setup happens, but new ones tend to be fast). Next, head over to share. Instead of logging in as admin instead use email@example.com and a password of adminpass (we set the domain and admin password at creation time). When we log in, we see an empty repository, without any of the sites we previously had
Create a new site here, and upload a few files. Then, log out, and log in with the normal admin account. Search for the site you created, but you won't find it. Alfresco keeps the different tenants independent, including the default tenant and the one you just created.
Finally, before we look at the problems that modern styles of working pose to this, let's do a quick round-up of what the Alfresco On-Premise / Enterprise / One implementation of Multi-Tenacy does and doesn't do.
You can use Multi-Tenancy with the following:
- Alfresco Explorer (JSF-based web client)
- Alfresco Share (since 3.2)
- Web Scripts
- CMIS (since 3.2)
- tenant 'guest' authentication is allowed, but must be within the context of a tenant (such as 'guest@acme')
Unfortunately though, the following are not supported/implemented/tested in a multi-tenant enterprise environment:
- LDAP, NTLM and authentication methods other than "alfresco"
- Inbound Email
- Content Replication
- SPP / VTI (SharePoint Protocol)
- reloadable Share config (if using dynamic models)
- GoogleDocs integration
In Part 2, we look at what the Alfresco Cloud offers in place of this.