Environments
As a multi-tenant service offering, the Mosaic Platform gives you the ability to
maintain a list of tenants
(based on your contract). For each
tenant that you own, you are assigned the role of a tenant administrator and
gain access to maintain any number of environments within those tenants. In this
article, a tenant
refers to a grouping of environments.
To perform any environment administration tasks, you can use the Environment Administration Portal. Using the same portal, you may also introduce more tenant Administrators when needed.
Within each environment you maintain, you can enable
the Managed Services you
want to use, and disable
them when you no longer plan on using those services.
The Core Services, however, are mandatory for each environment.
They are enabled automatically during environment creation and cannot be disabled
afterwards.
You can create, maintain, and delete environments in the Environment Administration Portal.
Environment Isolation
All resources which are generated within the Mosaic Platform have an environment-level isolation. The diagram below visualizes the relationships of some of the top-level entities to an environment.
For example, the same user with the email address abc@domain.com
may exist in the
environment ABC
, as well as in the environment XYZ
as we maintain storage isolation
per environment. They would never conflict with each other.
The records which are created by the user abc@domain.com
(i.e. an uploaded image)
in the environment ABC
are not visible to the same user in environment XYZ
.
Multi-Tenant Managed Services
Once you enable a managed service for an environment, the service starts accepting
requests from that environment (originating from a User
or a Service Account
).
The requests can take multiple forms. These could be HTTP requests if they are,
for example, invoking a service’s GraphQL endpoint. It could also be a RabbitMQ
message posted to an exchange when using asynchronous messaging to make the requests.
However, the URL endpoints of these Managed Services always remain the same (as they
are multi-tenant aware services), and you do not receive new URLs for each managed
service that is enabled for an environment.
Therefore, each managed service considers the contents of the access-token
attached
to every request to decide if the request should be honored or not. For example,
when an access-token
with the below JWT is sent to a managed service, the service
first checks if the tenantId
& environmentId
present in the payload represent
an environment where the specific service is enabled
.
{
"tenantId": "b0f7081a-8097-455d-8216-a3ff680855e1",
"environmentId": "70cbf548-3669-4fbf-a333-ec789e188e67"
...
}
If this first check is successful, then the already mentioned environment isolation
logic kicks in on the persistent storage of the service. The data records belonging
to the specific tenantId
and environmentId
are isolated and made available to be
accessed by the request.