Probably the most dangerous thing a company can do in tight financial times is to chase buzzwords. Given that view, you won’t be surprised when I say that I was less than enthusiastic about the Great Telco Debate on the importance of being a “digital service provider”. I’ve never been wild about the term itself, perhaps because I remember when “digital service” meant T/E-carrier leased lines, and the fact that all services today are carried digitally. But rather than dig up ancient history, let me talk about what I think are the real issues the term raises.
According to the piece I referenced above, the attributes of a digital service provider are “flexible customer engagement, integrated operations and end-to-end automation”. It’s not that I dispute that these are important points, but that I think they take second place to a more critical way we could define what being a digital service provider should mean.
My beef with the attributes is simple; they make three important presumptions; that changes in the actual services being sold are not a requirement, that you need to engage customers better to sell your stuff, and you need to wring out all possible excess opex, because profit enhancement depends on cost reduction. The last two are necessary because of the first, which is why I emphasized that first point. The reason is that we’ve likely reached a point of diminishing returns on investment to reduce opex.
The integrated operations and end-to-end automation attributes, if they’re to reduce opex, have to reduce staff, and the primary problem with these two is that the majority of human-related opex was focused on outside plant, the “craft” piece of telco. There is little that remains in that area now, and the specific focus of the two attributes would be network operations, whose staff is a minimal piece of opex overall. There are benefits that might accrue from addressing these two cost factors, but frankly I doubt they’d be worth having a conference. Operators need to address profit per bit decisively, and I don’t think re-operationalizing existing services is the way to do it.
The right way would be to change the service set, and not just diddle with pricing models like “usage” versus “leased”. Experience has shown that if you offer a different way of pricing a service, users will adopt it if it lowers their cost overall. If that’s the only reason for adoption, then “success” in the offering would mean that operators suffered an overall revenue loss. Even the as-a-service model that I personally believe is the right way to target networks faces a challenge if you can’t define something new to be offered in as-a-service form. VPN as a service? Get real.
Here’s the thing. The network operator community wants to take root in the current service set and become trees. Give them a story that seems to promise they can do that and they’re all over it. Operators are facing a revolutionary problem and they want to address it with slow, orderly, comfortable, evolution, and that simply is not going to be effective.
What could actually link the three attributes for “digital service provider” to some rational model for operators? The best option and the easiest option are quite different, but both are illustrative and both are NaaS in some form. To me, “NaaS” would have to mean providing a form of logical addressing, and the difference between easy and optimal versions would be based on just how much work the user had to undertake to use the service.
The easy NaaS model would be one where the user could assign IP addresses to logical elements that could be hosted in various places, and the service would route the IP address to the current location of the element. This would mean that the user would have to tell the service that it had relocated an element, of course, and that would mean that there could be a lag between the instantiation of an element in a new location and the direction of network traffic there. The user, or software tools provided to the user, could take on the role of deploying and redirecting to simplify use. This mechanism would assume that an element was relocatable but that there could be only one instance of it.
A more complex example would be to allow the logical address to represent a community of elements 1:n in makeup. The NaaS service would be responsible for maintaining the instances associated with the community based on the user’s having provided a “community label” for an element and adding it to the community. Now, the service could employ one of multiple options for load-balancing among the community members.
The ultimate, perhaps, would be to frame NaaS as a “service mesh service”. In a service mesh, there’s a sidecar that service elements communicate through, and this sidecar element provides logical addressing and load balancing capability. The problem with current service mesh technologies (like Istio) is that they’re not highly integrated with the network and they don’t present themselves as a service. The challenge in a service mesh NaaS is figuring out what the service would look like. Since service mesh technology is really about message exchange within a component community, it would appear that you’d have to include a community-building function similar to the intermediate-level NaaS model above.
I think the NaaS evolution described here demonstrates a deeper truth as well. To be relevant, future services in general, and the “facilitating services” that I’ve blogged about and that AT&T has suggested it’s planning to deploy, have to be tied more to the cloud/edge hosting and message exchange model. There’s a tendency for operators to think only in terms of connectivity, and both the NaaS concept and the facilitating service concept mandate presenting something a bit more elevated, and thus a bit more useful in building retail experiences.
The challenge with all of this, and thus the challenge for operators who want to be true “digital service providers”, is that OTTs and cloud software providers and tools could “build down” to provide the same sort of thing. If we focus for a moment on facilitating services (presented, likely, as a NaaS), it’s pretty obvious that the stuff that’s being facilitated could build down as easily as the connection layer could build up. Kubernetes, for example, already has a virtual-network plugin/API. The service mesh concept in particular could be generalized, and we have a number of service mesh implementations already.
This is why I get frustrated by the determination of operators to take root in their comfort zones. There’s little comfort in eroding financials, and absent some strategy change that’s exactly what we can expect for operators worldwide.
