Back
Author: Shah Zeb, University of Bristol
JOINER provides a shared infrastructure, but every project needs a safe, isolated environment in which to experiment. So it’s almost a given that the platform should have a multi-tenancy architecture.
In its essence, multi-tenancy means different users from different organisations can use the same complex infrastructure in a shared fashion, without needing to worry about the other projects running simultaneously across the same tech stack. This perhaps makes it sound more simple than it is, but shielding users from this complexity is, equally, part of the service. All they need worry about is what they’re working on.
A better way to think about JOINER is as a shared national research environment, rather than a single-purpose lab. Multiple projects can be active at the same time, using parts of the same underlying platform, but each with its own project boundary, access rules, resource allocation and lifecycle. That is where multi-tenancy becomes essential: the infrastructure is shared, but the research experiment environments must remain distinct.
Lots of people might think of multi-tenancy as involving little more than logins: providing usernames and passwords to allow different people access. But it’s a lot more complicated than that. We’re managing and orchestrating resources, not just handing out multiple logins. Handling singular requests is easy, something that can be automated fairly simply. Managing multiple simultaneous requests automatically is much harder. And for JOINER, multi-tenancy needs to happen across the entire vertical stack. If we receive a request for five virtual machines and 100GB of storage at our Bristol node at the same time as 80% of our resources at that Terminal are in use, we need to be able to quickly redirect the request to pull in resource from another node without the user experiencing a delay.
So how do you design for this?
Multi-tenancy design is integrated across the entire JOINER architecture: user, infrastructure, and our user portal, the JOINER Brain. For this we design in layers — five in total, and each with isolation at its core.
The top layer is user multi-tenancy. This is where we can identify the user’s relationship with the platform — so whether they are, for instance, a researcher working on an experimentation project, an admin at one of the JOINER nodes, or a member of the operations centre here in Bristol. The Brain needs to understand the relationship between users, organisations, projects, roles, approvals and resource ownership.
At the second layer, we manage access. This is where access control and user access policies can be established, governing who a user is and what a user is authorised to access, and for how long. We’ve designed a custom access system for this, splitting out three project user categories: leader, admin, experimenter. This is defined as a relationship-based, project scope access control where access permissions are tied to the relationship between a user, a project and a role. A leader is the ultimate project owner, admins have management controls, and experimenters are able to access the tech stack assigned to their project.
The third layer is resource allocation and orchestration. This is where project requests are managed and enabled. This happens automatically through the Brain, which enables multiple requests to be resourced, orchestrated, and isolated from one another. JOINER’s federated setup means that Terminal resources — more detail on those over here — are spread throughout 15 separate nodes, and can be easily spun up and down to accommodate requests. If a resource exists in JOINER, the Brain needs to know which project owns it, who can access it, what policy applies to it, and what should happen to it at the end of its resource lifecycle. It turns a high-level project request into a repeatable, policy-aware infrastructure workflow
At the fourth layer, we have observability and operation. This is JOINER’s operations centre, where myself and the team in Bristol are monitoring the platform in real time via an array of screens and desks — the physical manifestation of the Brain as a nerve centre. We ensure that resources are being used in accordance with each project’s guidelines, and are able to keep the wheels greased for all live projects operating across our 15+ nodes. For Ops, multi-tenancy gives traceability, and for users, it gives confidence.
The fifth layer is isolation, and is maintained by the Brain. In some ways, it’s unhelpful to think about this as a layer because, in reality, it runs more like a thread throughout each level of the JOINER platform. It means isolating user identities on different projects from each other at the first and second layers; it covers compute, storage, network and data isolation (in cases in which different projects are using resources based at the same location for different projects, for instance) at the resource allocation layer. That means one project cannot see, modify or disrupt another project’s resources, even when both are using the same underlying JOINER platform.
Why this approach is important
Simply put, our multi-tenancy design offers speed and security. Two things that can often be sacrificed at the expense of one another.
Experimenters can spin up projects much faster, without having to spend months churning through an expensive procurement process to build out their research environments. And because we’ve designed for isolation throughout, we’re able to do the same with additional security measures. Again, this is more than just user credentials; security is baked in across the infrastructural level too. Our design provides researchers with the peace of mind they need.
JOINER’s security model follows a secure-by-design approach, and is layered throughout the platform in the same way as multi-tenancy is. In practice, this means MFA-based SSO logins at the application level, and siloed project areas so that users can only see the projects, resources and actions they’re authorised to access. Resource requests are checked against project scope and deployment policies before anything is provisioned, and access is linked to a project’s lifecycle — meaning permissions can be reviewed, revoked, or cleaned up when an experiment ends. In the operations centre, our team maintains audit trails to keep tabs on who requested a resource, which project it belongs to, when it was provisioned, and what changes were made. All of this makes it possible to offer speed without treating security as an afterthought.
There are benefits for JOINER in this too. In particular, the ability to push to the full capacity of our tech stack and support as many projects on the platform as possible. That helps JOINER towards its own goal of breaking down barriers to innovation and better connecting industry, academia, and government decision makers. On a personal, technical level, it’s pretty satisfying to see everything humming along too.