Everyone has an opinion on what telcos need to be doing (including me). At an event like MWC 2021, it’s not surprising that that question has been raised, and it’s similarly unsurprising that IBM’s CEO has used the bully pulpit of a keynote session to offer IBM’s answer. IBM is one of the vendors telcos have always favored as a technology partner, and IBM is now trying hard to gain traction in the telecom vertical, which means catching up with rivals in the cloud and in the software space. Those cloud rivals came to the fore with the announcement by AT&T that they would be expanding their cloud deal with Microsoft to include hosting parts of their 5G Core, and the two announcements combine to show there’s going to be a battle over the very nature of “carrier cloud”.
In the session, written up by SdxCentral, IBM CEO Arvind Krishna cited four tectonic shifts that are shaping the future of telco infrastructure; 5G (of course), edge (of course), hybrid cloud, and artificial intelligence (AI). The keynote made it clear, by Krishna’s comments on open technology, that Red Hat is leading the IBM charge for the telco vertical, and it also made an interesting point about the edge that’s a good starting point.
IBM says that it believes the edge to be an extension of the data center, but it’s not entirely clear whose data center is being extended. On the one hand, the comment seemed to be aimed at operators; “It’s critical to understand that telecom operators and carriers have enormous potential to harness the power of 5G and the edge, not just as a connectivity solution but as a business services platform.” On the other hand, it’s very possible that IBM’s reference to hybrid cloud as a tectonic force is an indication that it sees edge computing critically linked to premises hosting of real-time features that would then link with public cloud or public edge services.
It may be that IBM is balancing forces (and opportunities) here. On the one hand, obviously the operators are looking primarily at 5G hosting in the near term, and 5G Core in particular is a metro-hosting or cloud-hosting possibility. For 5G RAN, the operators may have significant equipment deployed in the form of discrete devices, so whatever they do there will have to influence the way the cloud/edge piece is managed. On the other hand, applications beyond 5G could well start specifically with the “edge” being on premises. In my blog on IoT opportunities, I noted that the early phase of “visionary” IoT was likely to be hosted by enterprises within their own facilities, evolving toward broader edge services at the metro layer as time passed.
Another significant point IBM made was that, after initially focusing on virtualizing key network functions, operators were shifting toward Linux, containers, Kubernetes, and so forth—all cloud-native elements. This seems to endorse the notion that NFV isn’t going to be the centerpiece of edge computing, or even of telecom feature/function virtualization overall, in the longer term. Obviously that’s my view, but I’m a bit surprised that IBM would take a strong position in that area. It suggests that they seeing the handwriting on the wall.
They also realize that cutting both capex and opex is critical for operators who want to improve profit per bit, so they’ve announced the IBM Cloud Pak for Network Automation, which is a toolkit to improve lifecycle management and achieve (or more likely approach) zero-touch automation. This is an enhancement to the previously announced IBM Cloud for Telecommunications, IBM’s root offering for the industry.
Not surprisingly, a theme that crosses back and forth through the whole keynote is the value of an open set of solutions. IBM recognizes that their real competitors in the telco space are the network equipment vendors, particularly those that offer specific 5G capabilities. 5G is the first network technology that was designed to be hosted, at least in part, and IBM knows that if a computer/software vendor is going to get a piece of the pie, they’re going to have to beat back those network vendors who traditionally supply infrastructure. Stressing the value of openness is a popular public position, but it also stakes out an IBM sales strategy—proprietary stuff will lead you down the garden path (again).
IBM is much more accommodating to the network vendors (like Juniper) who aren’t perceived as specific 5G threats, or threats to IBM’s vision of 5G at least. Juniper is a partner listed on IBM’s website, and Juniper’s Cloud Metro story is actually fairly symbiotic with IBM’s vision of both 5G hosting and edge computing in general. It’s unlikely after all that data-plane services for 5G will be hosted; white boxes or a separate IP network are the preferred approach according to providers.
For all the good stuff included in or referenced in the keynote, there are still some gaps that could upset IBM’s plans. The biggest is a lack of a clear picture of what the architecture of edge applications will be, something needed to frame the toolkit and help development teams build edge-native applications. There are some clear architectural issues at this point, and several are crucial enough to warrant discussion.
The first issue is the functional/serverless versus container issue. Functional computing is available from all the cloud providers, often called “serverless” because there is no specific hosting commitment to a given function. Everything is run-on-demand. That model makes sense where edge applications are made up of small units of logic that are run relatively rarely, but it would make no sense where there’s either larger functional units or more frequent executions. There’s also a question of whether function loading could create a crippling level of latency in the very applications that are running in the edge to avoid latency.
Containers are a kind of middle ground between functions and virtual machines. Good container design emphasizes more stateless, or at least no-internal-state, behavior because that improves scalability and resilience, but containers are designed to be persistent; they stay loaded when the application is running. That means that if the things the application handles are rare, the cost of container-based applications is unreasonably high.
The second issue is “latency scheduling”. If edge applications are latency-sensitive, then there’s likely a budget for latency that has to be met, and to meet that budget the hosting of application components has to consider the latency implications of the choices. Even Kubernetes experts are reluctant to say that Kubernetes can provide latency-based scheduling, in no small part because part of the latency is network-related, and Kubernetes doesn’t see network topology or delay. Since latency depends on the workflow and network relationships between components, just having the characteristics of a set of Kubernetes nodes doesn’t let you reliably predict the latency a given combination of hosting points might generate.
One way to address this is to assume “flat-fabric” connectivity, meaning that every hosting point in the edge is connected with a mesh of high-speed paths, and since it’s likely that “the edge” for a given application is entirely within a metro area, it’s possible to build a metro network so that there’s minimal difference in network latency among hosting choices. Possible, but whether it’s financially practical could be another matter.
If we could address these two points, we could probably frame a set of edge-native tools that would support development. Cloud providers can address the first of these points, but they don’t control metro networking or latency differences. Network operators could, in theory, address both points, and of course software providers could anticipate the question, but would have to rely on the organizations who deploy their software to actually control whether these points are fully addressed.
Let’s close by linking this to the AT&T deal with Microsoft. Many 5G operators are looking at public cloud hosting outside the areas where they have real estate, meaning out of their home region. As I hinted in the opening, this deal establishes that public cloud providers are going to take a serious run at owning 5G hosting, perhaps completely. IBM certainly sees that, and that’s likely why they make a point of saying that their own 5G and telco solution can be run on any cloud. What IBM is doing is laying out its own key differentiating point, which is that if operators were to sign on to the IBM strategy, they wouldn’t be locked into a specific cloud provider, or indeed any provider at all. The “carrier cloud” self-hosting option for operators would still be on the table.
Microsoft is also acquiring AT&T technology and intellectual property relating to 5G, which gives Microsoft more ammunition in going after the telco space. In fact, this piece of the deal may be the strongest indicator that Microsoft is going to offer 5G-as-a-service and focus on that complete solution. That puts it in conflict with IBM’s “any cloud” theme, and with software providers who want to offer 5G without specific cloud ties.
All of this represents a victory for open-model 5G, however it falls out, and it’s also in a way a victory for the legacy IP vendors, notably Cisco and Juniper. If the 5G control-plane features are going to be cloud-hosted, then it is possible that the competitive landscape in the IP network won’t be changed much by 5G introduction. The metro area is both the focus of 5G functionality and the key opportunity in the router space. In theory, disaggregated router vendors might have posed a significant threat by incorporating 5G features into their separated control planes and then going after metro. It may now be too late for that to have much impact on the market.
The “however” to this part is that AT&T has already committed to open technology in the 5G access space and to disaggregated white-box routing in its core. If the Microsoft deal takes some immediate pressure off legacy router vendors in the metro space, it doesn’t mean that AT&T won’t eventually insist on white-box metro. Cisco and Juniper will have to use the breathing spell they get here to do something not just useful but compelling.