Sometimes the best solutions stem from the simplest questions. Simple questions often prompt us to think about why we do things the way that we do. For example, a customer recently asked me, “What about multi-tenancy for my MEC?”

Multitenancy and MEC are both loaded terms, so an easier way to tackle this question is to start by asking, “Should I plan to support multiple customers on my network-edge cloud infrastructure; and if so, how do I do it?”  

Multitenancy is one of the critical benefits of a cloud environment, and sharing resources seems to make sense in a highly constrained environment like the edge. Despite its benefits, multitenancy also introduces significant management complexities, which come at a cost. These complexities can drive customers to consider whether the efficiencies of multitenancy justify the costs. This answer depends on both the cloud model that is used to deliver a service (SaaS/PaaS/IaaS and co-location) and the customer.  Moreover, in most cases, it is either innate to the solution hosted on public MEC, or not worth the cost.  

Starting with SaaS, multitenancy is enabled through proper handling of organization accounts and associated user accounts, something that any successful cloud-based SaaS must enable. It is therefore innate in this model. The second model where multitenancy is innate is co-location because, presumably, a successful co-location business model needs more than one customer.  

For PaaS (which includes container platforms such as Kubernetes), the answer to considering multitenancy is a straightforward no. Delivering multitenancy across customer boundaries (as opposed to simply hosting multiple projects of a single enterprise) typically involves creating a SaaS offering from a PaaS-based platform. For more information, see the discussion of this issue on the Kubernetes project site.

This leaves us with IaaS and reduces the question to whether a Mobile Network Operation (MNO) deploying MEC should invest in IaaS multi-tenancy. Conversely, it might be sufficient for such an MNO to provide each customer with physical infrastructure and a cloud stack, which the customer then integrates into an overall IaaS multicloud operational process. To address this, we need to dig deeper into requirements that different types of customers are likely to have for IaaS Edge infrastructure.  

MEC IaaS and verticals

It is important to remember that the information in this section is opinion-based and should be interpreted as such.  Also, it is equally important to keep in mind that each customer is different and broad-stroke statements such as the ones below may not be valid in every situation. In short, pay attention to your customer!  

Let’s start with large enterprises, which are likely to have some of the most stringent security and management policies. IT downtime and security breaches carry significant costs, and there is substantial in-house IT expertise to deploy and enforce industry best practices. For enterprises, anything that could have been moved into the cloud while meeting IT policies and application requirements presumably is already there. This means there is unlikely to be low-hanging fruit candidates for a network-edge migration.  

A multi-tenant IaaS environment introduces additional hurdles towards meeting IT policies which can complicate an already difficult sales motion and business case. In short, the opportunity cost of trying to do multi-tenant IaaS in this segment is usually not worth it. Capturing business for network edge here is hard enough. This remains true even when such enterprises have remote locations with limited IT expertise at such sites. While the ROI of moving compute off-prem improves in such cases, the hurdle of meeting IT policies remains, and the complications associated with trying to meet them are usually not justified by the cost savings of multitenancy.  

Smaller enterprises (SMBs) often have a stronger case for moving compute off-prem while the burden of IT policies is lower. These SMBs are likely looking for an easy way to achieve an outcome. A SaaS-based solution is much more appropriate than an IaaS one, which means multi-tenancy is out of the question.

To find a business justification for multi-tenancy in IaaS MEC, we need to look outside of enterprises and to direct-to-customer applications providers that take advantage of the network edge. Examples of these include the independent SW vendors (ISVs) of SaaS solutions which are offering outcomes to SMBs (where the tenant is now the ISV itself, not its customers), and ISV offering consumer applications, like emerging interactive gaming. When such applications require Edge presence, the choice is often limited to public MEC, as there is no on-premises and traditional edge co-location providers may not be able to deliver sufficient proximity to customer to meet the required KPIs. Moreover, the customers (ISVs) are typically well-adapted to the cloud and are comfortable with issues such as multitenancy, provided that cloud-like shared responsibility structures are in place and adequately formalized (a legal and contractual issue as much as it is a technical one).

Delivering a multitenant IaaS solution   

So how does an MNO go about creating that multitenant edge?  First, we need something generic because attempting to guess what kind of applications might run on MEC simply limits the addressable market. Second, it is important to remember that operations (O&M) and management will be your biggest headache, so anything that simplifies O&M is likely to pay back for itself in spades. And third, it’s public ISVs are most likely to be your customers.   

Typically, ISVs developing cloud-native applications use some flavor of Kubernetes (K8S) as the platform. K8S flavors can span the gamut from public clouds (Google, Amazon’s EKS) to enterprise clouds (Red Hat, OpenShift, VMware Tanzu). An ideal platform would address the following:

• Provide a way to efficiently address the need for compute-intensive applications, including high-performance computing and storage-intensive ones
• Make O&M easier in a meaningful and monetarily measurable way
• Support cloud-native applications developed for any (almost any) of the most commonly used Kubernetes frameworks.  

Although that seems like a lot to ask out of a platform, solutions that address all of these points do exist.   One excellent example is Dell’s VxRail VmWare HCI platform. The definition of VxRail, according to the Dell VxRail home page is:  

VxRail goes further to deliver more highly differentiated features and benefits based on proprietary VxRail HCI System Software. This unique combination automates deployment, provides full stack lifecycle management and facilitates critical upstream and downstream integration points that create a truly better together experience

VxRail provides an MNO that flexible combination of compute (GPU and DPU options for high-performance computing) and storage, which can be easily and quickly scaled in response to actual demand.  Notably, with vCloud Suite, a VxRail deployment can be turned into a multitenant public cloud. For more information, see VmWare Public Cloud Service Definition.

Last but not least, in addition to VmWare’s Tanzu, VxRail supports Google Anthos (Running Google Anthos on VmWare Cloud Foundation), Red Hat OpenShift (Vxrail and OpenShift Solution Brief), and AWS EKS (Amazon EKS Anywhere on Vxrail Solution Brief); delivering an all-in-one platform for a flexible public MEC at Network Edge cloud deployment.   

Summary

The question of multitenancy for MEC is only relevant when considering the IaaS service model. In that case, multitenancy is not likely to be of interest when addressing most traditional enterprise customers but may be important when addressing the needs of ISVs providing SaaS solutions that need Edge presence.  To succeed in delivering a MEC platform to such ISVs MNO needs an underlying platform like Dell’s VxRail, designed to address their diverse needs in a scalable and easily manageable fashion.   

VxRail 7.0.400 introduces an option that opens up new functionality for SmartFabric Services (SFS) switches with VxRail deployments. This new option allows you to choose whether automated SmartFabric switch configuration is enabled or disabled during VxRail deployment.

In VxRail versions earlier than 7.0.400, automated SmartFabric switch configuration during deployment is always enabled, and there is no option to disable it. The automation configures VxRail networks on the SmartFabric switches during deployment, but it limits the ability to support SFS with VxRail in a wide range of network environments after deployment. This limitation is because internal settings specific to SFS are made to VxRail Manager which limits the ability to expand the network or add additional products in some environments.

Starting with VxRail 7.0.400, the VxRail Deployment Wizard provides an option to set Automated VxRail Switch Configuration to Disabled. Dell Technologies recommends disabling the automation, as shown below. 

With automated switch configuration disabled, the VxRail Deployment wizard skips the switch configuration step. The advantage of bypassing this automation during deployment is that SFS and VxRail can now be supported across a wide array of network environments after deployment. It will also simplify the VxRail upgrade process in the future.

Disabling automated switch configuration only affects SmartFabric switch automation during VxRail deployment or when adding nodes to an existing VxRail cluster after deployment. The SFS UI is used to place VxRail node-connected ports in the correct networks instead of the automation.

Automated SmartFabric switch configuration after VxRail is deployed is still supported by registering the VxRail vCenter Server with OpenManage Network Integration (OMNI). When registration is done, networks that are created in vCenter continue to be automatically configured on the SmartFabric switches by OMNI.

In summary, for new deployments with SFS and VxRail 7.0.400 or later, it is recommended that you disable the automated switch configuration during deployment. This action will give you more flexibility when expanding your network in the future.

Resources

Dell Networking SmartFabric Services Deployment with VxRail 7.0.400

OpenManage Network Integration User Guide Release 3.2

Dell SmartFabric Services User Guide Release 10.5.4