Tenanacy Model
Varadhi is a multi-tenant RESTBus platform. Multi-tenancy ensures Varadhi’s RESTBus capabilities can be used by different organizations simultaneously without affecting each other’s resources.
In current form, multi-tenancy is supported by providing access level isolation, implemented using appropriate Authentication and Authorization policies. Additional tenancy constructs e.g. billing, quota management etc would be added in future.
Varadhi’s multi-tenancy is centered around Resource Hierarchy, which is hierarchical grouping of an organization's resources. This resource hierarchy is used to assign right IAM policies to control access to various Varadhi resources. For details on access control and IAM policies refer Access Control
All Varadhi resources are organized hierarchically. At the bottom of this hierarchy are Varadhi messaging resources of type Queues, Topics and Subscriptions. Higher level of the hierarchy has container resource types (Resource types which contain resources of other types). These container resource types are as below -
Org (Organization): Org represents the organization entity e.g. company. It is at the top of the resource hierarchy. All resources that belong to this organization are grouped under this Org resource. This provides central visibility and management of all your resources and in future would enable additional functionality related to billing and quota management etc which are org level concerns.
Team: Team resource is an additional grouping layer between org and project resources. Varadhi resource hierarchy only supports one layer of Team resource.
Project: Varadhi messaging resources can only be created under a project resource. This association is immutable i.e. once a messaging resource has been created it can’t be moved to another project. All messaging resources which need to be managed similarly can be associated with the same project. A project would typically translate to a single service or an application serving a single use case.
A Varadhi tenant is onboarded by creating an Org entity into resource hierarchy and further administering all resources under this org entity. Below diagram shows an example Varadhi resource hierarchy of an org named “some-ecom”.
Org (Organization) resource represents an organization (e.g. a company) and is at the root of the Varadhi resource hierarchy. Org resource is a prerequisite for creating additional Varadhi resources. Org resources can have one or more team resources.
From a resource management perspective Org resource is a logical container of Team resources and hierarchies underneath them.
Org resource would allow users to do org level administrations. This includes handling operations related to billing and quota management (Note: These will be implemented in future release and are not part of MVP).
If needed, Org resources can also be used to delegate access for all resources within the org to some well defined users.
An org resource consists of a
- Org’s name, which is also an identifier for the team. This is immutable.
For more information on how to create and manage Org resource refer Org API
Team resources are an additional grouping mechanism layer between org and project resources. An org resource is a prerequisite for creating a Team resource and an org resource can have one or more team resources.
From a resource management perspective Team resource is a logical container of project resources (and hence Project resource’s associated messaging resources as well).
A user might create a team resource to represent an organization or company structure. It would be
A team resource enables administration or management delegation at a higher level where a senior team member can be given a responsibility of managing all resources at Team level. Alternatively it can also be used to give limited pervasive access to team’s resources to all or more team members. More about access management
A Team resource consists of
- Team’s name, which is also an identifier for the team. This is immutable.
For more information on how to create and manage Team resource refer Team API
Project resource is a leaf level organizing entity. A team resource is a prerequisite to use project resources and a Team resource can contain one or more project resources. A project resource is required to create one or more of Varadhi messaging resources of the type Queue, Topic and Subscription.
From a resource management perspective Project resource is a logical container of Varadhi messaging resources which are managed together. Lifecycle of these resources is tied to the lifecycle of the Project resource.
In practice, a user might create a project to associate resources which correspond to either a single use case or an application which are co-managed in terms of ownership and access.
A Project resource consists of
- Project’s name, which is also an identifier for the project. This is immutable.
- Optional description, can be used to describe the Project in more details.
Restrictions on Project resource
- Project resource is globally unique across all orgs and teams within the given Vardhi deployment.
- Association of Varadhi messaging resources to a Project resource is immutable i.e. they can not be moved across the Project resources.
- A project resource can be moved across teams, but it can not be moved across the orgs. Once a project resource is moved to a different team, all resources associated with the project are also moved along i.e. now they will be managed as per the new Project resource hierarchy.
For more information on how to create and manage project resource refer Project API