Someone wants your software - Is it platform ready?

You created some piece of software that can be repurposed by you or by others.  Step back and think about how the system was built.  Do the design and data protection rules mean you have to run multiple single-tenant instances?  Is it built in a way you can securely add tenants into a multi-tenant system?

Identity management, data security, load isolation, data isolation, log, and metric isolation, reporting controls, data exposure, and APIs are just some of the things that you need to review before signing up new consumers.

Multi-tenant or Single-tenant

The big push is to Software as a Service.  You stand up your platform in the cloud for use by other teams or organizations.  There are two main models for supporting multiple customers. 

Muli-tenant: The customers all run within a shared environment.  The environment is coded to firewall off the different consumer groups to make it appear as if they are the only ones in the system. Multi-tenancy often must be supported at multiple places, persistence, identity management, monitoring, logging, etc.

Single-tenant: The customers all run their own isolated instances. This works especially well with monolithic or very shallow applications.  Light-weight LAMP or MERM applications would be good candidates.  Systems with highly sensitive data might be single-tenant in order to create an auditable security boundary. Operations management components or networking components might be shared even in a single-tenant environment.    
Hybrid-tenant: Deeper more complicated systems may be a hybrid of single and multi-tenant components.  Data might be completely isolated.  The data interchange portal may be shared across all external parties.


Let's walk through this as a story!

It started with a simple application.

You have a simple application that could be useful to others.  The diagram shows an app with a database. It could be  JAM  LAMP,  MERN, MEAN, or something else. There aren't a lot of pieces to the system at this point.

Someone else wants the functionality 

You want to provide the functionality in a short amount of time.  The app was originally built for a single purpose.


The simplest way to support that, especially in AWS, Azure, or GCP is to just stand up another copy.  We are running two single-tenant copies of the application.  The logs, metrics,     and identity are also isolated from the other application.
Some organizations have very strict data protection or isolation requirements. In that case, single-tenant may be the only option.

The app grew

Then your app grew up to have multiple services behind the front tier. Now we have to decide if it is all single-tenant, multi-tenant, or a mix.  Single-tenant might have a lot of components.  Multi-tenant might have security issues around mixing data, users and processing in each tier.

Production hardening adds a small explosion of supporting components. Each tier and component has its own metrics and logs. The monitoring and logging information would be very useful to the consumers/customers

Isolation and Security with multi-tenant

In this case, we decided to provide a customized human user experience.  That let us isolate identity management and any customer/ front-end data store.

The diagram shows a multi-tenant API tier.  We isolate the database in the service tier by giving each customer their own database space isolated from others. The API services know how to bind a domain/company to a single instance. I've seen where we used a single schema/database for all the tenants. The various tenant data was co-mingled. It made it hard to provide non-mingled bulk data.

In this case, we have tenant-specific logs and metrics for the Web tier.  We have potentially co-mingled logs for the Service Tier.

The application becomes a platform

It turns out that even a simple app has other pieces that make complicate our decision tree. This image shows two new pieces, one business and one operational.  We revisit our tenancy decisions as we add more components.

  1. The column on the left is an external API tier that provides service access to each tenant's database.  
  2. The system on the right feeds the hosting company's systems.  That single corporate system does not handle customer data and can be shared across tenants.

Data protection and version skew isolation zones

Here we have two tenants.  They share some single-tenant pieces and some multi-tenant pieces.
  • All of the components with persistent data are staged in single-tenant zones.  
  • The external API tier is multi-tenant because a single process handles all requests, routing, and data protection for the request. It can sit on top of either single-tenant or multi-tenant data stores
  • The corporate and bookkeeping systems are single-tenant because they support all the tenants.

Created 2021 10


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs