Co-locating microservice persistence containers within tenant-specific database
A platform's central instance manager (IM) receives microservice requests issued to a common application shared between various tenants. Embodiments function to co-locate within a same database, the persistence containers of different microservice instances of a specific tenant. The central IM associates a corresponding tenant identifier with microservice request instances created. Referencing this assigned tenant identifier, the central IM maintains an external configuration file comprising a mapping of services (m) and tenants (n), to relevant persistence container service instances. Such mapping permits the allocation of tenant-specific microservice data for storage within persistence containers of a particular database. This co-location of data promotes flexibility, allowing tenants to furnish database structures tailored to their individual needs. Consolidating microservice persistence containers within a tenant-specific database may also facilitate: the efficient backup of data, the isolation of individual tenant data for security purposes, and/or the provision of access to individual tenant data by extension application(s).
1. A computer-implemented method comprising:
co-locating persistence containers of different microservices of a specific tenant, within a same database, wherein the co-locating comprises:
an in-memory database engine receiving a service request from one of a plurality of tenants sharing an application;
the in-memory database engine instantiating a service instance from the service request; the in-memory database engine determining, from a tenant identifier associated with the service request and a configuration file including a mapping, whether a tenant-specific database is configured with the one of the plurality of tenants;
if the tenant-specific database is determined to be configured with the one of the plurality of tenants, the in-memory database engine storing the service instance in a first schema of the tenant-specific database, where the in-memory database engine grants to an outside extension application, access to the first schema;
if the tenant-specific database is determined to not be configured with the one of the plurality of tenants, the in-memory database engine storing the service instance in a second schema of a service-specific database, wherein the configuration file is stored in the service-specific database;
an instance manager separate from the in-memory database engine receiving a logging request;
the instance manager receiving a parameter indicating a service plan; the instance manager instantiating a logging service instance from the logging request and the parameter; and
based upon the logging service instance and the configuration file, the instance manager storing the logging service instance in the second schema of a service-specific database, wherein,
the tenant-specific database comprises the in-memory database, and
the associating is performed by the in-memory database engine of the tenant-specific in-memory database.
2. A method as in claim 1 further comprising:
associating the tenant identifier with the service request.
3. A method as in claim 1 wherein:
the service-specific database comprises another in-memory database; and
the instance manager comprises the in-memory database engine of the service-specific database.
4. A method as in claim 1 wherein instantiating the service instance comprises calling a representational state transfer (REST) application program interface (API).
5. A non-transitory computer readable storage medium embodying a computer program for performing a method, said method comprising:
co-locating persistence containers of different microservices of a specific tenant, within a same database, wherein the co-locating comprises:
an in-memory database engine of a tenant-specific in-memory database receiving a service request from one of a plurality of tenants sharing an application;
the in-memory database engine instantiating a service instance from the service request;
the in-memory database engine associating a tenant identifier with the service instance;
the in-memory database engine determining, from the tenant identifier and a configuration file including a mapping, whether the tenant-specific database is configured with the one of the plurality of tenants;
if the tenant-specific database is determined to be configured with the one of the plurality of tenants, storing the service instance in a first schema of the tenant-specific database, where the in-memory database engine grants to an outside extension application, access to the first schema;
if the tenant-specific database is determined to not be configured with the one of the plurality of tenants, storing the service instance in a second schema of a service-specific database, wherein the configuration file is stored in the service-specific database;
an instance manager separate from the in-memory database engine receiving a logging request;
the instance manager receiving a parameter indicating a service plan;
the instance manager instantiating a logging service instance from the logging request and the parameter; and
based upon the logging service instance and the configuration file, the instance manager storing the logging service instance in the second schema of a service-specific database,
wherein,
the tenant-specific database comprises the in-memory database, and
the associating is performed by the in-memory database engine of the tenant-specific in-memory database.
6. A non-transitory computer readable storage medium as in claim 5 wherein instantiating the service instance comprises calling a representational state transfer (REST) application program interface (API).
7. A computer system comprising:
one or more processors;
a software program, executable on said computer system, the software program configured to cause an in-memory database engine of a tenant-specific in-memory database to:
co-locate persistence containers of different microservices of a specific tenant, within a same database, wherein the co-locating comprises:
receive a service request from one of a plurality of tenants sharing an application;
instantiate a service instance from the service request;
determine, from a tenant identifier associated with the service request and a configuration file including a mapping, whether the tenant-specific database is configured with the one of the plurality of tenants;
if the tenant-specific database is determined to be configured with the one of the plurality of tenants, store the service instance in a first schema of the tenant-specific database, where the in-memory database engine grants to an outside extension application, access to the first schema;
if the tenant-specific database is determined to not be configured with the one of the plurality of tenants, store the service instance in a second schema of a service-specific database, wherein the configuration file is stored in the service-specific database;
the software program further configured to cause an instance manager separate from the in-memory database engine to:
receive a logging request;
receive a parameter indicating a service plan;
instantiate a logging service instance from the logging request and the parameter; and
based upon the logging service instance and the configuration file, store the logging service instance in the second schema of a service-specific database,
wherein,
the tenant-specific database comprises the in-memory database, and
the associating is performed by the in-memory database engine of the tenant-specific in-memory database.
8. A computer system as in claim 7 wherein the software program is further configured to cause the in-memory database engine to:
associate the tenant identifier with the service request.
9. A computer system as in claim 7 wherein: the service-specific database comprises another in-memory database; and the instance manager comprises the in-memory database engine of the service-specific database.
10. A computer system as in claim 7 wherein the software program is further configured to cause the in-memory database engine to:
instantiate the service instance by calling a representational state transfer (REST) application program interface (API).