Month: June 2019

With the exception of Cisco, none of the network equipment vendors can market themselves out of a paper bag.  Juniper, perhaps, is even a bit worse than average.  Their positioning of their Mist acquisition has been murky, but they’re apparently working to refine it now.  The question is whether there is a real value proposition for an “AI edge”, and if so whether Juniper is actually moving toward realizing it.

SDxCentral wrote the latest Juniper move, “Mist Edge” up HERE.  In effect, what Juniper is doing is extracting AI from the wireless management application Mist originally promoted, and moving it onto an appliance.  This has the benefit of improving wireless management by reducing latency, but Juniper also says this will let enterprises rev up a distributed-microservice architecture on premises without having to move to the cloud.  But is this really a useful AI-edge concept?  To find out, we first have to look at the overall utility of an AI edge.

Intelligence is about drawing inferences from information, and so an AI function should do that.  Since “information” into the network (as opposed to about the network, meaning network events) is the source of our inferences, it’s logical to presume that having AI close to the point where information enters would be helpful.  Logical, of course, is often a bit of an oversimplification.

Drawing inferences is usually followed by acting on them.  If you make an inference close to the information source, then send the inference a couple thousand miles to act on it, there’s not much lost if you move the inferring task to where the action is.  The value of AI at the edge, then, is linked to the value of pushing control responses close to the edge, which is related to the need for managing latency in the control loop.

An edge appliance is very different from an edge server.  There are software design patterns and middleware that let a “server” be a virtual element that fronts an entire data center or even a collection of data centers.  An appliance is by nature a more locally focused element.  If you had a cloud mission, you’d expect to deploy a cloud.  If you have an appliance mission, you’d expect it to be more local.  Yes, there could be a cloud architecture behind it, and this is true with Mist Edge because it’s a local instance of a cloud management function, but if the management function was in the cloud to start with and was then pushed out to an edge appliance, you’d have to presume that the reason was that there was local stuff to do.

What this means for an edge appliance concept is that it’s not “cloud equivalent”.  There are limits to how much processing you can do in an appliance, so there’s a limit to how sophisticated a set of actions you could host to respond to your AI inferences.  There are also limits to what Mist Edge might be able to do in terms of inferring stuff from various inputs; the material on that isn’t published yet and suggests that there’s still work being done there.  That limits what we can infer about Mist Edge’s inference value, but we can lay out some rough issues.

With source information that fits fairly well within the parameters of WiFi 6 management, there’s little question that Mist Edge could do the job.  That would be true for WiFi (obviously) but likely true for 5G-related cell-site management, and it could also be true for content delivery networking.  All of these things could use AI based on conditions recognized and actioned locally without a whole lot of heavy lifting.

What falls outside that range of applications is more problematic, in part because we don’t know exactly where Juniper will take their Mist Edge concept and in part because the value of AI and the value of event-driven applications are both fuzzy when you consider the broad market—like IoT.  There’s a good chance that you could fit Mist Edge into at least some IoT applications, but the problem is that Juniper so far is focusing (at least in their discussions with the media) the Mist Edge on the enterprise.  Operators do 5G and operators are probably the best target for a Mist-Edge-like concept for IoT as well.

I’ve said in many past blogs that open sensors on the Internet are a loser in a business-case sense.  The best way to exploit IoT sensors would be for someone to add an inference layer to them, both to digest raw sensor data to make it more useful and to protect sensors from hacking, spoofing, etc.  Operators might use an appliance to make basic, local, inferences that would then be sold as services to OTTs or exploited by their own higher-level applications.

The big question here is what tools Juniper/Mist might be adding to the arsenal, and that’s hard to say.  The Mist website talks about a “cloud architecture with microservices”, but the details on the site are all related to WiFi management:  “The world is going cloud…Now wireless can too.”  It’s probable that there’s an underlying architectural model behind any WiFi-specific features, but that architectural model isn’t presented in enough detail to evaluate.

There could be value to this concept, make no mistake.  The value, I think, will depend on whether Juniper can push the details of the Mist Edge AI capabilities to areas not specific to WiFi, and perhaps not even specific to enterprises.  It could then represent a truly, broadly, useful step for Juniper.  Or it could be nothing more than AI-washing if Juniper can’t collateralize the details.  I think it was a mistake for Juniper to push out the notion of a Mist Edge without creating and validating a broader mission than WiFi optimization.  If they weren’t prepared to describe what utility they were aiming to achieve and how they were intending to realize it, they should have waited.  It’s hard to relaunch something these days, and there could be real value here that’s at risk to being missed.

One of the many concepts the cloud has brought us is the “single source of truth”, the idea behind the repository-centric operations vision called “GitOps”.  Some vendors, like Ciena, have recently been promoting a transformation model based on collecting data from operations systems and management systems into a repository.  This raises the question of whether GitOps-like modeling would truly be transformational to operators, or even be a step in the right direction.  To answer that, we have to lay out the challenge of transformation in operator-data terms.

In the beginning, there was manual operations.  The old-line telco model of the ‘70s and ‘80s was based on craft personnel (technical workers) doing stuff that created services.  The operations systems of the time, “operations support systems” or OSS and “business support systems” (BSS) were primarily recording manual steps after the fact, or generating work orders.  In a very real sense, they reflected the old-time batch processing mindset of IT, rooted in punched cards to capture transactions or commercial paper that was processed by humans, not systems.

As network devices became intelligent, which happened largely through architected voice and data service features that were finally rooted in routing and IP, the management of these network devices started to take humans out of many of the service creation tasks.  This created a “network management system”, and it raised what turned out to be a critical question—the relationship between NMSs and OSS/BSS.  The critical nature of that question was not recognized, and we ended up creating a link between OSS/BSS and NMS that mirrored the old craft-management model of fulfillment.  Instead of journaling human activity, we had OSS/BSS journaling NMS activity.  We still do today, as all the diagrams that show OSS/BSS as a box that’s “upstream” from the NMS, and separate.

Recognition that this was the wrong approach came along with the new millennium, when the Telemanagement Forum (TMF) released its Shared Information and Data model, or SID.  SID represented a truly revolutionary step in telco GitOps, before Git came along.  The essence of SID is that a single model defines the data necessary to describe a “service”.  I put the term in quotes because from the very first, the TMF adopted nomenclature inconsistent with the rest of the industry, so they call the orderable entity a “product”.  Whatever the name, the SID defined a repository, and as it evolved it came to include the notion of a service as a hierarchical structure of elements, each of which had an appearance that faced the customer (Customer-Facing Service or CSF) and another that faced resources (Resource-Facing Service or RFS).

Over the next decade, the TMF enhanced the SID-centric view with various features, most notably the “NGOSS Contract” which said that the service data model (the SID) provided the binding between service events and operations processes.  That created a model of an event-driven OSS/BSS that would be naturally integrated (by the fact that network and service events were both events) with NMS.  However, there were few complete implementations of the SID, and virtually none of NGOSS Contract.

This is important for two reasons.  First, we have had, courtesy of the TMF, the right repository concept for OSS/BSS/NMS for almost two decades.  There’s nothing new about gathering information in one place.  Second, given that we’ve had the SID for the career lifetimes of many in the industry and have not effectively exploited it, there are obviously barriers that need to be crossed.  That would be just as true for a new approach as the TMF approach.

Let me make it clear that I don’t think that the SID is an ideal model.  We have modern modeling approaches (like the OASIS TOSCA specification) that I believe are far better at addressing how we now view complex services, especially ones involving hosted elements.  The thing is, TOSCA has also been around for a while (having been approved in 2014) and it’s not set the world on fire, adoption-wise, either.  I think the barriers to a GitOps-like approach for operators lie beyond pure model technology.

Problem number one is the TMF’s approach to things.  They’re an organization with dues, officers, and biases toward sustaining their own business model.  They developed terminology that’s unique to them, and they provide most of their information only to dues-paying members.  You need to join and absorb their whole complex picture to understand their approach, and that tends to keep the TMF a kind of micro-culture, a secret society.  They’re not alone in this; I think you could make the same statement about most of the industry groups we have.  The problem is that it makes it hard to socialize the TMF vision to the outside-the-TMF world.

The second problem is that operators have long divided their organizations in a way that separates OSS/BSS (under the CIO in most cases) and network operations (under the chief operations officer).  The two groups have had a hands-off relationship for all the old-craft-support-model reasons I’ve already noted.  To integrate both network and service operations around a common model would imply integrating operations overall, meaning merging/eliminating some groups and perhaps jobs.  Finding political support for that is obviously not a trivial task.

The third problem is that management in the telco world knows “software” mostly in the telco context.  They’re not cloud people, not microservice people, at the senior level.  Even if they hire totally state-of-the-art people at the lower layers, those people are buffered from decisions by layers of people who literally don’t know what their juniors are talking about.

The final problem is that the impetus for the harmonization of everything around a model, the telco GitOps, is service lifecycle automation.  This is a massive initiative, one that telcos are ill-equipped to handle on their own, and that telco-centric vendors are afraid to push because it lengthens sales cycles and perhaps threatens the jobs of their prospective buyers to boot.

If transformation means transforming all operations practices around the “telco GitOps”, whatever the specific model technology used, then these four problems will have to be addressed.  The good news, I think, is that there is a convergence of modeling and tools between what the cloud is doing and what the telcos need done.  It would be better if the telcos would acknowledge that their needs are just applications of generalized tools designed for the world of virtual computing and networking, but eventually the cloud people will end up with something close to a right answer.  “Close” here, meaning close enough that visionary telco types can grasp the connection.

ETSI could have fixed this, both in the NFV group and the zero-touch automation initiative.  The TMF, obviously, could fix it too.  Neither have fixed it so far, and that’s why I think we have to forget the bland discussions about transformation and recognize that until we advance the cloud tools for virtual-lifecycle-management overall, to the point where telcos can recognize what’s there, we won’t move an inch.  A body or even company with the right mission and approach could hasten that happy insight convergence, but it’s realization that’s needed here, not just technology.

As I said yesterday in my blog about the application of cloud federation to operators, I think the cloud is going to provide the answers here.  The problem for operators is that they may not provide it in time.  We had, at one point, an addressable benefit case for service lifecycle automation equal to almost two-thirds of the total capex budget of operators.  That’s an enormous asset in terms of improving profit per bit.  The problem today is that tactical one-off improvements to operations in some areas have reduced the addressable benefits by about half, which means that it will now be much harder to justify lifecycle automation based on profit per bit.  Today, it’s probably tied to either significant substitution of hosted features for physical devices, or to climbing the value chain to more OTT-like services.  Business cases for both can be made, but with greater difficulty.  It would be smart for operators to start working with cloud players on how to advance “GitOps” and lifecycle automation overall.

I want to take up federation again, extending the federation approach of Google’s Anthos to the service provider space, where federation is surely needed.  I’ve said many times that the cloud initiatives we’re seeing are addressing many of the things that operator standards for advanced services and hosted features should have addressed.  The question now is whether Anthos-like federation is an example of that; whether Anthos could be an indicator that the cloud is going to address one of the critical issues that operator standards groups have failed to cover fully.

My first experience with operator-centric network federation in a formal sense came on the IPsphere project a decade ago.  IPsphere defined a hierarchy of service-as-a-set-of-elements.  Services were essentially a commercial envelope and a unifier of the relationship of the elements within.  Elements could be provided by the service owner, or they could be outsourced to others—presumably operators in IPsphere terms.  Thus, services required federation as a standard feature.

The presumption inherent in IPsphere was that each “Element provider” was an autonomous entity who was unwilling to expose the details of their infrastructure to others.  An Element was a set of properties that could be relied upon, from the perspective of the Service, and a recipe for fulfilling those properties to the Element provider.  The Element ran in the Element provider’s infrastructure and delivered what it promised, exposing status information and interfaces as described.  In virtually all cases, the Element had to be connected in some way with the data plane of the Service owner, and perhaps other Element owners too, to create a cohesive service.  This is the framework I proposed in my ExperiaSphere project.

This structure is not unlike that which Anthos describes.  Each Kubernetes domain in Anthos is autonomous, and there are gateways (implicit or explicit) that provide data plane linkage among the domains.  There’s also a set of properties, in the form of high-level policies, that define how everything is supposed to work at the collective level.  These feed the domain-specific policies, and vice versa, so the general notion of policies rather than scripts links the collective level and the domain levels.

Sometimes you can go astray by staying up in the stratosphere.  The basic model of domains linked with policies and gateways seems appropriate for the kind of federated relationship of autonomous providers that IPsphere envisioned, but while a 50-thousand-foot architecture diagram of the two approaches would look similar, the details are quite different, and those differences are what we need to look at in more detail.

Anthos is about application deployment.  IPsphere, and most network operator federation needs, are service-related.  Anthos lets you connect the pieces of a distributed application, and if we draw the obvious analogy that application components are the same as hosted service features, then Anthos is really about a form of federation that operators (in the IPsphere work) had dismissed.  They didn’t want to expose their infrastructure for others to deploy on, which is what Anthos federation would enable.  They want to have each operator deploy on their own infrastructure, and expose the functional result of that deployment.  Don’t host on me, cooperate with me at the service level.

If we look at this point carefully, we can see that operator-centric federation, or service federation, is actually a layer above Anthos.  You can’t address it with general hosting tools, you have to first assign application/service functional missions to domains, and then advertise those missions on the outside while fulfilling them on the inside.  A VPN could be federated as a service, but if you wanted to do one using Anthos, you’d first have to assign roles in the service to the federated partners, describe those roles in our inside/outside feature/recipe form and then use Anthos to fulfill the recipes by deploying components.

Could you build a service like a VPN that way?  In the present form of Anthos, probably not.  Anthos is about a tenth as fast as native component interconnection, due to the latency that the service mesh and its associated features introduces.  That’s too much of a performance hit to be incorporated into a data-plane network connection service.  You could use Anthos and service meshes for control-plane stuff (within IMS/EPC, for example) but probably not for the data plane.  At least, not until we work through some of the performance issues, which is almost surely going to happen with Anthos, and with service mesh technology in general.

The opposite question is also interesting.  Could Anthos find another layer useful?  An application is like a service.  Could some new application-layer piece be introduced that would be able to decompose functional needs into domain assignments, then use Anthos to deploy the pieces of the application according to that functional assignment map?

Anthos’ main components are Kubernetes and Istio, for container orchestration and service mesh, respectively.  Both are no walk in the park to learn and use.  Could we make them easier to use with a layer above?  Could introducing some service-federation thinking into the cloud benefit the cloud, and so become an outcome we could actually hope for?  I think that’s possible.

Anthos takes a stab, via policy coordination, at managing the collective resource pool, but that’s done at the level of hosting and discovery of microservices, not at the function-to-domain assignment level.  That means that users have to decide where stuff belongs, if that decision is based not on simple metrics like available resources or cost, but on application and user requirements.  Another higher-level dimension that could map an application across multiple hosting domains (multiple public clouds and the data center or data centers) would surely help users.

This might even be the way to get artificial intelligence into the game.  Functional or user-level assignment like this requires balancing a lot of variables, including the performance impact of where you put something, the regulatory implications of having your service pieces in a specific place, and of course cost and performance.  Then there’s the differences in the tools and features available in all the possible domains to consider.  It’s a complex problem of the kind AI would be perfect for.

And (no surprise) there’s more.  If we had this kind of AI-driven higher-level element that mapped function to deployment, why couldn’t it feed the policies of the Anthos layer?  How much of the complexity of container deployment and management could be erased by having something that mapped goals and intent to deployment and connection?  A lot, I suspect.

What this all shows, in my view, is first that what operators think of as “federation” is a higher layer than Kubernetes/Anthos federation, and second that the software for that higher layer isn’t unique to the network operator application of service federation.  The higher layer’s general solution is AI-based coupling of application/user goals and intent to deployment and connection policies.  That means that the cloud community will likely get there as they move to make Kubernetes, Istio, and Anthos more accessible and useful.  So, if operators want input into the only processes likely to actually advance their own needs, they’ll need to hustle.

Google has been in a fight for third place in public cloud, and a distant third at that.  For some time, many (myself included) have wondered how Google would gain market share, beating IBM for third and even closing in on the leaders.  Now we may see the first clear signals of their overall strategy.

The problem Google had was that the public cloud market is divided into two segments.  The first, the “startup community”, targets social media and content startups who need to be able to scale out quickly without investing a ton of VC money in their own data centers.  The second is the enterprise space, who are not interested in “migrating to the cloud” in general, but in using the cloud to add agile pieces to current applications.  Amazon has locked the first segment and Microsoft the second, and IBM’s deal for Red Hat makes them a contender for that space too.

Google is the biggest OTT, and so it’s hard to get social media and content startups to commit to Google cloud, given that Google is probably already competing with them and is likely to start competing if they’re not.  That leaves the enterprise space, and Google has no enterprise products or tools to leverage, as Microsoft does.  However, nobody really has pride of place in “hybrid cloud”, the combination of public cloud and enterprise data center that’s the current battleground for cloud providers.  There’s a window for Google to jump in, if they can be decisive, before Amazon or Microsoft lock the space up.

Their answer is Anthos, a hybrid model of Kubernetes that’s designed to create a “universal” framework for deployment and management of containers across virtually anything and everything.  Yes, that includes other public clouds, and that’s an important piece of what I believe Google’s strategy to be.

Anthos is essentially a federation model, meaning that rather than establishing a single container platform that spans multiple infrastructure options (as the combination of Apache Mesos and DC/OS does), each environment has, or can have, its own container platform.  These are federated via Anthos tools to create unified deployment and management, as seen from the top where management, monitoring, and operations controls are applied.

Federation is a high-level relationship among autonomous elements, and the key to making it effective is a pair of concepts—unification and subduction.  You need to unify the domains in terms of capabilities at the minimum, and at the tools level if possible.  That simplifies treating them as a continuum, meaning connecting them so that information and components pass among them and that performance is harmonized across everything.  You then need to subduct them at the policy and management level, creating an overarching set of rules that govern the domains and manage their interconnection with each other.

Anthos is based on three Google-initiated open-source pieces.  The first is Kubernetes, which hardly needs an introduction.  It’s the container orchestration tool that Google developed and that has literally revolutionized application development and deployment thinking.  The second is Istio, a service mesh technology that’s designed to make components/services/microservices accessible in any environment.  Istio is quickly gaining traction in the industry.  The third is Knative, a Kubernetes-hosted serverless framework that’s portable to wherever Kubernetes can run.

A user of Google Kubernetes Service (GKS) can add in a “local” or data center Kubernetes domain, including Istio and Knative, and then use a cloud and monitoring connector to link the domains.  If you don’t have a Kubernetes domain to add, you can use the Migrate tool to convert VMs to containers and then link them with GKS as before.  If you have VMs hosted on another cloud, you can migrate them the same way.  It’s not yet clear whether managed Kubernetes services on other providers are/will be supported, but users who hosted their own Kubernetes on VMs in other clouds should have no problem with migration.

The user benefit of this federated approach is that you can secure a highly harmonious operations platform for applications across hybrid/multi-cloud deployments without doing anything revolutionary to your current applications.  It should be possible to cloudburst from the data center to the cloud, even to multi-cloud, and even in theory to redeploy between cloud providers, though the examples of this aren’t fully developed or clear, so be sure to ask Google if that’s your plan.

Google’s benefit?  This is a way of creating a true multi-cloud that accentuates hybridization with the data center but at the same time absorbs other (largely competing) cloud commitments, which users admit are in their early stages today.  By embracing what enterprises have already done, Google gets a position in hybrid cloud evolution.  That they’re basing all this on open-source means that, in combination with their support for competing clouds, they’re not locking users into a single strategy.

Equipment vendors are also major Google targets with this initiative.  Hybrid cloud is the only model of IT that preserves investment in the data center, which surely is a big issue to the players who sell servers and platform software.   Google has trotted out references from nearly all the major players, and is actively working to promote their participation in the creation of federated IT communities.

The market itself benefits from this move, because anyone who’s tried to adopt modern software componentization principles (microservices, functional computing, serverless, etc.) knows that while containers are becoming a necessary condition for success, they’re not a sufficient condition.  The Kubernetes ecosystem, something I’ve blogged about before, is more valuable than Kubernetes alone, but most users aren’t clear just what’s supposed to be inside it.  Google is laying out an architecture for agile, distributable, applications that includes enough elements to fulfill basic development and operations requirements.  Kubernetes plus Istio plus Knative equals ecosystem.  Just knowing all that is helpful.

Is it enough to get Google over the top?  The biggest problem with Anthos is its biggest benefit—openness and inclusiveness.  You can’t easily differentiate your solutions using tools that everyone can copy, and if you leave your competitors in place to facilitate migrating to your own services, you leave those competitors a position to exploit in trying to migrate users away from you and back to them.

What Google needs to do here is to develop some clear differentiators, things that they can offer that others have a problem duplicating.  They also need to do more work socializing the application development and deployment implications of the Kubernetes ecosystem they’ve defined, so that enterprises will build applications that take full advantage of it.  With that combination they can brand the ecosystem with a decisive Google stamp, something that would force competitors to either acknowledge Google’s leadership in the space or try to roll their own approach.  It will be a challenge, but it can be done.

Computing is being revolutionized by the cloud, whether it’s actually in the cloud or in the data center.  In fact, the line between the two is blurring in a number of novel ways that might give us some insight into how applications, data centers, and IT will look in five or ten years.  Not surprisingly, the changes are being driven by a combination of new technology and the overall industry competitive dynamic.

An example of the latter point is THIS article in SDxCentral about HPE’s initiatives, described at HPE’s Discover event in Las Vegas this year.  Built around its previously announced “Greenlake” initiative, HPE is crafting a framework to deliver “everything” in as-a-service form.  What this really means is shifting from relying on a pure capital purchase model (which will still be available for most traditional IT purchases) to offering a pay-as-you-go/use subscription or aaS model.

If you want to understand the principle behind the move, you need look no further than Adobe, whose revenue and profit surprise has its shares up by over 5% this morning.  Most of the gains, say the company, are from its subscription model.  Adobe, like most software companies, have been shifting to a model where they sell software on an annual subscription, which provides users with continuous updates and improvements.  Most important, it provides the company with continuous new revenue.

The subscription approach deals with a problem that, decades ago, killed Novell, the leader in the enterprise WAN and resource-sharing software.  Netware, at the time, was the gold standard for file and printer sharing in offices, but the problem was that when you had a version of Netware that did what you wanted, it was harder and harder to offer features that would induce you to upgrade and generate more revenue.  It was also easier and easier for competitors to offer “basic” capabilities, or to simply build the resource-sharing stuff into their products as an additional feature.

For the last decade, the whole IT space has been moving toward the “Novell problem”.  For decades, the whole of the IT industry has been focused on bringing computing to more and more applications.  During this period, companies had both a “modernization budget” to sustain their existing IT framework and a “project budget” for each incremental improvement to operations.  New benefits justified the latter, and when the projects were complete, the infrastructure was added to the modernization pool.  Other projects took their place.

Up to about a decade ago.  Then, we saw nearly all the low-hanging and even mid-level operations opportunities realized.  The ratio of project to modernization shifted, and even modernization became more “sustaining” than progressing.  Everything was about technologies to reduce cost, which of course means reducing the revenues of the IT vendors.  One obvious approach to holding revenues up is to shift more to that subscription model, to get annual payments so users can’t hunker down on infrastructure investment until it rusts into dust.

Subscription is a great idea, then?  Well, look again to the software space and you’ll see the downside of subscription.  Two of them, the same two we mentioned regarding Novell, in fact.  Feature starvation and competition.

Subscriptions are valuable to the user when there are meaningful updates to be made, and where users consider it “likely” or “justified” to get the new versions.  As the number of truly meaningful updates declines, users start to resent the subscription costs because they perceive themselves has having the same capabilities (the stuff they actually use) for a recurring cost.  They get antsy, and they’re particularly interested in a change of vendor if the vendor announces a price increase.  Which, if the total addressable market is largely saturated, is the only way that additional revenues can be raised in a subscription model.

When buyers get antsy, competitors get opportunistic.  Adobe’s competitors have split between adopting their own subscription model as an option or requirement (Cyberlink offers both models, and Corel is moving with at least its flagship product to subscription-only), or positioning against the Adobe pricing model by saying they have a perpetual license.

There’s a buyer-side progression at work here, one that everyone considering subscriptions or as-a-service has to consider.  When new stuff creates new and clear benefits, people will stay up-to-date and spend regularly because it benefits them.  As the benefits become less clear, something like a subscription or as-a-service approach will tip some over into continued regular payments for a time.  Eventually, though, nobody will pay for what they don’t think they need, and somebody will offer them what they really want.

Does this mean that HPE’s move isn’t going to work?  Yes, eventually, but it could also be a very valuable tool in buying time.  We are in the midst of a computing revolution created by the Internet, virtualization, and cloud computing.  We’re in the midst of a revolution in IT engagement with cloud services sold directly to line departments and low-code/no-code tools to let any reasonably capable worker do at least light programming.  It’s very hard to say where these revolutions will lead us, and thus there’s a big benefit to being able to tie yourself over the transition period with a subscription or as-a-service play.

But a transitional strategy eventually depends on something to transition to.  What is the end-game here?  Clearly a new form of IT, clearly something based more on modern application and hosting models.  How does this new IT work, what do you need to use it to open new areas of IT application and reap new project benefits that justify incremental spending?  Those are the questions that vendors like HPE need to answer in the long term, and they’re not easy to answer.  Which is why vendors need to be working on the answers now.

Are they?  We don’t know for sure.  I think that some vendors, such as IBM/Red Hat and Dell/VMware, actually see the future in enough detail to be creating the ecosystem that’s needed to support it.  These vendors are already cautiously positioning for the future.  I think what’s new about the HPE announcements is less the as-a-service as it is the recognition of a new IT model.  Here’s the relevant quote:

“Companies today have a tremendous opportunity to embrace digital transformation in order to create new and compelling customer experiences, differentiate their business, and grow revenue. In order to do so, organizations demand a consistent cloud experience for managing all their apps and workloads, the ability to innovate at high velocity, and the freedom to choose the combination of technologies that best meet their needs. Unfortunately, the current paradigm for enterprise technology underserves the market – customers are forced to accept an inconsistent experience between the data center and the cloud; inflexible, expensive, and proprietary stacks that prohibit choice; and limited in-house IT skills, budgets, and options for financing.”

This isn’t a ringing call for a totally new IT model, but it’s a step toward justifying one.  IT vendors, like most vendors, recognize that too much revolution doesn’t sell.  You have to creep up on change, get buyers disconnected from the comfortable past and then get them to face not the ultimate future but a future that’s not too frightening.  This is what all the IT vendors are now doing, and it’s a transformation of positioning that’s going to lead to more interesting announcements later this year, and beyond.

Services based on physical connectivity, like IP services today, seem to be hitting a profit wall.  As I’ve pointed out in other blogs, we’re seeing operators under pressure to cut costs because customer willingness to pay for more bandwidth isn’t particularly high.  There are surveys that suggest that plenty of users would like 100Mbps, or a gig, or more of both mobile and wireline capacity.  Data on current services, though, shows that users don’t cluster at the high end of speed options.  That suggests that they don’t really find even current maximum bandwidth all that cost-effective.  For free, people take what they can get.  For pay, it’s a different story.

The challenge this poses for operators and OTTs alike is that bandwidth is the key to increased profit for both groups.  You need to sell something more if you expect to get more revenue, and capacity seems the logical thing for operators to look at.  If you’re an OTT, you need bandwidth to carry new and improved services that can earn you more.  The combination means that operators do need to be willing to modernize and improve both wireless and wireline networks, but to do that they have to sustain an ROI on infrastructure that’s at least as high as their current average internal rate of return.  Revenue per bit hasn’t met that objective, which is why cost management has been such a recent focus.  However, cost reduction strategies vanish to a point; you can’t reduce costs to a negative level.  Revenue is needed.

There are two ways operators have looked at new revenue.  One is to add connectivity features that are valuable enough to pay for, and the other is to rise up the food chain to become more OTT-like, meaning features aimed more at delivering experiences than at connecting things.  There are problems/challenges with both.

Connectivity features are things like add-on higher-layer security elements, virtual networking, bandwidth on demand, and other things that relate to making connectivity better or cheaper.  The biggest problem with these features is that they have little value to consumers and their value to enterprises is more problematic than it might seem.  We’ve had story after story, claim after claim, on things like bandwidth on demand, and it’s never really gone anywhere.  One reason is that it’s hard to differentiate connection services—they connect or they don’t.  That means that something like bandwidth on demand is useful to buyers primarily if it’s cheaper, which defeats it as a source of new revenue to sellers.

Virtual networking is a connectivity feature that has the virtue of not having been discredited.  There are two dimensions to virtual networking—one that focuses on the concept as a means of exploiting lower-cost access/connection services (the Internet) as a replacement for more expensive tailored VPN services, and the other that focuses on the security and performance benefits of explicit connectivity control and application-specific prioritization.  This is where SD-WAN plays, with most vendors offering only the first of the two dimensions.  That’s a problem in my view, because it means that while those first-dimension SD-WANs could add some revenue by connecting sites that you can’t get on an IP VPN today, it also risks cannibalizing IP VPN revenues.

That leaves the second aspect of virtual networking as the focus point for revenue growth from connection services.  The fact that most operators today have settled for the first-dimension solutions is an indication that virtual networking is something that operators don’t really understand, and regarding which they aren’t finding much awareness among their prospects either.  Educating buyers to create demand is the antithesis of what network operators are used to; they’re the “Build it and they will come” crowd.

The whole point of virtual networking is that the goals of transport infrastructure and connection services are very different.  If you’re building a network for a given market area, it’s logical to look for an approach that lets you connect everything in the area.  That offers better operations and capital economies.  However, if you’re a network user, you don’t want to be connected to everyone, only to the things you want to use.  Promiscuous connectivity is a security problem, and network security is already eating way too much budget dollars.  Virtual networks, if they could make connectivity work as users want, could be a big boon.

The best way to use one of these second-dimension virtual networks would be to have all connectivity be explicit, meaning that it has to be called for.  Making that happen means either having the user (or the user’s application) establish the valid/used connections, or having the virtual network software make a determination based on something like the identity of the endpoints.  User-driven connection management would require changes in the users’ software platform, and probably a general elevation of user literacy—neither of which are likely.  That leaves us with the network-software approach.

To make explicit connectivity work at the network level, you need to start with a way of positive identification of endpoints.  In a VPN, that’s not all that difficult because (presumably) people wouldn’t admit someone onto a virtual network like an SD-WAN if they weren’t entitled to connect to something.  Just having positive user identification is a big step in improving connectivity management.

You can take further steps from there, the most obvious being the step that says “OK, these two endpoints are both mine, but are they really allowed to connect?”  If endpoints were assigned “roles” such as “member of the accounting management team” or “application to support payroll”, you could create role-based access rules that would add considerably to the effectiveness of connection management, without creating excessive effort and delay in getting things connected.  You could also track connection attempts that were not authorized, and bar them until they’re reviewed.

These are good features for revenue enhancement to business customers, but not for the mass market.  Does that mean operators need to get into the OTT business?  They probably should be looking into that, but there’s also an intermediate option, what might be called the “services” space.  For that, we’ll need an example.

Let’s say we have a desire to offer augmented reality, with a user having a “view” of a street that consists of the real world, overlaid by labels.  Each label represents a point of interest, not necessarily limited to landmarks, etc. but including places and even perhaps people.  Could a network operator build a model of labels, based on what a given user would be seeing, perhaps even getting feedback from the real-world side of the AR view?  If they did, they could sell this to OTTs who wanted to offer contextual services.

We could also sell augmentations to the basic service.  Suppose I’m shopping for something.  My hypothetical operator could obtain retail catalog information from stores and show me a point of interest label (with the item and price) on stores where my target purchase could be made.  Again, this could be sold as a service to OTTs.

The point of these examples is that there are plenty of things that are essential for the future of some key technologies (like augmented reality or autonomous vehicles) that everyone will need.  Should everyone produce them?  That would be a massive competitive overbuild, so to speak.  Better to obtain them from a third party.  Operators could be that third party, and participate in OTT services without taking on a retail role.

“Could”, again is the operative qualifier.  The problem operators clearly have is an institutional reluctance to embrace anything that’s not a simple connectivity service.  Even SD-WAN, the best opportunity to break out of the old mode, is being used in the minimalist mode, as nothing more than a higher-level version of basic IP.  The service model of OTT services would surely be easier for them, but at least at the moment they seem convinced that doing nothing is easier still.  And it may be; there are still at least some operators (in high demand-density areas) that could hope to make connectivity profitable enough.  The problem is that nobody knows who these are for sure, and it’s a pretty serious risk for any operator to assume they’re among the chosen.

There is a tide, they say, and that’s true for many things, technology included.  It’s been almost five years since I first said that there was more to be gained from operations automation than by capex reduction via things like NFV.  That was true then, and still true even just a couple years ago.  It’s now bordering on being untrue, and the implications of that shift are truly profound.

In 2014, my model showed that operations automation could have yielded a 6.5 cent reduction in “process opex”, which was about 20%.  Capex reductions via things like NFV could be expected to yield less than 3 cents based on the same modeling.  The current model says that capex improvements would likely yield less than 2 cents in 2020, and opex improvements about the same.  What the heck happened here, and what does that mean?

The biggest problem we have is what could be called “standards latency”.  The NFV process has been interminable, and even today we’ve not come up with an approach that’s both effective and broad enough in area of impact to make a significant difference in overall cost of services.  Operationally, that same point has eroded the possible benefits by delaying adoption, but the bigger problem is that operators have taken piecemeal measures to reduce opex, lacking any systemic approach.  These measures have been less effective and have done nothing to prepare for future improvements, but they’ve managed to erode the benefit of total service lifecycle automation by doing (inefficiently) what automation could have done.

Where we are today is, in a sense, frightening.  We had an opportunity to reduce opex by almost 30%, but point strategies have addressed about two-thirds of that.  We had an opportunity to reduce capex by about 15%, and today the odds are that we’ll achieve less than 3% reduction.  This means that “transformation” of the network is considerably less likely to build a business case than it was in 2014.

The most immediate impact of this shift is that operators are now unlikely to gain much from shifting to a feature-hosting-centric vision of traditional services.  The point-solution strategies that have given them a breathing space on the collapse of profit per bit have now run out of breath, and even if we had a strong service automation and feature-hosting model in place (which we do not), there’s little chance that we could get it into play in time to change things much in profit-per-bit terms.

The first consequence of this is that it is now impossible to make connection services profitable enough to sustain infrastructure investment.  Operators need to climb the food chain in terms of services, moving from simple connectivity to experience creation and delivery, or they’ll eventually have to turn to governments to subsidize their operations—become public utilities again.  That’s a major problem for two reasons.

Reason one is that operators clearly don’t want to get into experiential services, and have dragged their feet deeply enough to create canyons in order to avoid it.  To say “that has to change” is to ignore the fact that it’s been likely it had to change for at least five years, and it hasn’t.  In fact, with the current emphasis on operators outsourcing cloud hosting, there’s every indication operators are running away from their opportunity…again.

Reason number two is that experiential or higher-level services demand additional investment and new improvements in operations automation.  Operators have routinely fronted “first cost” investment in infrastructure in advance of full revenue realization, but that’s not likely to happen with overall profit margins at risk.  And the operations tweaks they’ve made to address opex costs, lacking a systemic solution to operations and service lifecycle automation, aren’t applicable to experiential services.  A good general solution would have been, but we can’t fund that out of the savings that the tweaks have left on the table.

The second consequence of the shift is related to this point.  We can’t fund service lifecycle automation, OSS/BSS modernization, and all the related stuff, from the residual benefits.  Thus, we very likely won’t get the tools needed soon, perhaps ever.  Thus, the service advances that would surely generate more operations complexity—all the experiential services—will take much longer to operationalize and be much harder to make profitable.  NFV, truth be told, would generate opex costs that would swamp any capex benefits, for anything besides business services and virtual CPE.

This problem was created by the failure of the operators and their standards activities (ETSI in particular) to accept and adopt what I’ll call “cloud reality”.  Cloud computing companies knew from the start that they had to make hosting profitable, so they worked hard to provide for operations automation.  All their work could have been leveraged by operators, but it wasn’t.  The ETSI NFV ISG is just now trying to pivot to do what it could and should have done in terms of cloud-technology exploitation.

The interesting thing here is that the network standards people, by demonstrating their inability to address market issues in a timely way, have essentially forced the operators to make the right choice—pick up the cloud work being done and use it instead.  It’s already possible to frame cloud-hosted services and applications in an effective operations framework using the tools created for the cloud.  Might operators have prioritized things a bit differently, or customized things for their own applications and needs?  Sure, but it’s too late now.

“Industry specification groups” or ISGs, which is what the ETSI work on NFV and operations are said to be, shouldn’t be writing standards in the first place, they should be “identifying” them.  We’ve gone way too far over the line in doing the wrong thing, and that’s something that ETSI itself should be looking into.  But even if the standards people actually focused on doing the right thing, could their processes have been completed any sooner, and would they have made the right choices?  We’ll never know.

The final lesson here is that the telecom technology world is hopelessly out of sync with the real market.  When the Internet made consumer data and services the primary opportunity, it made the service market a consumer market.  Consumer markets want what they want when they want it, which is usually right now.  The cloud space has accepted this truth, and the operators never have.

Recently, my blogs on carrier cloud have focused on the question of whether a trend among operators toward outsourcing public cloud services to a cloud provider will impact carrier cloud.  A related question, raised in this Light Reading piece, is whether it could also impact edge computing.  An element of that question is whether edge computing has “primary benefits” that might actually influence telcos, cloud providers, or both to fight for it.

In our hype-driven age, we often find that new technologies are justified only by being new, by being the logical extension of or progression from current technology.  5G is an example; we have a clear justification for evolving, but principally to increase capacity and spectrum utilization.  What might be done to generate more wireless revenue based on 5G is an open question.  We need a “primary benefit”, something users are prepared to pay incrementally to do, in order to pull 5G through faster or in more advanced (5G Core) form.

Edge computing can be linked to things like 5G, but if that’s the path to justifying it then we’d need to either prove that 5G itself needed or significantly benefitted from edge computing, or that some 5G primary benefits had that positive relationship with the edge.  What’s the real situation, at least as much of it as can be seen now?

There is little doubt that consolidation of computing resources, whatever the application, results in greater operations and capital efficiency.  My models have generally shown that computing concentrated in metro data centers would usually generate enough efficiency that further concentration (regional data centers) wouldn’t add much.  The question in edge computing is whether dispersing computing further out would take away much, and if so whether there’d be a justification.

It’s hard to model data center efficiency to account for all the variables, but using the US (the market for which I have the most/best data) as an example, my model shows that of the roughly 250 metro areas, about 180 are dense enough to say that there would be a negligible efficiency difference if we dispersed computing to a level of as many as 10 “edge” sites in the metro area, and just short of 100 would justify over 20 edge sites.  We’d end up with about 1,300 edge data centers if we wanted to disperse at no significant efficiency risk.

There are roughly 12,000 “edge office” locations in the US, places where access lines terminate and where network operators (telcos or cablecos, mobile operators, etc.) have real estate to offer.   That’s about 10 times the number of edge locations that could be deployed without loss of efficiency, which means that to reap full edge-hosting deployment even to edge offices would require a driver.

The most credible benefit of edge computing is latency control.  The speed of data in an optical pipe is about a hundred thousand miles per second, which means that one mile is transited in 10 microseconds.  If we assumed that access was homed directly to metro data centers, that would add only about a millisecond to over 90% of all metro hosting applications.  If we were connected through multiple packet devices, the addition is much greater, on the order of 25 milliseconds.

There are applications that could be sensitive to one-way delays of that magnitude.  Gaming, at least the online multi-player form of gaming, is the best example.  However, it’s important to remember that the latency of an application is the sum of the latencies of all the connections over which the application exchanges data, either with users or among component pieces.  The architecture of a game and the nature of the paths between players would determine whether the benefits of lower latency in that first hop really matters.  If you had a game where players were all hosted in the same edge or metro center, it probably would matter.  If the players were internationally distributed, not so much if at all.  Virtual reality as a driver is linked to gaming, the current killer app for VR.  Thus, it has the same issue set.

Autonomous vehicles have been cited as a need for low-latency computing, but that’s only true if you presumed that some central controller (hosted in an edge site) was running all the vehicles within the local geography.  We have a lot of on-ramp projects for self-driving or driver assist today, and all of them rely on local sensors to detect the time-critical events, like an obstacle in the path of the vehicle.  There might be opportunities for autonomous vehicles to exploit edge computing, but not to drive it.  You’d need to somehow get vehicles depending on the edge to deploy with or before the edges they depend on.

Augmented reality is a credible driver, primarily because it requires that any “augmentation” be linked precisely with the “reality” piece.  Further, AR likely depends on analysis of the user’s local context and the context of other users and other things in the area.  The “in the area” part means first that information further from the user than a couple hundred yards would be rarely valuable because the user wouldn’t see it, and second that an area-wide picture of things and users would be sufficient to satisfy AR needs.  This links AR with personalization and contextualization, legitimate “edge” applications because of their local focus.

The Light Reading article talks about Telstra’s experience with cloud-provider promotion of their own edge-hosting capabilities to operators, as an alternative to “self-deployment” of edge computing as part of carrier cloud.  I think that there are a couple useful links between cloud provider interest in the edge and Telstra.

Australia, Telstra’s home territory, has a very low demand density because so much of it has a very low (even zero) population density.  Not only that, most of the population is divided into a small number of metro areas around the major cities, widely separated.  What little data I have on Oz (as the locals call their country) suggests that every metro area would qualify for high-density edge computing simply because it would be easy to accumulate demand within the cities, enough to justify hosting closer to it.

Why would cloud providers be chasing the Oz-edge?  I think the answer is “To keep Telstra from deploying” more than “To exploit AR (or other) near-term opportunities.”  The most dangerous thing for a cloud provider is more competition.  The most dangerous form of competition is competition for the edge, because operators have a natural real estate advantage there with their access termination points.  If Telstra or any operator deploys data center hosting in edge offices, those in-place resources could open consideration of services to exploit them.  If those edge resources don’t require a lot of justification, they could deploy in advance of demand, and then create the demand.  That would put the cloud providers on the defensive.

On the other hand, if operators outsource their hosting, including edge hosting, then cloud providers build the resource pools at the edge, cloud providers get to exploit them with applications that can utilize but not justify edge resources, and cloud providers keep others out of the market.  Wise choice, and perhaps a critical one for edge computing.

Operators, overall, are very antsy about investing in their own cloud infrastructure at this point.  Left to their own devices, they could decide to let the old earth take a couple of whirls, as the song goes.  OTT competition, even prospective competition, could turn them toward the edge investment, and if the kind of partnership that was proposed to Telstra is taken up by cloud providers elsewhere, it could mean that we get the edge deployments we’ve been wanting.

Still, edge enthusiasts shouldn’t get cocky here.  There is still no strong business case for massive, or even moderate, edge deployment.  If there were, everyone would be running out to deploy.  If early initiatives, whether from operators or cloud providers, fail to realize any of those possible opportunities I’ve cited here, we could see the whole thing stall.

Telefonica has joined Vodafone in picking a cloud partner for enterprise services, rather than fielding its own carrier cloud.  Neither Telefonica nor Vodafone picked the top provider—Amazon—and neither picked runner-up and hybrid cloud leader Microsoft either.  Telefonica selected Google and Vodafone selected IBM.  What does all this mean for operators, for carrier cloud, and for the cloud market overall?

Telefonica’s Business Solutions group did the deal, and Telefonica had previously (last year) announced they’d be reselling Google’s G Suite, so the decision isn’t a big surprise in that sense.  However, there’s no question the new relationship is more strategic and important, and since Telefonica has been a leader in “clouidifying” itself, as well as a leader in NFV, we have to take a hard look at this decision and its possible meaning…and impact.

Obviously, this puts pressure on other EU operators.  More than any other market area, the EU is a combination of an integrated economy and a political federation with a lot of former national competitors in the telco space.  All these players are explicitly competitive because of the economic union, and so they all tend to feel the same pressures and watch how the others respond.  Telefonica can in theory sell to anyone in the EU, and if Google cloud is on their service list, other operators will need to think about how to respond.

One possibility, of course, is carrier-built cloud services, but that notion has largely fallen into disfavor because of the high cost of market entry, the difficulty in staffing an organization to run the cloud, and the corresponding financial risk of having a failure to launch.  My own model never rated operator-provided public cloud services as more than a 14% contributor to carrier cloud deployments, and that number is reached only in 2022, after which the contribution declines.  The model also says that operator cloud services are an exploiter of carrier cloud infrastructure rather than a driver, and that’s an important point when considering the question “Why Google and IBM, second-tier players?”

Suppose you’re an operator who believes that software-defined networks, 5G, NFV, and similar stuff will inevitably shift your investment toward servers and hosting.  You know you’re eventually going toward “carrier cloud” and so you know that eventually you have a possibility of hosting your own public cloud services on your otherwise-justified infrastructure.  But you need to be in the game now, or risk being out of it forever.  Do you sign up with Amazon, who will be your arch-rival, and hope they don’t end up shortstopping your own ambitions, or with a lesser rival?

In fact, you don’t even need to have specific roll-your-own-public-cloud-services ambitions to think in terms of second-tier partners.  A deal with Amazon obviously enriches Amazon, making them a more formidable OTT player and future competitor.  Amazon is less hungry, too, so they’re not likely to give you as good a deal.

Google and IBM are, of course, as hungry as you can get, cloud-wise.  The two are considered locked for third place in the public cloud service wars.  A deal with operators would do both companies a lot of good, and so they’d likely do more to get such a deal.

There’s also a possible technical motive here, though.  Google actually has the most open of all public cloud services.  Their primary tools, like Kubernetes and Istio, are open-source and thus don’t lock users in.  In fact, Kubernetes is widely used by all the public cloud providers.  A network operator like Telefonica could base a cloud service offering on Google and likely shift to their own offering by adopting the underlying open-source tools.  Try that with Amazon.

The question “Why Google?” can, I think, be answered by these points.  The harder question is what this might mean for cloud services in general, and carrier cloud in particular.  I noted that public cloud services were a minimal contributor to the justification of carrier cloud infrastructure, but they are at least some contributor.  The fact that operators aren’t going to draw on public cloud opportunity to justify their own clouds could mean their own clouds are delayed, and also (worse) that they’ve also misjudged the other possible drivers of carrier cloud.  NFV, we know already, has fallen far short of expectations in driving cloud infrastructure.  5G may be suffering the same fate.

There can be no question that operators have, overall and for a variety of reasons, failed to exploit any of the possible near-term drivers of carrier cloud.  We’re at about 35% of the level of carrier cloud deployments that opportunity could have justified.  The Street is now predicting that investment in hyperconverged data centers is slowing.  My own model says the biggest source not being tapped is carrier cloud.

Suppose, just suppose, that operators continue to lag in their exploitation of carrier cloud opportunity.  If that happens, then they’re almost locked out of any service future other than connection services.  That, we know, has been under enormous profit-per-bit pressure for at least six or seven years.  It could get a lot worse, especially if we see the Internet as a broad downward driver of per-bit pricing.  That would favor shifting more and more services to an Internet-overlay (SD-WAN-like) model.  Pricing, like water, seeks its own level, which is the lowest level.

On the other hand, all of this could be good for the cloud as we know it.  If Google and IBM are boosted by carrier deals, and if all four of the top vendors (perhaps even joined by Oracle) compete on a more level footing, we could see not only cloud prices but cloud features improve significantly.  Another positive is that network operators are exposed to cloud issues that mainstream cloud services have yet to face.  We need a unified vision of cloud features, not a vision that separates operators from the rest of the market.  Operator interest in partnering with cloud providers might help with that.

The big, and still-open, question is whether operators will decide to host some or even all of their own service elements in the public cloud.  There’s no reason why the primary application for NFV today, which is virtual CPE (vCPE) couldn’t be hosted in the public cloud if the data-plane traffic and cost issues were addressed.  Might that happen because we rethink how vCPE VNFs are structured, if we could somehow link control-and-management-plane behavior in the cloud with some abbreviated data-plane functioning in the network?  It would be a useful discussion for sure, but if operators start outsourcing their own stuff to public cloud providers, it may spell the death of carrier cloud.

I believe we have perhaps two years as the window where this will all play out.  My model suggests that if operators don’t achieve at least 60% of the opportunity-driven optimum carrier cloud deployment by 2022, they are unlikely to make the shift to carrier cloud at all.  At the current pace, we’d be lucky to get 30% of the optimum, so something radical has to happen.

What’s playing out here is the classic smart-versus-dumb network debate.  Back in 2004, I said in a mock presidential debate on the topic, that unless we had “smart” networks, we’d likely see network operators falling back into public utility status, having no real hope of sustaining profitable operation based on simple connectivity services alone.  We may test that theory, soon.

Personalization and contextualization represent the two primary and enduring drivers for carrier cloud.  The problem is that these drivers are associated with services above and beyond connection, which means they’re not what the operators are comfortable with.  It’s not news that they’re dragging their feet here, but what is news is that they’re prepared to outsource a piece of their carrier cloud future to avoid coming to terms with a reality they’ll have to face eventually.  Or fall into that public utility status I talked about over a decade ago.

With the media asking whether it would really be so bad for operators if 5G were slipped, and whether perhaps the whole idea of accelerating 5G was worthwhile, Cisco is telling the world they’re the most important 5G vendor because they can help operators monetize 5G.  I think all these stories are connected, and that we’re just starting to understand the true problems and opportunities associated with 5G.

Let’s start with Cisco’s statement, which is both true and false.  The true part is that 5G standards alone won’t do much to create incremental revenue.  They’ll facilitate better wireless, but we already know that users won’t pay a lot for more bandwidth.  In fact, simply improving cellular service could very well encourage more OTT traffic, increasing operator costs with little or no revenue compensation.  The answer to new revenue is new services, not new wireless.

The false part of Cisco’s statement starts with that same point, but includes the statement that the reason Cisco can bring new revenue to wireless is that they know the enterprise.  That suggests that enterprise use of 5G could bring new revenues, significant revenues, into operator coffers, and I can’t find any credible way of justifying that statement.  The vast majority of 5G “new revenue” opportunity has to come from the broad market, the consumer market.  Still, we need to explore Cisco’s view a bit further before we can fairly judge.

That won’t take long, fortunately.  Cisco makes three amplifying points.  First, “address the challenge of ability, give operators the ability to extend policies from enterprise to mobile infrastructure, and bring more transparency to what’s happening inside the infrastructure.”  I’m going to assume that the first challenge of “ability” should be “mobility”, and that either SDxCentral of Cisco misunderstood something.  Let’s go from there, then.

On the surface, these three points are nothing but typical Cisco platitudes.  What is the challenge of mobility, why do enterprises want to extend policies to mobile infrastructure, and how is lack of transparency relative to what’s happening in infrastructure hurting them?  There is no real story here so far.

Cisco goes on to comment specifically on two other things, the need for vertical market use cases and the value of network slicing to the enterprise…or perhaps lack of it.  I think there is a case to be made for the notion that some vertical markets might find a value in a partitioned “network-slice” service, but the case would have to address two difficult points.  First, are there things that one or more vertical markets would demand from mobile/wireless service that mass-market wireless couldn’t provide?   Second, could a vertical market somehow coalesce into a single slice without compromising those unique slice value points?

It seems to me that the only credible things that would separate a vertical market’s need for wireless from the mass market’s needs are IoT and privacy.  If we were to assume that we had vertical markets who needed IoT much more than the mass market, and that the network requirement for their IoT were fairly specialized so that making the features available broadly would be too expensive or would use up scarce resources, we could make the IoT story work.

The problem is that we’re having just about the same problem justifying IoT deployment as 5G deployment.  If we assume privacy is the killer reason for slice-based vertical services, we’d have to assume that the vertical represented companies and people who we didn’t need to protect from each other.  Gosh, given that any company’s competitors are in the same vertical market as the company, it’s hard to see how that could be true.  Join in a network of competitors to protect myself?

The truth here is that vertical-market slices don’t make as much sense as “horizontal market” slices, slices built on something like smart cities.  OK, I know smart cities are as hard to jumpstart as 5G and IoT, but we’re grasping at justification straws here!  A smart city has a common need to support commerce, move traffic, keep people safe, and so forth.  The enterprises in it could gain a benefit from having a framework for cooperation and communications around these issues, and the issues are cooperative rather than competitive.

The smart-city-centric approach would have another advantage, which is a natural point of concentration of interest.  One of the problems with IoT and 5G is finding who benefits enough to drive the necessary early risk-taking.  With smart cities, the city itself has the benefit focus and is in a position to do a lot to induce cooperation (tax breaks come to mind).

It might also be true that Cisco’s knowledge of enterprises would help in a smart-city initiative.  If, that is, the knowledge was really there, really compelling.  The problem Cisco has is that smart cities are really about IoT, about contextualization, about “information fields” (to quote one of my old blogs HERE), than about networks per se.  Software is probably the biggest thing you need, and Cisco has never quite gotten the range on software.  Today, with IBM/Red Hat and Dell/VMware increasingly looking at the software ecosystem of the future, we have other players better qualified to claim knowledge of the enterprise than Cisco.

But none of this disqualifies Cisco, for two reasons.  First, everyone with a better story is a marketing flop, and Cisco is a marketing powerhouse.  Who else could spout three clichés and have a network publication run a story around them?  Second, Cisco has more enterprise strategic credibility than IBM or Dell, more than Red Hat or VMware.  If Cisco really can get something going technically, they have the influence to sell it.

There is a problem with 5G, a problem of value.  There is a need to define some kind of community market, because (as the past shows), network services are inherently a community matter.  There may be better, bigger, communities than the enterprise, but the enterprise might indeed be an on-ramp to smart cities, and smart cities might be the on-ramp to 5G and IoT both.

5G is falling short because it provides a resource to exploit without defining a mechanism for the exploiting.  That’s behind the stories on 5G’s problems.  Could enterprise-driven slices pull 5G out of the hole?  Sure.  Could Cisco be a catalyst for that?  Sure.  Could Cisco actually be looking to do that?  Sure, but they might also have become so captivated by a good marketing yarn that they forgot that the best sales pitch in the world is useless without something real to sell.

Cisco’s Live event, where the interview I’ve been citing took place, is always a place where glittering generalities rule, and it’s easy to dismiss Cisco’s approach as a victory of form over substance.  Remember, though, that Cisco is pretty much the lone success story, earnings-wise, among network equipment vendors.  A promise, even a hazy one, from a credible source still means something to buyers.