Multi-tenancy models

An empty house is better than a bad tenant.”
Irish Proverb

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.

  1. 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.
  2. 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.

4 thoughts on “Multi-tenancy models

  1. Hi Ryan,
    Multi-tenancy is such an important area – as you’ve mentioned in at least a couple of your blog entries (that I know of). In case you’re interested I’ve been following a LinkedIn thread by John Reilly of the TMF re the evolution of the ‘value chain’ concept into the new world of ‘value fabric’, which overs this area (Multi-tenancy). It may be worth connecting with John if you’re not already? Regards Evan

  2. Sounds very interesting Evan!
    It could be another concept to add to the blog roll at some point in the future!!

  3. Ryan: We see in our customers and prospect many instances of customer information and IDs being stored in the network devices. It is indeed handy, but can also raise concerns wrt privacy laws, even national security. We have seen examples where sensitive government organisations (including intelligence agencies) were explicitly identified in device names.

  4. Hi Roland,
    Great point!!
    That’s so true. In my experience the “secure” customers, or even internal teams like lawful intercept, are given network segments / ranges that aren’t scanned by the same OSS tools as the “public network” customers. It’s interesting when organisations like yours are given access to the whole network and you find things that perhaps you shouldn’t. A close friend of mine was once trying to find out about an unexpected network range that popped up during a reconciliation scan. He received a menacing phone call to the effect of, “how did you get this information? Delete any records you have immediately. We have not had this conversation! Click.”
    With respect to privacy, many CSPs I’ve dealt with have embedded customer and service IDs in the network that are system generated and can’t be directly identified as a particular user or customer. Then again, I guess there are always other breadcrumbs back to privileged information within an OSS.
    As you’d have experienced too Roland, it’s always interesting to look at the raw data sources and see what surprise insights jump out at you isn’t it?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.