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.

Video

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.

Single-tenant

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

Comments

Post a Comment

Popular posts from this blog

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

Image
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with  gadget drivers  that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget  is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device.  All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget  in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update  or  Upd...
Read more

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

Image
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time.  Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM.  You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop.  Docker Desktop has two of its own WSL modules that need to be accounted for.  You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory.  The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaul...
Read more

Almost PaaS Document Parsing with Tika and AWS Elastic Beanstalk

Image
The Apache Tika project provides a  library capable of parsing and extracting data and meta data from over 1000 file types.  Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk.  I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents.   Preconditions An AWS account. AWS ac...
Read more