In a previous post here on the Streamlio blog, 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.
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).
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.
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:
Look again at the empty admin layer in the diagram above. What you should really see there is your organization leaking resources.
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:
An example of a cluster/instance/tenant architecture in a hypothetical enterprise can be seen in Figure 1 below.
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:
We’ll cover how multi-tenant administration works in the section below.
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:
In this case, the finance, business intelligence, and auditing divisions use the same Pulsar instance. The benefits should be immediately clear by now:
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
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.