Weighing Up (Telecom) Cloud Deployment Strategies

Broadly speaking, there are two types of telecom cloud strategies: single-vendor versus multi-vendor deployments. With the former, one vendor integrates its virtual network functions (VNFs), VNF manager (VNFM), and virtual infrastructure manager (VIM) with the underlying hardware layer. With this approach, the VNF vendor supplies its own hardware. The supplier carries out the engineering and fine tuning between VNFs, hypervisor environment, and the network function virtualization infrastructure (NFVI) layer. The engineering concept of interdependence best characterizes a single-vendor deployment. An architecture is interdependent if one component cannot be created independently of the other part. The way one component is designed and integrated depends on the way other components are designed and integrated. Network Equipment Vendors (NEVs) such as Nokia, Huawei, Ericsson, and ZTE excel at commercialising interdependent product architectures.

In contrast, a multi-vendor deployment consists of (modular) disparate components. A modular architecture is a clean one. There are no unpredictable interdependencies across components. With this deployment strategy, a diverse set of components (e.g., VNFs, VIM, etc.) need to be chained together and their life cycle managed as one coherent platform. Modular components are designed and built by different vendors working at arm’s length. So in addition to NEVs, the pool of suppliers extends to pure-play software vendors (e.g., Mavenir, Affirmed Networks) and hyperscalers (e.g., AWS, Google, Microsoft). This supplier diversity mandates a high level of integration for CSPs to automate, onboard and life cycle manage individual VNFs/CNFs. In the end, there are pros and cons to weigh up for a CSP to decide on which deployment strategy best suits their commercial standing.

A single-vendor strategy reduces complexity because all components and interfaces are integrated together in advance. CSPs can obtain better assurance and monitoring capabilities to support management at the VIM and NFVI layers because a single vendor spans all cloud components. Further, a single-vendor approach is more conducive to ‘operational effectiveness’ within the narrow scope of what is hosted in the cloud platform. On the flip side, a single-vendor strategy can potentially lead to CSPs losing leverage for negotiation. This is pertinent if there is no multivendor interworking and cloud stack openness to enable CSPs onboard other vendors’ solutions into their cloud execution environment. In addition, a single-vendor strategy renders CSPs reliant on one vendor for support and continued delivery of cloud capabilities as they embrace digital-first processes and operations.

The multi-vendor cloud stack strategy is better suited for new B2B value creation. It is unlikely that a single vendor offers a broad enough set of capabilities to support all lines of business for a CSP. Moreover, the existence of multiple vendors puts downward pressure on product pricing. This results in lower upfront costs. But if not approached with caution, that lower upfront pricing can be offset with high operational costs due to fragmentation and complexity. A multi-vendor stack is inherently associated with interworking, certification, and compliance challenges. A multi-vendor strategy, by definition, needs to put together (proprietary) interfaces from several vendors, each of which will bring its own NFVI with their VNFs/CNFs and potentially cloud OS layer. This introduces overhead and mandates integration work that needs to be done by a third party who may not have knowledge of the ecosystem.

For CSPs, evaluation of these two cloud strategies will need to be done in line with their market positioning, geographical location, and commercial growth strategy. With a single-vendor strategy, CSPs may run into integration challenges and incur costs if the selected vendor blocks, or reduces, cloud platform compatibility. This makes it challenging to work with other providers within the same cloud stack. But with a multi-vendor approach, agreement is required on service-level agreement (SLA) requirements and operating models that allow an integrated and end-to-end view of services and performance. Further, a multi-vendor cloud blurs the lines of which vendor is responsible for which network anomalies. Consequently, if there are no clear agreements in place, CSPs face the prospect of network outages with no clear mapping to a solution provider.

The commercial imperative for Ericsson, Huawei, Nokia, and ZTE is to focus on performance, user experience, and feature sets with interdependent architectures. These vendors enjoy a competitive advantage vis-à-vis competitors whose cloud architectures are modular. In contrast to modular architectures, the functionality that NEVs offer is robust and scalable. That is because the standardization inherent in modularity limits the degrees of design freedom for product engineers. Consequently, engineers cannot optimize for performance. But ultimately, the specifications for modular interfaces will coalesce as industry standards. For example, O-RAN specifications will eventually be adopted within 3GPP standards. That means that, in the long run, NEVs should strike a balance between interdependent architectures and modularity. Pure modularity and interdependence are two ends of a spectrum.

In contrast, the commercial imperative for software vendors is to focus on agility and breakthrough (disruptive) innovation as opposed to incremental innovation. They have cloud-native and software expertise. They introduce new products faster because they upgrade individual elements without having to redesign the entire stack. But in addition to technology, the likes of Affirmed Networks, Ciena, and Mavenir should guide the industry on how to institute new business models. After all, telecoms will not capture new revenue streams by reshaping existing business models into new growth opportunities. It is breakthrough innovation that is typically simpler, more convenient, and less expensive as it disrupts and redefines the trajectory of serving both CSPs and enterprises. This is where pure-play software vendors stand to play a key role.

Going forward, CSPs will succeed if they align cloud architecture strategy to competitive circumstances. The industry structure in the coming years will be horizontally stratified, not vertically integrated. With that said, it is the circumstances of product performance and the ability to create new waves of disruptive growth that drives the viability of cloud architecture. To that end, CSPs should keep working with NEVs, but also introduce ‘added value’ from software and cloud vendors. For example, Dish deploys 5G core on AWS, with Nokia providing the core network and Ciena providing end-to-end automation with its Blue Planet offering. This is where new use case innovation and business agility is a function of end-to-end ecosystem openness among multiple vendors. Equally important is interworking and interoperability between vendors’ integrated (interdependent) and non-integrated (modular) architectures. Most (telecom) cloud platforms will fall somewhere between these two extremes.