Breaking the Stack: Rethinking Tenant Isolation in your Cloud Migration - Part 2

Part 2 of 3 - The Bridge Tenant Isolation Model

Welcome back to the “Breaking the Stack” blog series, where we are looking at the various tenant isolation models available to us and how cloud migrations allow us to change architecture and how we isolate (or don’t isolate) tenants in our applications. In Part 1 of this series, we talked about legacy application architecture and VMware logical components and dove into the silo tenancy isolation model. In this part (part 2), we will take a look at the bridge tenancy isolation model and how its emergence was an early indicator that the silo stack's dominance was waning and SaaS architecture was on the rise.

Bridge Model

The bridge tenancy isolation model is characterized by both shared resources and isolated resources in the stack. In the previous example from part 1, removing dedicated file share servers and replacing them with S3, or moving the database calls from inside the isolated clients into a shared API service, would constitute a bridge model. Let’s look at a diagram, and then we will bring out another application example.

Diagram 2

To better illustrate this example, let’s consider a 3-tier application that uses a native client and an API. In this application, users still launch a native client application from their local machine or a remote session host. Instead of the application interfacing directly with the database, it communicates through an API layer, which then connects to the database and file servers. Bridge model applications are characterized by these key indicators:

• One or more parts of the application are completely isolated for each tenant. In the above diagrams, the database is the isolated piece. The file share is isolated in the right diagram but not the left. 
• One or more parts of the application are shared or using pooled resources. In this example, all the requests from the client to the backend go through a shared API layer. 

This hybrid approach enables teams to optimize for scalability and cost while preserving tenant boundaries where security, compliance, or “noisy-neighbor” concerns demand stronger isolation. This is all well and good, but how does it impact migration? What are some of the things we need to be aware of when trying to move this type of application, and what opportunities for improvement may or may not present themselves?

There are several challenges that present themselves with this bridge model. For instance, how do we allocate costs to tenants when they use a shared resource? How do we handle access control coming from an environment that typically relies on more coarse-grained access control, like dedicated VMs or per-tenant domains? When moving the data layer, data layer segmentation must be considered: is it schema-per-tenant, database-per-tenant, or a shared database with row-level security?

Understanding the touchpoints—the connections between components—is crucial, similar to the silo model. Consider shared APIs: can they be replicated in AWS Cloud while still pointing to isolated resources? You might need to migrate the shared parts of your application first, followed by the isolated parts incrementally. This depends on the configuration of these touchpoints and your deployment processes. Be mindful of client-side configurations that dictate routing to siloed resources. Will each migration necessitate a new client or require end-users to update their systems with new database connection strings or API endpoints?

Another thing to wrap your head around is whether there is an opportunity for improvement when moving this type of application. If the API layer is the shared part, then we have a readily available spot to “jump off” to new improvements. For instance, if you wanted to add a cache between the API layer and the databases, then making changes to the API layer to handle this routing is much easier than it would be in a client-server environment, where each client would need to have an updated configuration. Additionally, if you decided to combine all of the isolated DBs into a single DB and then implement something like row-level security, having that shared API layer would once again make the transition a bit easier. You could add additional services that the API reaches out to and begin splitting pieces of the existing monolith off into microservices. The key to these decisions is to ​​let the data isolation needs from a compliance and performance standpoint drive the structure of the target architecture. 

Okay, with the knowledge of silo and bridge isolation models and our application examples fresh in our minds, let us take a break. In the next part (part 3), we will dive into the most common cloud-native tenant isolation model that, if you come from a web background, you are probably already familiar with. The pool isolation model.

The Evolution to SaaS: A Shift in Application Delivery and Design

Let's briefly explore the evolution of application and system design, particularly the rise of the Software as a Service (SaaS) model and its reliance on the bridge model. This represented a significant shift from traditional software delivery methods, such as distributing physical disks or requiring downloads through complex online portals while the server resided within an organization's own data center.

As software hosting and distribution methods changed, so too did application architecture. Today, following tutorials from major application framework sites often leads to applications that align with a tenant isolation model we haven't yet explored: the pool model. We will delve into the pool model in the subsequent section. However, it's important to note how this evolution in operating paradigms has driven a corresponding transformation in how we distribute and architect our applications. The emergence of the bridge model was an early indicator that the silo stack's dominance was waning. Driven by the pursuit of economies of scale, industry thought leaders like Armando Fox and David Patterson authored "Engineering Software as a Service," a highly influential book known simply as "The SaaS Book."

These developments initiated a profound transition, leading major software like Microsoft Office Suite and Adobe Premiere to adopt online delivery models. Consequently, many others are now striving to adapt and modernize their applications for greater efficiency and more effective distribution.

Conclusion

This concludes Part 2 of the Breaking the Stack Series. In this blog, we took a look at the bridge tenant isolation model and a sample application. We also referenced our silo isolation example from Part 1 to highlight how changing from silo to bridge is sometimes an effective strategy. As architectures moved from manually delivered and siloed architecture, and SaaS became more popular, the onset of bridge and then later, the fully shared pool model architecture came about. Check back frequently for Part 3 of 3, where we will cover the pool isolation model. If you are already familiar with the pool model or just can’t wait to get our help with your own cloud migration strategy, feel free to drop us a line at sales@ipponusa.com.