One of the common starting points during the IT architecture process is trying to define and identify tenancy. Part of the problem is that the term “tenant” has various definitions depending on the business unit. As a network engineer, I don’t care about one of those definitions of the word: “Layer 3 subnet isolation with a unified set of routing and security policies.” Trying to communicate that to technical leaders in other IT organizations is hard enough, but trying to communicate this to a non-technical business leader can feel like an impossible task.

The goal then becomes trying to distill the complexities of a tenant into a consumable morsel.

What happened?

In my most recent consulting engagement, I worked with a company that had three key players during the design stage:

  • Server team
  • Network team
  • Business team

We kept using the word “tenancy” thinking we were speaking the same language , but we slowly realized that we weren’t speaking with the same definitions. In my network-first definition, I only cared about the subnets allocated to the servers and whether the servers were able to talk to each other. From my definition of tenancy, any server allocated to a tenant had free flowing communication regardless of the IP address. If there were 3 subnets inside a single tenant, all three subnets could speak to each other without a policy device getting in the path. No ACLs, no firewalls- nothing that would actively restrict traffic between those servers within the infrastructure.

While I was working with that definition in mind, the server team defined the tenant from their perspective of clustering. They wanted the ability to restrict traffic between clusters of compute workloads. The server team had no concept of IP addresses, L3 routing isolation, nor were they interested in getting into the specific details of how a cluster becomes a VRF. e quickly realized the server clustering requirement wasn’t a networking requirement. We were able to solve the server clustering problem through a provisioning GUI that separated the application and compute workloads when their application users requested resources. The server team was overreaching and assuming that a cluster was a VRF, but the reality was that multiple clusters could live in the same VRF since groups within the same organization would be requesting services from servers that had the same subnet, and hence the same routing and security policy. The network team was abstracted from this decision, and as a network admin I didn’t care about how the server team divided up their workloads.

We thought at this point that everyone was happy, but now enter the business team. The business team had no concept of any tech solutions. They didn’t know what clustering was, they didn’t know what a VRF was. or how servers get IP addresses and what subnet pool housed the allocated server IP ranges. When they started spouting their requests, they were describing horizontal lines while the network and server teams were describing vertical lines. The business team defined their tenancy as the different organizations and functional units within the company. They wanted isolation between those resources. On face value, that seems easy enough, but the kicker was that these units were interested in the same server workload resource pools. So not only did we have to create unique tenants for services like Hadoop clusters, Web front end and storage, but each business unit needed their own isolated group each time they requested the same resources.

How did we solve all three requirements together?

It wasn’t easy and from the lens of a technological purist I hate to say that we had to make compromises. The reality is that when we start combining multiple requirements that speak past each other, there can’t always be a clean solution that accommodates all parties involved.

We learned that the key to this process is to clearly define what tenancy means for each party involved, in simple, concise terms. Then, using these definitions, we can drive towards a solution that will meet the requirements for all those involved. Keep in mind that it may not always be possible to meet the initial definition of tenancy for everyone without some give or take on the actual definition of tenancy for at least one party. As we continue through this process, and potentially update what the definition of tenancy means for each party, we continue to gain clarity on the technical solution within the environment. Ultimately, the goal is to have a solution that aligns with the tenancy definition for all, without introducing overly complex and unmanageable requirements into the design.

If you’re interested in learning more, be sure to check out some of our other blogs including Lessons learned from Black Friday and Cyber Monday.