“An empty house is better than a bad tenant.”
As described in an earlier post (High-Rise OSS), multi-tenancy is becoming an important feature for OSS applications, particularly in highly virtualised environments.
Aside from the shared infrastructure itself, there are two* key components of multi-tenancy models for OSS implementers to consider.
- Applications – Naturally, the OSS tool/s must deliver the functionality that allows CSPs to segregate and visualise data on a per customer basis. This might include being able to show the assets in use by the customer at any point in time, which customers are impacted by any given network outage, etc.
- Data – What is often overlooked is that the functionality only works within the applications if they can gather data that can be identified on a customer-by-customer basis. There are a few different ways of tracking assets by customer ID but all require quite a bit of planning to ensure the data remains viable.
In theory, the best place to record customer or service identifiers is within the devices themselves as they are generally the single source of truth**. For example, we would ensure that CustomerID and/or ServiceID are inserted into fields like Device description, Interface (or Sub-interface) description, VRF description or many other data “placeholders” that exist on the devices. This could be automated by pushing the data to the network as part of the service activation / provisioning process or it could be manually inserted, which is prone to human-errors.
An alternative approach might be to rely on cross-referencing against, or augmenting from, data in a customer / inventory database or CMDB. These databases could also be populated automatically or manually.
The other gotcha to avoid, whether taking a manual or auto approach, is that you must build these data modelling rules not just for service activations but for deletes and modifications too. Otherwise the customer data stored in your network or database will lose accuracy and the OSS multi-tenancy reporting will become less reliable.
* There’s also the data segregation models to consider (eg separate databases, same database but different schema, shared database and shared schema) but that might be a topic for another day
** Sometimes devices don’t record cross-device constructs like circuits or paths.