Analyzing the Telecom TV Take on Cloud-Native

Industry events are good, providing you can time-shift to watch them.  That’s particularly true for analysts, because drinking bathwater is not an attractive image, whether it’s your own or not.  The term could be said to apply to any number of things that create a kind of intellectual recycling, a belief set that builds on itself rather than on outside needs and opportunities.  Like all market pundits, I try to avoid it, and one way to do that without becoming a conference gadfly is to watch replays of events.

TelecomTV had a nice series on a topic dear to my heart, cloud-native and telco cloud, and I want to review what I think it meant.  As always, I’m putting my own stamp on this, hopefully to explain, add perspective, and sometimes disagree.  Tomorrow’s blog will look at another conference series, this one on 5G and open-source, sponsored by the ONF.

The thing that seemed to cross all the sessions, in my own view, was that there’s still a lot of haze surrounding the notion of “cloud-native”.  There are some who think that it means something designed to be hosted, period.  Some think that it’s about reorganizing things a bit to allow the telcos to create a kind of hybrid-/multi-cloud framework of their own, much like other verticals.  Some think it’s about adopting cloud-like development practices and tools, like continuous integration and delivery (CI/CD).  Finally, of course, some think it’s what it really is, which is the disaggregation of functions and applications into microservices to build new models of old things.

Perhaps the most important thing about the conference videos is that each demonstrates that there are people who see cloud-native as it is in just about every organization.  Some of the speakers commented that they had real cloud-native dialogs with every operator they talked with, which would certainly be a good sign.  Since I know that I at least have had conversations with every operator that proved cloud-native wasn’t the universal language there, this shows that a lot of your cloud-native discussion will depend on who you happen to be talking with.

Another thread that cut across sessions is that operators recognize that they are not really cloud-qualified.  Not only are they fairly sure they don’t know how to build their own carrier cloud, they’re not entirely sure they know how to consume someone else’s cloud effectively.  My sense, from the comments, is that most of the operators don’t think this is going to be an easy problem to solve, either.  Since the fact that operators participated meaningfully in all the sections proves that some people in the operator space do get it (and refer again to my last paragraph here), the problem is obviously breadth of knowledge.  Network people, to paraphrase one operator, don’t do cloud.

What’s perhaps the most important “technical” point from the conference is that 5G is very likely the big driver of cloud-native awareness among operators.  The fact that 5G separates the control plane and the user plane was cited often, probably at least once in every session where cloud-native drivers were brought up.  Sadly, this good news is dampened by the fact that the comment was often accompanied by two points I think are at least sub-optimal, if not wrong.

The first point is that 5G “requires” cloud-native.  It doesn’t, it requires (meaning specifies) NFV, which is itself struggling toward cloud-native understanding.  5G is surely an opportunity to introduce and leverage cloud-native development, but it’s still a decision that operators and vendors will have to make explicitly, and so far, I’d say that most are not making it.  If 5G is truly a big driver for cloud-native, then it may be getting wasted as we speak.

The second point is that “control plane” is one of those highly ambiguous terms.  The term usually seems to mean what used to be called “signaling”, the process of controlling communication and facilities, rather than the channel that passed information end-to-end.  What makes this definition a risk in the 5G context is that 5G networks run on IP, which has its own “control plane”.  The 5G User Plane, then, consists of the IP control plane and the IP data plane (or forwarding plane).  Since we have a lot of discussions about separating the control plane in IP networks, it’s easy to see how people might think that 5G mandates that.  It does, but only with its own signaling, which is a higher layer than that of the IP control plane.

What 5G does, most explicitly, is to separate its own control and user planes.  That creates two incentives, one implicit and one explicit, for IP networks to do the same.

The first incentive is that if 5G Core represents the state of the art in operator thinking, then it’s a powerful architectural reference for other services.  That doesn’t just mean new or old services, but both.  We should expect to see control/user separation across the board, because it’s what operators think is the right approach.

The explicit incentive is that 5G Core presents interfaces (N1, N2, and N4) between the control and user planes.  If the user plane is IP, then you can argue that an IP network should be able to support these interfaces, meaning that the AMF/SMF (access and mobility management and session management) elements could rightfully be seen as network services built on those interfaces.  If we assume that the IP network has an independent, cloud-hosted, IP control plane, then the Nx interfaces are essentially APIs that invoke network service features.  This sure sounds like network-as-a-service, and it would represent a model of represent how other services, old and new, interface with the IP network.

The reason this matters for cloud-native wasn’t really brought out in the conference, but I’ll suggest one.  The higher you go in terms of service layers, from connectivity up to applications and experiences, the more cloud-like your architecture had better be, to conform to application trends.  If the Nx interfaces are the boundary between “legacy” connection services and “over-the-top” services, then they represent the place where cloud behavior starts to make sense.  That argues for considering the IP control plane and the 5G (or other service) control plane as sublayers, with a common and cloud-native implementation.

Vendors in the sessions were more likely to see cloud-native in its real, and realistic, form than the operators.  One vendor even talked about state control, which is critical for cloud-native but something most don’t understand at all.  But even the vendors had the view that 5G Core was written to be cloud-native, and I don’t see anything in the specs that admit to that interpretation.

Another area where vendors had a distinctive (and understandable) combined view was that operators really needed to have their own cloud, eventually.  Most operators also seemed to agree with this, but it seems like the cloud software vendors are recognizing that public cloud hosting of “carrier cloud” applications could tap off a lot of their opportunity, and they’re particularly sensitive to the loss of the “edge” opportunity.

If you were to dissect my forecast of carrier cloud data center opportunity, over 70% of the data centers would be expected to deploy at the edge, largely in central offices and mobile backhaul concentration points.  Given that, and given that the software vendors would face a significant opportunity loss were the operators to outsource their edge requirements to public cloud providers, all the software vendors saw evolution of carrier cloud as starting with 5G and quickly becoming edge-centric.  They also saw the biggest public cloud outsource opportunities in the operators’ administration and operations systems, not in hosting network features or functions.

Cloud-native is here, providing that we’re willing to accept a rather loosey-goosey definition of what “cloud-native” is.  I’m grateful for TelecomTV for running these kinds of events, and making the material available online afterward.  It gives us all a stylized but still grounded view of what the operators and vendors most committed to changing things are doing and thinking.  We’re not there yet, not in the transformed future, but we can see it through the weeds now, and that’s progress enough to applaud.