Why You Should Adopt a Multi-Tenant Solution for Real-Time Applications

In a previous post, Streamlio co-founders/engineers Matteo Merli and Sijie Guo described how Apache Pulsar provides a best-of-breed multi-tenant messaging system, complete with cross-cluster geo-replication for message data, resource isolation, a simple admin interface, role-based authentication and authorization, and much more. What I’d like to talk about in this post is the why: why you should strongly consider adopting a multi-tenant messaging system over single-tenant alternatives.

The Concept of Multi-Tenancy

Multi-tenancy is a notoriously difficult concept to pin down, but I’ll venture a definition for the sake of argument here:

Multi-tenancy is a facet of well-architected software systems that enables large organizations to use those systems to maximum effect.

The core assumption driving multi-tenant systems is that many divisions, teams, applications, geographical regions—in other words, many tenants—will need to use the system securely, efficiently, and without undue operational burdens. Note that I say one unitary system here, not multiple, discrete systems that need to be installed and managed separately.

But even serving multiple tenants isn’t quite enough. A multi-tenant system also needs to be able to serve an indefinite number of tenants. When future tenants are onboarded, the process should be seamless both for the new tenant and for system administrators. And existing tenants should be unaffected because the system was designed not just for resource and usage scalability but also for organizational scalability. After all, you never know how many teams will end up relying on a system or how crucial it will become.

One final reason why multi-tenancy is necessary in enterprise environments: resources are finite and costly, and not all tenants are of equal importance. Furthermore, the tenants using the system may have no means of coordinating their usage patterns, and they may not even have any knowledge of each other (even inside of the same organization).

Why Single-Tenant Systems Are a Problem

Attempting to shoehorn single-tenant systems into covering multi-tenant use cases invariably presents a whole host of problems. One of those core problems I’d like to call the administrative problem. If you have multiple tenants trying to use a single-tenant system, your only option is to essentially make tenants use their own isolated systems, each of which must be installed and administered separately. This problem is illustrated in Figure 1 below.

^{Figure 1. Cluster isolation in a non-multi-tenant system with no unified admin interface}

In this figure, there are three tenants inside of an enterprise: the finance division, the business intelligence division, and the auditing division. In this case, each division (tenant) uses its own cluster (could be a messaging cluster, a NoSQL database cluster, etc.). There are a number of fundamental problems with this scenario:

• If a fourth division (let’s say the inventory division) needs to use the system—already a bit of a misnomer because there are many competing systems in play—it will have to stand up a new cluster on its own (or get someone from elsewhere in the org to do it for them). This means that it needs to procure resources—machines, disk space, networking infrastructure—to do so and then either manage it themselves or get someone else to.
• Each of the three clusters has its own admin layer, which presents major administrative redundancy and wastes valuable eng and ops resources.
• There’s no central admin layer that has a bird’s-eye perspective on the different systems.
   

Look again at the empty admin layer in the diagram above. What you should really see there is your organization leaking resources.

A Brief Overview of Multi-Tenancy in Apache Pulsar

At Streamlio, we've adopted Apache Pulsar (incubating) to provide the messaging layer of our real-time platform in large part because it provides such a compelling multi-tenancy. Pulsar was originally built with Yahoo’s massive multi-tenant needs in mind and ended up powering massive, business-critical applications like Yahoo! Mail, Yahoo! Finance, Yahoo! Sports, and Flickr. Upon being open sourced in late 2016, Pulsar became quite simply the only open source pub-sub messaging system available today that offers full multi-tenancy.

In Pulsar, the basic building block of multi-tenancy lies in that a single Pulsar instance can consist of multiple physical clusters (separate clusters can also use cross-cluster geo-replication for message data). An instance is essentially a full Pulsar installation that:

• May include as many physical Pulsar clusters as you need, even hundreds (Yahoo uses 10+ but there are, in principle, no limits)
• Allows for as many tenants as you need (Yahoo has 80+ tenants, but again, you can have many more)
• May include clusters that geographically span the entire globe (and replicate message data via geo-replication)
• Each tenant can be granted access to any or all of the available clusters
• Multi-tenancy is highly scalable because adding clusters and tenants simply means writing small amounts of data to ZooKeeper
   

An example of a cluster/instance/tenant architecture in a hypothetical enterprise can be seen in Figure 2 below.

^{Figure 2. Clusters and tenants in a Pulsar instance}

In this diagram, there are three tenants within a large enterprise: finance, business intelligence, and auditing. That enterprise is using a single Pulsar instance that currently consists of four geographically separated clusters (in the Eastern US, Western US, Asia, and Europe). In this particular enterprise, not every tenant needs access to every cluster. Finance needs to access us-west and asia, business intelligence needs to access us-west and us-east, and auditing needs to access all but the us-west cluster.

In Pulsar, there’s a variety of things that you can control at the tenant level:

• Authentication and authorization
• Access to clusters (using role-based access)
• Geo-replication between clusters
• Resource isolation
   

We'll cover how multi-tenant administration works in the section below.

Multi-Tenant Administration in Pulsar

Take another look at Figure 1 above. Note the strict separation between the three systems, each represented as a self-contained capsule. In stark contrast, this is what an Apache Pulsar instance looks like:

^{Figure 3. Multi-tenancy in Pulsar}

In this case, the finance, business intelligence, and auditing divisions use the same Pulsar instance. The benefits should be immediately clear by now:

• There is a single administrative layer with three available interfaces (the pulsar-admin CLI tool, a REST API, and a Java client API) that oversees the entire system. That admin layer controls authentication and authorization for all tenants, resource isolation policies, storage quotas, and more.

• Each tenant can use as many multiple clusters as you'd like, and enabling and disabling tenants' access to any cluster takes just one call to the admin API.

• Onboarding a new team, for example an inventory team, would involve simply creating a new tenant property and granting the inventory tenant access to desired clusters. Here's an example:
   

  $ pulsar-admin properties create inventory \
    --allowed-clusters us-west,us-east
  

   

Conclusion: Pulsar and the promise of multi-tenancy

Large, multi-faceted enterprises demand a lot out of software systems. They typically have exacting security requirements and require a lot of resources—from hardware to human hours and beyond—that they need to use as efficiently as possible. In order to satisfy these requirements, enterprises often opt for multi-tenant systems.

But resources are finite and costly, and not all tenants are of equal importance. Furthermore, the tenants using the system may have no means of coordinating their usage patterns, and they may not even have any knowledge of each other (even inside of the same organization). Apache Pulsar is a system that solves these problems and does so with aplomb.

Messaging systems are becoming ever more important in large organizations, whether they're backing service-oriented architectures or powering edge computing systems or serving massive real-time workloads. Single-tenancy just doesn't cut it when it comes to such crucial infrastructure. Multi-tenancy is a must, and Pulsar has come along to fill a yawning gap.

Thanks,
Luc Perkins