Month: September 2018

How do vendors and network operators solve their NFV problem?  In just the last two or three months, it’s become clear that operators are generally of the view that NFV, at least as ETSI has defined it, has limited value.  It’s clear that carrier cloud has enormous value, but both vendors and operators are struggling to bootstrap their way into it, or even to define its architecture.  NFV has years of standards-group momentum, media attention (even if it’s shifting in a negative direction) and at least a constituency.  More, for sure, than “carrier cloud” has.  What now?

There are three options that seem to offer themselves for everyone who was in the NFV camp:

1. Stay with NFV both as a term for a hosted-feature future and as a vehicle (through the ETSI NFV ISG) for developing carrier cloud.  This is the “stay the course” track.
2. Stay with NFV as a term, but follow the hallowed industry practice of taking a popular name and giving it to anything that happens to be even slightly related to the original concept, but more useful and likely to succeed.  Then go ahead and let an open-source movement gradually do the right thing, all the time calling it “NFV.”  We’ll call this the “subduction” track.
3. Let the term “NFV” continue to apply to what it does today, but “superset it”, creating a higher-layer concept like “Cloud Network Functions” or better yet, “Cloud-Native Functions” (CNF) that then kicks off a rational cloud-native function effort, eventually absorbing ETSI NFV as a special case.  This is the “superset it” track.

Starting from the top, the stay-the-NFV-course camp has a lot going for it.  Yes, it’s true that the ETSI efforts have gone way off track.  Yes, it’s true that the media (who has to make everything either a positive revolution or a cynical fraud) is turning on NFV.  The ISG still exists, there are some in it who can see the value of shifting future activity to either correct the flaws of the past, or at least add a layer that includes both the old and the right approaches.

For operators, this might be the most dangerous of the options.  CFO and CIO support for NFV has been lukewarm from the start, and the only trends I see only lessen that support.  I’m also seeing a lot of questions being asked by the CTO organization whose standards people have been involved in the ETSI ISG.  Finally, it’s been five years since the ISG started and they’ve been exposed to the perspectives that the NFV structure was wrong for all that period.  Nothing happened for all that time, so we have to assume that there’s a lot of inertia to still to play out here.

For vendors, all these issues apply and then some, but ironically, they push vendors in the opposite direction.  Vendors are about sales, about buyers.  We have lab trials and deployments on NFV.  NFV could be linked, at least semantically, with things like 5G and IoT.  NFV could in theory be applied to anything that requires hosted elements.  There’s a constituency, a familiarity, in NFV, and you can’t sell anything if nobody is designated as a buyer.  Carrier cloud, or cloud-native, is a better idea with little or no specific sponsorship, no architecture to define it, no specific service driver.

The subduction camp says “Well, network functions virtualization is after all about virtualizing network functions.  Isn’t a cloud-hosted function virtual?  Who says the term has to mean ETSI ISG NFV instead of just NFV?  It’ll all come out in the end, and the ETSI ISG people are working on the problem of function virtualization, while the cloud people are working on…well…cloud.  Let the kids play.”

Operators like this approach best for a bunch of reasons.  First, it validates an enormous sunk resource effort in the NFV ISG.  Second, it validates all that management support for NFV.  Third, they can cite open-source as the revolutionary force that converts NFV into cloud-native.  “Open-source” means “someone else is doing it for free” to many operator executives.  They’ll sit back and the right answer will manifest itself (to quote Emerson) “in silence and certainty”.  This should have been what was done from the first, some already think.  Operators can be even less involved than with the ETSI NFV ISG.

We can see some indicators of this perspective already.  All of a sudden, we have a looming bandwidth glut, excess capacity that somehow operators need to monetize.  There’s no profit per bit problem, there’s a lack of sufficient demand.  New applications like autonomous cars, IoT, augmented reality, and so forth will take up the slack, creating zillions of new connections and connection service revenue dollars.  So the story goes, at least.

Vendors also favor this approach, because it combines the positives of the stay-the-course option with a theoretical pathway to actually doing something useful.  Since “NFV” like most buzzwords was valued by vendors mostly to open the door for sales calls that could then shift focus to something near-term and practical, a theoretical path is just as good as a real one.  Better, because the vendors might have to support a real one, while for a theoretical one, a nice press release will do.

The right answer, of course, is our third camp, the “superset” approach.  In every respect, NFV was too narrow a concept to be a revolution, or even to justify the enormous amount of resources put into it.  What should have been done is to explore the requirements for carrier cloud, the broader hosting mission that would have to cover all the bases for new services to be offered by operators down the line.  NFV is surely a part of that (a small part, overall, representing only about 5% of the total opportunity in its best year, which is 2025 in my model), but not enough in itself to move the needle on infrastructure spending balance.

The challenge with the superset approach is getting a forum.  Not only do you need some body to organize the process and actually shepherd things toward the goal, you need a bully pulpit to sing the praises of the concept and raise both operator and vendor awareness.  Good ink, as they say.  The first of these flies in the face of how bodies want to work these days; microsegmentation is the name of the game.  Pick a small target and show early results.  “God-boxes” were anathema to VCs in the old days because they didn’t have a strong focus.  Think of something driven by six or seven major opportunity forces, implicating software, servers, and networking.  How “god-boxy” could you get?

All the difficulties aside, the carrier cloud challenge is really just that broad, which makes it all the more important to somehow come up with a single strategy that answers all the opportunity requirements.  I think it’s going to be very difficult to get to the superset future through any form of standardization or open-source activity.  We’re probably going to blunder there through a combination of operator efforts to deal with the multiple parallel drivers of carrier cloud and vendor desire to get a lock on early deployments.  That’s going to take a lot longer than it should.  We could have been at the point of about 2500 new carrier cloud data centers by now, and we’re actually less than half-way there.

Sprint is yet another operator to announce an IoT platform, but we still don’t have a real handle on what a really useful IoT platform would look like.  So far, perhaps not surprisingly, what’s coming out focuses on what the operator does in the RAN to support IoT sensors.  Is that all there is, or even the best overall place to focus?  I don’t think so.

It’s hardly surprising that operators look at IoT as a connectivity problem; to a hammer salesperson, everything is about nails.  You need lots of devices, so lots of radios (and bills, of course).  You need low latency so you need to pack everything toward the edge.  You need security for public sensors, meaning that you likely need some specialized chips to keep cost and power down for your devices.  You need connectivity, the ability to manage connectivity, and the ability to manage what’s using the connectivity.  All this was the focus of Verizon’s early IoT stuff, and it’s also the focus of Sprint’s Curiosity platform for IoT.

You can forgive the operators for this perspective.  Telephones, after all, were provided to users who then decided what to do with them.  The connectivity was the operators’ contribution; everything else was up to you.  That makes the biggest question for IoT hopefuls “Is IoT like telephony; just providing connectivity to an opportunity base?”  We have to break that one down to answer it.

The first question is whether IoT is about deploying sensors on a RAN at all and that rests on a couple of second-level points.  First, is there a business case for someone to deploy “public” sensors, meaning sensors that would be on a cellular network accessible to others, at least potentially?  Second, would any such business cases be better served with a different approach?  Third, are the security, privacy, and public policy issues associated with public sensors so daunting that only an alternative approach could manage the risks?  Finally, could we hope to bootstrap these applications to manage first cost?

There are lot of things you can do with public sensors, but that’s not the same as saying there are a lot of business cases.  Autonomous vehicles?  Augmented reality?  Yes, those are credible reasons to deploy public sensors in volume, but how rapidly will they develop.  Let’s take them one at a time.

Autonomous vehicles aren’t quite as rare as being struck by lightning, but they’re up there.  This, in an industry where the inertia of past purchases is strong.  Over 90% of all successful vehicle models ever manufactured are still on the road in 15 years.  Today, industry estimates are that one car out of 500 is electric, after almost a decade of availability.  How long would autonomous vehicles take to build a critical mass, and even if you see that as possible, who pays for the deployments?  Do manufacturers kick in to build out the sensor network?  You see the problems.

Augmented reality?  This is an exciting topic, but it’s far from clear that it’s something that drives IoT.  What people want augmented about reality for is in the eye of the beholder.  Landmark recognition?  We can do that with phones today.  Alerting them to sales in stores?  Same answer.  Substitute icons for people to make the real world look like a game?  That’s a graphics problem more than an IoT problem, and that’s true of most augmented reality applications.

Then there’s our second point, which is whether the business case for “public sensor IoT” could be more easily made with something else.  That probably depends on where the sensors are.  In areas where human population density is high, and if the sensor is associated with something like an intersection where there’s normal power line wiring, I’d submit that cellular connectivity probably isn’t the cheapest option.  Certainly we’d be refreshing traffic lights fast enough to keep pace with the onslaught of autonomous vehicles!  In my view, overall, neither of our two key applications for IoT would require cellular sensors; something cheaper would be available.

The third point, then, may be redundant.  We don’t need security, compliance, or public policy concerns to tip the balance.  For the near term, there is nothing compelling in those two applications that would justify IoT deployment using public, cellular-connected, sensors.

There are other pedestrian (meaning not worthy of media attention so you never hear about them) applications of IoT.  I’ve worked on transportation applications of sensor technology for decades, for example.  If you have stuff that moves around on rails, roads, or in the air, you need cellular connectivity for a sensor on it.  There tend to be a lot of these things, so they create a viable market, but do they require a whole new 5G infrastructure?  Not so far because we already have them, and have had them for decades.  There’s even more industrial control stuff that uses sensors, and still more stuff that’s used in residential monitoring and security, but all of that stuff is already served by wires, by local sensor protocols like Zigbee, or by WiFi.

Having dispensed (to my own satisfaction at least) with the justification for a 5G connection bias to IoT, we then turn to the question of what an IoT platform would look like.  The answer to that question is fairly simple; it would have to look quite a bit like one of the function-cloud services we have out there, from Amazon, Google, and Microsoft.  That means that an IoT platform would be a collection of hosting resources (edge, metro, core), a set of features/functions, and an orchestration process that brings all this together to create applications.  Events from IoT trigger, via orchestration, features/functions that eventually do something, whether it’s a control response or a traditional transaction.

There’s connectivity involved with this, of course.  When you host something, you have to get the information that triggered the hosting decision to where you put the feature/function.  When that feature/function generates an event, you have to repeat that process until the chain of actions and reactions comes to its logical conclusion.  Connectivity can be visualized on a per-hosting-site basis or on a process basis, meaning networking the resources or providing network-as-a-service features for the processes as part of the resource layer.

Obviously this isn’t what Sprint is describing, though it’s fairly clear that they could add this on if they needed.  I don’t understand why they don’t see the need, or at least the benefit, because IoT is really about the applications and not the “I’s” or “T’s”.  Experiences augmented by sensor activity is the real goal, the only thing that the users of IoT will pay for.  The top of the revenue food chain then has to drive any lower-level charges for connectivity.  That’s why omitting the real IoT platform is dumb.  Somebody else will have to come up with that platform or the whole IoT strategy for Sprint, Verizon, and everyone else is just a pipe dream.

If somebody else does come up with the strategy, then isn’t their platform, resources, and so forth likely to include inter-process connectivity?  Hasn’t the decision to stand off from the real IoT platform then compromised everything an operator could provide other, perhaps, than the cellular connection (if there really is one needed)?  How many times have we seen operators come up with a strategy that builds in their own disintermediation?  This sure looks like another one.

The announcement that Affirmed Networks EPC is now available as a hosted AWS service is very interesting in two dimensions.  The obvious one is that Amazon itself might be trying to get into the mobile network business, to take advantage of the hosting opportunity that might otherwise drive carrier cloud.  The less obvious one is that they’re demonstrating the value of thinking of future services in two layers, and that second one will impact where Amazon itself might go with the first.

EPC stands for “Evolved Packet Core”, which is the 3GPP model for supporting mobility and mobility management.  EPC (simplified) routes normal IP traffic from a “Packet Data Network Gateway” (connecting to the Internet) to a “Serving Gateway” that connects to the cell sites, via tunnels that can be redirected as the user moves between cells.  In the old days, the PGW and SGW were appliances, basically enhanced routers.  The trend of course has been to turn them into hosted instances, which is where the “virtual” in “Virtual EPC” comes in.

Virtual EPCs aren’t unique, of course.  Affirmed has made one available for some time, and you can also get virtual EPCs from Core Network Dynamics and other sources.  They’re already fairly widely deployed, and sure to be even more widely used as we evolve mobile infrastructure.  Their normal use is to let operators build vendor-independent, scalable, EPC deployments using their own data centers and servers.  A vEPC hosted in the cloud would eliminate the need to deploy those data centers, making the strategy a good one for serving “thin” areas.  The strategy is particularly helpful for mobile virtual network operators (MVNOs) who ride on one or several mobile operators and may have some geographies where they just don’t have the business/traffic to justify their own hosting.

In theory, almost any vEPC implementation can be ported to the cloud, but Affirmed has done the necessary customization to make their stuff work on AWS.  It can be run anywhere Amazon has cloud hosting, scaled as needed to support the traffic load, and linked to virtually any radio network, including WiFi and 5G.  The downside is that it creates an ongoing expense for the hosting, which if the traffic is high enough could exceed the cost of self-hosting.  In other words, like any cloud application, the vEPC has to be cost-managed as activity increases, and perhaps eventually displaced by a self-hosted vEPC (which of course can also be Affirmed’s product).

The cost side of this is what opens my second point.  There are two layers to EPC operation, a signaling layer that mediates the data-plane (tunnel) activity, and the data plane where the tunnels are carried.  The PGW-to-SGW relationship actually carries customer traffic, which is the big cost/performance burden on cloud hosting.  So suppose you tool that data-plane traffic off the public cloud and left the signaling side intact?

Wireless standards groups aren’t necessarily the most data-savvy group out there, but you can fairly presume that if mobility management was available in native form within IP, it would have been used instead of the tunneling approach.  What would be needed is for the IP network itself to “follow” a user roaming across cells.  Some IETF work has been done to propose a way of doing that, but it’s also true that SDN could be used.

The purist model of SDN, the one based on OpenFlow control of white-box switches, could obviously be used to create forwarding rules that linked a cellular user to the Internet on-ramp.  Those rules could then be modified based on control-plane signals of a cell change.  Similarly, you could write a P4 forwarding-language program to accomplish the same thing.  If this were done, then the signaling-level interactions in vEPC could continue to be cloud-hosted while the data plane is passing through a “roamable” service offered by the underlying network.

There are a lot of benefits associated with the ability to split signaling- and data-plane activity, at least optionally.  This capability was introduced by the 3GPP in Release 14, June 2017, and is called “CUPS” for Control and User Plane Separation.  Implementation of CUPS would make it fairly easy to host the control plane in any cloud, and to then manage the data plane as an independent service that could be out-of-cloud, meaning implemented separately or consumed as a service of the IP network itself.

5G Core (5GC) would support CUPS, and other stuff like network slicing that might be related to CUPS in terms of service evolution.  In my view, the value of this separation might well be a driver for 5GC, but I haven’t been able to dig out the details of how the control plane of EPC elements gained access to the data plane elements.  Early evolutionary diagrams suggest a “CUPS-aware” EPC would control specific data plane (“user-plane” in 3GPP terms) elements and that the ultimate approach would be a form of distributed control, which to me should mean some kind of central control to mediate requests from CUPS EPC elements to ensure there’s no resource collision at the data level.

You could implement CUPS in 4G, and Affirmed supports CUPS in its vEPC, though they seem to position it more for (hypothetical) to deliver (possibly useful) latency management.  I think it should be considered more a mainstream feature, something that would allow greater participation of public cloud hosting in EPC by separating the stuff that would add to hosting cost the most from the stuff that would be easily hosted.

But this area is an example of where standards could hurt more than help.  There is no reason why a generic implementation of a CUPS-compliant data-plane service couldn’t be deployed on anything that can provide what looks like a tunnel connection to the cell sites (or their representative elements), as long as the relationship between that service (presumably represented by a “UP” element) and the CUPS-enabled EPC control plane element was standardized.  It’s way too early to say if this kind of logical relationship actually gets mandated, and how far the 3GPP, vendors, and operators would go to make the UP elements and their services represent the full range of network options we have in this virtual age.

This is one reason I think that the talk about NFV and VNFs in EPC or mobile evolution is misplaced.  The separation of control and data plane is really an SDN concept.  Most NFV work has been on VNFs that sit squarely on both the control and data planes, which is exactly the opposite of what CUPS envisions.  In any event, as I’ve noted before, CUPS elements are all multi-tenant by nature, and NFV focuses on tenant-and-service-specific VNFs.

What we really need here is the notion of “network-as-a-service” or NaaS, with the service being offered one that essentially pulls the service termination point from site to site to reflect roaming.

On October 1^st, Verizon will launch the 5G home network service it promised, in four cities.  The pricing for current Verizon wireless customers will be $50 and for others $70.  This is a big deal, perhaps less for the fact that it gives 5G-hungry editors something to work with than that it’s a potential step toward a transformational change.

The new Verizon service will apparently be offered at a 300 Mbps baseline speed, with higher speeds possible where customer location relative to the 5G/FTTN hybrid sites is favorable.  You could, they say, get up to a gig, which for those prices would be a revolutionary bargain in itself.  Verizon’s own FiOS services can’t match that price, and that may be the onramp to the first development we can expect from the service.

It’s hard to see how Verizon could let their FiOS base languish with speeds down at 100 Mbps or below for about the same price (after promotional periods have expired).  I think Verizon will be moving to normalize their pricing across FiOS and 5G, which could give Verizon users the best Internet bargain out there today.  In addition, since it appears that the 5G broadband service is delivering anything from 300Mbps to a gig at the same price, it’s likely that the price curve for capacity on FiOS will be flattened over time.  Some people have told me that Verizon may even baseline FiOS at 300 Mbps.

This is not good news for cable companies, particularly Comcast, for two reasons.  First, and most obvious, the new Verizon service would significantly undercut cable broadband pricing, and perhaps even pressure cable operators to modernize their plant to deliver broadband at high speeds with less traffic interference from other users.  A big build-out at a time when price points are falling isn’t what the cablecos want to see.

Perhaps a bigger problem is the fact that many new residential communities in Verizon’s area have signed deals with Comcast during their building phase, limiting the ability of other operators to come in.  In my own town, some new residential communities can’t get Verizon because there’s a deal with Comcast that prevents running FiOS cable.  Well, radio waves are no respecter of this kind of territorialism.  I think Verizon could plant 5G microcells at the borders of these communities and offer competitive services without any Comcast restraints.

Comcast seems to understand that the game is changing here, not only for broadband but for video as well (see below).  CEO Roberts told Wall Street that Comcast would be emphasizing connectivity, meaning broadband services, and relegating video to a supporting role.  That’s a major shift from the prevailing theory that you can’t make money on home delivery services without the kicker of TV profits.

For everyone, the Verizon strategy has another revolutionary dimension.  You can’t deliver linear TV over this new 5G home network, only broadband data.  Verizon has at least a temporary deal with Google’s YouTube TV to offer customers television over IP, which could be great for Google and Verizon.  The former gets a potential giant boost in market opportunity (it’s behind AT&T’s DirecTV Now today), and the latter gets IPTV without having to buy anybody.  If they like what happens, they could shift FiOS to TVoIP too, and drop a lot of cost along the way.

Another angle to watch in the Verizon deal is the linkage between 5G home broadband and mobile broadband customers with unlimited plans.  AT&T links DirecTV Now with mobile services (its Watch TV offering is free to mobile unlimited users), and so it’s possible Verizon is just responding to a rival.  It’s also possible, based on how Verizon words its discussion about the 5G/FTTN hybrid sites, that Verizon may roll out mobile 5G at the same locations.  In fact, some people tell me that they may use mobile-5G spectrum and technology even for some home users, where customer density isn’t high enough to make the shorter-haul mm-wave delivery optimal.

All this clearly impacts television delivery.  5G home broadband means TVoIP.  Mobile linkage with home broadband encourages that same outcome.  The fact that Verizon seems to be willing to take a partnership with YouTube TV to get TV to customers may be the most telling fact of all.  Could Verizon now be saying that because of its high demand density, it can deploy broadband to the home profitably via 5G, and is intending to dodge the whole TV licensing and content ownership game?

What this might do to the networks, and to TVoIP competition, is also important.  There are fewer barriers to market entry for TVoIP; you can ride any broadband network that can deliver enough bandwidth.  We already have a half-dozen entrants in the space, and it’s possible that 5G home broadband, if widely available and expanded beyond just Verizon, could promote new competitors.  These competitors could end up differentiated only on price, which puts pressure on them to try to focus their marketing by selecting channels more like a la carte.  That’s something the networks have hated from day one.

On the flip side, from the perspective of the TVoIP services, a broader competitive market could impact the current trend to target these services a bit more on the youth and mobile-viewer side.  If you look at today’s lineups, you see the channels in TVoIP are a combination of the big-name networks and youth-favored networks.  Can that be sustained if everything is delivered on IP?  That could be a factor for some of these specially targeted networks.

From an equipment/infrastructure perspective, the 5G home broadband shift could be equally revolutionary.  You obviously need to push a lot of new fiber remotes out, you’ll need a lot of small-cell 5G RAN elements (pre-standard or not), and you’ll need a 5G home broadband antenna.  You won’t need a set-top box or in-home CATV cable, and since broadband routers in the home can typically handle even gigabit speeds, you probably don’t need new routers either.

At the edge, we could expect major changes.  As TVoIP gains traction, it’s sure to drive a need for deep caching and enhanced fiber connectivity to those deep caches.  It’s more challenging to deliver live TV than streaming something from a library;  too many viewing glitches force the provider to either run long and overlap the next show, or skip the areas of problem delivery and risk consumers missing something they think is important.  TVoIP also promotes ad targeting, which means more caching still and logic to quickly pick ads to match viewer profiles.

You could even link this to the thing I’ve been calling “contextual services”.  There’s no reason why people couldn’t share show links on social media, build conversational communities around them, and then have advertising that can provoke interest and even discussion.  You could factor in, per viewer, shopping profiles and even website activity.  All this adds up to smarter delivery, and If vendors and operators think this through, that could enhance and accelerate edge computing.

My model always said that TV and advertising was the earliest large-scale driver of carrier cloud, but things may be developing faster than I’d forecast they would.  That’s important, because while there are a lot of things that could be done with carrier cloud, most of them don’t return enough on investment in the near term to jumpstart deployment.  A driver like TVoIP could justify a lot of caching and ad selection logic near/at the edge, and that could preposition edge computing assets that other applications could leverage.  These could then deploy with less ROI pressure.

Everything in the tech news is not hype, fortunately, and I found a great example of something that’s playing it straight in Fierce Telecom.  “Time to move on from NFV; focus instead on the cloud” is perhaps the best picture of telecom reality I’ve seen in years.  Quoting Vodafone’s head of virtualization, Fran Heeran, the article says “I think the industry needs to look beyond traditional NFV as it’s really about cloudification now. We can’t operate in [an] NFV silo, as it cannot deliver tangible benefits on its own and simply virtualizing legacy or traditional applications will not deliver anything close to the full benefits.”

This mirrors what telco CxOs worldwide have been telling me for almost five years now, but for a different reason.  They believe that NFV got too focused on the low apples, on substituting virtual functions for physical appliances.  These appliances were typically CPE devices designed to add higher-layer features to business services like carrier Ethernet.  That gave NFV a focus on functions that were deployed per-customer, per-service, rather than shared at the service level.  Virtual CPE (vCPE) impacts a miniscule piece of most operator capital budgets.  The big piece is “infrastructure functions” shared by all service users, like the elements of IMS, EPC, video caching and content delivery networks (CDNs) and the like.

Heeran is raising a different issue in his quote, and so we should explore it.  The overall sense of his discussion is that “cloudification” means constructing cloud-native applications to build services.  He associates the concept of “virtualization” with the process of converting something physical (like a firewall) to a virtual-function equivalent.  A “cloud-native” world would mean operators developed a platform that then could host specialized cloud-centric functions, most of which were never specifically provided in appliance form.  A new world, in short.

A world, according to Heeran, that focuses on things like containers and microservices, meaning on the software architecture to be used rather than on the way to translate the current physical to the “future” virtual.  This would be a welcome shift in thinking in my view, because no reasonable implementation of cloud-hosted network features can be operationalized efficiently without some standardization of how each feature is written and integrated.  The NFV ISG should have addressed that.

It may sound like the shift Heeran suggests is radical, but I really think it’s a simple matter of emphasis or definition.  A “virtual network function” or VNF was the goal of NFV.  You could visualize VNFs in two different ways.  First, the way most comforting to old-line standards guys, is that a VNF is a simple migration of the features of a physical network function (PNF, a real device) into hosted form.  Second, a VNF is a useful function or feature implemented to optimally support service needs and exploit hosting resources.  The second is Heeran’s cloud-native thinking, and the first is what we ended up with out of the ISG.

I’ve blogged many times in the past about how I believe the ISG went wrong on this issue, so I’m not going to dwell on that point here.  Instead I want to look at what would actually be needed to make cloud-native work, and the answer lies in combining some thinking from the past and present.

In my second-phase ExperiaSphere project (please note that this project was an open activity with results available to all, without attribution, except the term ExperiaSphere which is trademarked), I took some of my early modeling ideas (from the first phase of ExperiaSphere, modified and presented in 2013 to some Tier One operators as “derived operations”) and defined an approach to service modeling and automation, framed in a series of six annotated PowerPoint tutorials available HERE.  The goal was to talk about how to operationalize and orchestrate services from service features, which of course isn’t the notion we’re talking about here (though it’s still going to be a requirement).  The point was that the architecture I described presumed that there was a set of functional models that represented features or elements of services.  These models would define both a management-plane behavior set (which was the way orchestration was applied), but also a data-plane behavior set.  The first described and controlled the second.

If you’re going to do practical service orchestration in cloud-native (or any other) form, you have to presume this modeled two-plane structure, or the individual features/functions won’t tie together to create a service without custom integration of every service and without having to re-engineer what you did for every change-out of functions/features you make.  The model, in other words, defines a data structure that when interpreted by suitable software, enables a given feature/function to be dropped into a service, connecting both the data plane and the management plane.

The right way to do a cloud-native service is to have a model that defines it, and have service logic that deploys according to the model.  Each element of the model would carry the necessary data/management connection requirements, each of which would have to be framed in terms of a standard API set.  Probably, a series of possible data-plane APIs could be provided, depending on how the feature/function handled information, but for integration purposes we should assume that there’s a common management API set that connects back to operator lifecycle management systems.  The service events then activate these process APIs based on state/event logic in the model, which I’ve described before in the ExperiaSphere presentations and in blogs.

Having a single standard management/process API set simplifies the way that the management plane is connected, but for the data plane it’s more complicated.  There are, as I’ve said, a number of possible “data plane” connections.  One example is a simple digital bitstream, part of the data flow among/between users of the service.  Another would be the retrieval of a customer record from a repository.  Obviously there would have to be different APIs for these types of data-plane interface, but obviously for any given type of interface there should be only a few (ideally one) API, or you face the problem of integration when you change implementations.

Think of this now in “new” terms, meaning intent-model terms.  Each cloud-native feature/function is an intent model, which means that it’s a part of a class structure and a member of a subclass that represents that specific feature/function.  For example, we might have “ServiceFunction.MobileFunction.IMS.CustomerRepository” as a model.  Everything that implements “CustomerRepository” has to present its outside-world connections in exactly the same way, so to ensure integration works each implementation has to harmonize to the APIs defined by that class.

Microservices and API brokerage are a big step in this direction, but primarily for their ability to support the non-service-data-stream aspects of the APIs.  It’s not always desirable to have user data flowing in and out of microservices, particularly when you implement them in containers.  What’s important here, again, is that the implementation of a given feature/function is hidden inside the intent model, so you can use a microservice in a container, a public cloud service, or an appliance that lets you manipulate its management features to conform to the intent model’s standards.

With cloud-native development, there would be enormous benefit to having all the APIs referenced by the models of a given feature/function to be standardized and made a logical part of an inheritance structure (a hierarchy of subclasses).  That would allow any implementation to plug easily into a given model element that’s supposed to represent it.  Where there’s existing code (or even devices) it would be the responsibility of the implementation of a model element to harmonize all the current interfaces to the model reference, so compatibility and integrability could still be attained.

It would be nice to see something more detailed about the “cloud-native” architectural model in the media, of course, but to be realistic you don’t get stories even as long as this blog very often, and I’ve referenced a fairly enormous body of work and prior blogs just to get everyone up to speed.  Eventually, we’ll need to face the complexity of this issue, and I think Fierce Telecom has made a good start.

In earlier blogs, I’ve noted that AI is about as overhyped as a concept can be.  That wouldn’t make a Cisco announcement in AI surprising; Cisco has always been willing to surf the hype wave.  This time could be different, though.  Cisco may actually be onto something very smart…emphasis on “may”.

To start with the hype angle, Cisco quotes a Gartner report that says “only 4% of CIOs worldwide report that they have AI projects in production.”  Given the prominence of AI in stories, you’d think that number would be ten times higher.  Add in the fact that AI technology is really not much different from what it was a decade ago, and you have what might seem like a total yawn in the making, reality-wise.  Not so.

The most telling part of Cisco’s release on their new AI-and-machine-learning server is the quotes at the end, or rather who they’re from.  One is (predictably) from Nvidia, whose GPUs power the Cisco server.  Another is from a university, whose AI research is expected to be a driving force behind the harnessing of AI for the real world, and the last is from a cloud provider, who represents who Cisco is really targeting with this stuff.

What Cisco is announcing is a server that’s built on GPUs, the specialized chips used on complex computational applications.  It’s designed to bridge the task of running the most common and also most forward-looking AI/ML software platforms we have today, the needs of developers to create a reasonable application ecosystem to justify AI, and the needs of those who will likely deploy this kind of stuff first.  It’s also a bridge between two very distinct market periods.

Right now, AI is just hype, as Gartner says (and as I’ve been saying).  That doesn’t mean it’s not valuable to a vendor.  Sales calls sell products, but what sells sales calls is something new and interesting.  Nobody is going to let a salesperson call with the mission of giving them the same update on the same stale crap they’ve been hearing about for years.  Once you get in the door, you can dazzle the prospect with novel things and then get down to business and make your quota.  That’s reason enough to support the hype phase of the AI market, but there’s more.

Servers have to deploy in data centers.  Where will the largest data center opportunity come from for the next 20 years?  Answer: Carrier cloud.  Not only that, whoever else you think might be a winner in deploying AI, they’ll surely be a cloud provider of some sort.  The most important element in the future of AI is who will deploy it, and the answer is “A cloud provider”.  What class of provider represents the largest opportunity of the cloud provider group?  Network operators or telcos or carriers or whatever you’d like to call them.  They’re the future that AI has to connect with.

Cisco is a bridge vendor.  They have a strong network position, strong engagement with the big network operators, and yet they also are a strong provider of servers and software platforms.  UCS has been a success for Cisco, a way for Cisco to acknowledge that network operators in particular are looking beyond pushing bits as a source of future revenues.  Experience hosting is the future, and to do it you need…well, obviously…hosts.  That Cisco has them gives Cisco a good start on engagement, but it also puts competitors in the deep brown.

IT vendors like VMware (who has their own aspirations in the cloud and with network operators) has a platform but no real engagement with the buyer.  Network rivals like Juniper have engagement but nothing to engage on.  Cisco has that bridge, and by productizing it and linking it to AI, they nail their competition to their deficiencies in one area or the other.

Bridges have to take you somewhere, of course, and a hype-phase-one for AI hosting isn’t going to be helpful if nothing comes of it.  That gets us to the second market period.  Starting in 2021, we can expect to see a sudden upsurge in one particular driver of carrier cloud—contextual services.  Today, it’s in the statistical noise level in terms of influence on deployment, but by 2021 it will double what it is today, and by 2024 it will be the largest single driver in the carrier cloud market.

Contextual services are services that take as input detailed information about user requests, but also about the context of those requests.  Where is the user?  What is the user doing, where is the user going, what’s influencing what they’re thinking, what are they seeing, how are they feeling?  Answers to these questions, if they’re available, can be crunched into the critical answer to the real question, which is what does the user want.  Not on the surface, but deep down.  Contextual services are optimally relevant, and so they’re optimally valuable.

Contextual services are also at the heart of everything we’re hearing about.  Autonomous vehicles are darn sure driven by contextual services.  So is IoT success, and 5G success, and augmented reality, and personalization of advertising, and suggesting relevant content to viewers.  Future applications to enhance buyer productivity and seller efficiency will be driven by contextual services, too.  Altogether, contextual services represent over a trillion dollars a year in potential service revenues.  If an operator today spends 19% of revenue on capex, that equates to almost two hundred billion dollars in equipment.  Cisco would be stupid to ignore that.

Remember my point about contextual services being the heart of a bunch of significant stuff?  The corollary point is that the networking industry isn’t going to be able to create silo systems for every possible one of those contextual-related applications.  We need a single framework, a unified model for contextual services that can then drive everything.  That way, early applications grease the skids for the later ones, letting those who have to deploy all this stuff reap the benefits of picking the best returns early on, and then exploiting what they’ve done with things that can’t generate enough ROI to justify a build-out.

The first phase here is then an ecosystem-building phase, from a technology perspective.  Cisco’s not getting into networks with AI servers this year or next, but they’re going to get into labs (as the quote in the release demonstrates).  What goes into networks will have to pass through labs, and so that’s a very important strength this announcement brings to Cisco.  It’s also the place where their current weakness is exposed.

Servers are like oil tanks.  They won’t heat the house, but they hold what does the job.  There’s other stuff needed to connect the oil tank to a comfortable living room, and so while you can engage someone seeking comfort with talk of the tank (so to speak), you’ll quickly have to add some meat to the bones there.  Cisco needs not an AI architecture (which the labs can provide) but a contextual services architecture.  That’s not something that universities or network operators are likely to figure out.  Even cloud providers like Amazon probably can’t do the intellectual heavy lifting needed to turn an experiment into AI into a multi-hundred-billion-dollar industry.

Can Cisco?  That’s my “maybe”.  They’ve always been the top sales firm, one of the most aggressive market-hype exploiters (and often generators).  They can sing any story beautifully and some would say, cynically.  Can they conceptualize the real pathway to AI success?  There’s nothing in Cisco’s material to suggest they even know what contextual services are.  There’s nothing to suggest that they can divide them into meaningful functional classes, devise a way to host each class, device a mechanism to integrate them to create various applications of contextual services, or to productize what buyers would really need to deploy the stuff.  And they’ve given everyone else notice that there’s an opportunity to jump past the hype and deliver reality.  Might another competitor do just that?

Remember, AI and contextual services requires an ecosystem, a platform with clear developer rules, clear business connections.  Without that, it’s just a bunch of rods and joints seeking to become a jungle gym.  This can’t be, for Cisco, one of those famous-of-old five-phase plan announcements where Cisco always placed themselves in phase two and never got beyond phase 3.  This is going to require real software architecture work, which is why it’s not been done already.  I don’t know whether Cisco has the expertise to do it, or the management risk tolerance to even try.  In the end, will having those sales people get their meetings, sing their song, and then sell something else to make quota be enough for Cisco as well as the sales people?  The answer to that question will determine whether Cisco really makes a seminal product in the AI space, or just erects an attractive billboard.

Playing the 5G “can do” versus “will do” game could be enlightening right now.  We’re starting to see more about the reality of 5G emergence, and that might help us in the game.  The game is important because it will define just how many visible changes we can expect from 5G deployment, and when we can expect them.  It’s also important because it may show us what 5G players really have a shot at an upside.

I’ve seen a lot of articles recently on what “5G can do” or “could do”, and the choice of phrases is right on, even though most readers will likely misinterpret the meaning.  “Can do” versus “will do” separates capability from reality.  There are a lot of things technology “can do”, but many (most, these days) are things that the technology could support, of those things had their own business drivers.  The “will do” category consists of the things that actually have those drivers, either because the new technology itself can provide them, or because the technology solves a pent-up problem that’s holding something back.

Let’s start with the stuff that we can say with fair confidence will be provided through 5G.  All of it relates to the radio access network (RAN), which in 5G is known as “New Radio” or NR.  There is no question that we’ll see 5G NR deploy, simply because it’s an improvement in both per-user speed and total capacity per cell site.  There are a lot of subtexts on the 5G NR story, though.

Subtext one is the “mobile-versus-millimeter-wave” story.  The flavor of 5G most people think about is the one targeted to mobile devices, but in some geographies (like the US) it’s likely that another target will dominate early on.  Millimeter wave 5G, so called because of the very short wavelength of the radio frequencies used, is more directional than standard 5G and also has issues passing through a lot of dense objects.  These characteristics make it less than ideal for mobile users, but for creating hybrid “wireline” delivery via a hybrid with fiber-to-the-node (FTTN), it’s great.  Where demand density is low, meaning rural or sparse suburban areas, it might be the only way telcos could get high-speed broadband to homes.

The 5G/FTTH hybrid situation is one reason why the “can/will” confusion with 5G is so high.  It’s almost certain that this mode of 5G will deploy, starting late this year.  Many of the articles on 5G trials are referring to it, but the truth is that this model doesn’t have anything in common with what most call “5G”.  Using it wouldn’t ensure that any other 5G features or deployments were pulled through.  Think of the hybrid approach as a totally different technology, kind of like “home broadband over radar”.

Mobile 5G, meaning NR, is the radio side of what we all think of as 5G, just as sticking an LTE radio on top of a tree doesn’t build a mobile network, so 5G NR needs something to surround it.  The low-apple on that front is something called “5G Non-Stand-Alone”, or NSA.  What the NSA means is that 5G NR rides on the mobile infrastructure of 4G.  This is the minimum requirement for an evolution to what appears to users to be a 5G service, and this is something we can expect to see going live in noticeable quantities in 2019.

The big barrier to NSA isn’t the radios or the NSA hybrid process, but the handsets.  We don’t have much in the way of 5G phones at this point, and that puts operators and users in the classic state of interdependence, sometimes called the “first telephone problem”.  You can’t sell the first telephone because that first buyer would have nobody to call.  You can’t put up NSA without handsets to use it, but nobody would buy handsets for NSA without service.  Somebody has to step up, and it takes time for this kind of tentative watch-the-other-person thing to evolve into some real movement and momentum.  Early 5G phones will obviously have to work on 4G too, but they’ll be a bit more expensive.  Most expect the high-end smartphones (whose users are most likely to want to exercise 5G bragging rights) to move first, and it will probably take several years for budget phones to get 5G.

These are typical ecosystem growing pain problems that will be resolved, but they will be resolved.  You can bet you’ll be able to buy 5G phones and get 5G services, within a couple years if you live in a high-value market area.  Does that mean that all the “could/can” stories then morph do “will/does” stories?  Nope.

We hear about lots of wonderful things that could be done with 5G speeds, but the first caveat we have on our rosy NSA future is that we don’t know what actual service speeds will be offered.  5G specs say the user could experience 1G connections, but we’re back to that “could” qualifier.  There are two problems with superspeed 5G in the real world.  The first is that most applications wouldn’t need anything like that speed; we can deliver HD video in many areas on 4G, and certainly smartphones with WiFi connectivity can experience it.  The second problem is that if somebody were to actually utilize 5G at gigabit rates, they could put a serious strain on the backhaul infrastructure.  Would an operator build out the additional resources without charging more?  Would people pay what was then charged?  You get the picture.

Deeper into 5G than the NR specs, I think even the “could do” label may be misleading, at least for the next three to five years.  The 5G Core specifications add in a lot of stuff, including network slicing and NFV, that are technologies in search of a business model.  Could we do network slicing?  Sure, but the question is why operators would deploy it unless they can see some profit from it.  Same with NFV, but perhaps more so.  Anyone who’s been involved in NFV over the years knows that the majority of the specs are aimed at customer-specific appliance virtualization.  Wireless networks don’t do customer-specific infrastructure deployment.  What 5G needs isn’t NFV, it’s just cloud-hosted features, which we don’t need all that stuff to deploy.

You’re going to get 5G, but almost surely not all of it.  You’re going to get faster connections, but not as fast as you might have hoped.  Don’t worry, you probably won’t know the difference.

5G-specific applications like IoT or augmented reality are the most problematic of all.  I read recently that someone thought every autonomous vehicle would need gigabit connectivity.  Yeah, right.  I do think that there’s a future in augmented reality, but I don’t think the problem is the network, latency, or speed, it’s providing the intelligence needed for the augmentation.  That’s one of those business-case issues, the ecosystem that surrounds information delivery still has to come up with the information.

We should think about mobile futures for sure, but we should be more realistic about the totality of the changes that would be needed to bring a new generation along.  It’s more than what the user wants, it’s most of all what the players deploying the stuff can profit from.  With everyone expecting unlimited service at faster and faster speeds, and even lower prices, we seem to be disconnecting from that profit side, and that won’t have a good outcome.

Anything in network automation is hot these days, so it’s no surprise that the Ciena announcement it was buying DonRiver has made news.  Light Reading has a nice story on it.  Unlike some other network-vendor M&A that seems to create an independent product area hanging in space, Ciena’s deal seems to target a specific ecosystemic combination of the new DonRiver entity and its current Blue Planet stuff.

This deal, I hear, was promoted by some Ciena and Blue Planet users, operators who also employed DonRiver and liked what it brought to their overall operations platform integration game.  Like most “orchestration” tools, Blue Planet has tended to target basic service deployment and some lightweight lifecycle management extensions, but it never had any real OSS/BSS integration and so didn’t target the service as much as service components.  DonRiver could change that.

DonRiver has been around a while, mostly operating as a customization and integration specialist for OSS/BSS systems.  Over time, they’ve developed some tools that supplement their custom work, and these form the basis for the products they offer.  Like many smaller tech firms (and even some larger ones!) they’re highly geeky, which means that you have to dig to gain an understanding of just what they’re doing, certainly dig beyond the news.

Here’s how the Ciena release describes it: “DonRiver will bring new capabilities to Ciena’s Blue Planet software and services portfolio that significantly enhance the company’s ability to deliver on its Adaptive Network vision through intelligent, closed-loop automation.”  That’s a great goal, of course, but so far there’s not much detail on how it will be achieved.  The Ciena release specifically mentions the DonRiver’s “federated network and service inventory management solutions”, and on the DonRiver website, this seems to target multiple-OSS integration.  It’s almost surely intended to be more than that for Ciena.

The first hint we have from the press release is: “The combination of Blue Planet and DonRiver will enhance our ability to deliver closed loop automation of network services and the underlying operational processes across IT/operations and the network,” said Rick Hamilton, senior vice president of Global Software and Services at Ciena. “With this new set of technology and expertise, we can help customers realize the full benefits of network automation by helping them move away from highly complex and fragmented OSS environments to those that accurately reflect the real-time state and utilization of network resources.”

The basic vision of DonRiver is that “OSS” is almost a virtual term rather than a single specific product.  It represents the stack of relationships that starts with the customer, moves through the “service” or business-level descriptions of what’s being sold, and down to the service, network, and element management systems and their associated devices.  In simple terms, “OSS” here means the overall framework for operations management at every level, and so the integration or federation that the release talks about is likely to refer to everything in the network, threading through all the current management/operations processes.

The DonRiver OSS Product Suite is a group of tools/elements built around the DonRiver Fusion integration framework/fabric.  It presents a Network Planning unified view of everything, and also includes a Rapid Path Search capability for finding the best path for a service/connection, Network Discovery and Synchronization to collect every piece of configuration data and centralize it in an inventory database, Automated Workflow Management to create orchestrable, automatic, process integration, and the OSS Network Analyzer that provides reports on important “OSS” trends.

The arguable heart of the suite is the Network Discovery and Synchronization element.  It’s set up much like many of the generalized network elements we find for the cloud (Neutron, OpenDaylight) in that it has plugins to support various management interfaces and protocols.  These are used to pull in current management/configuration data from everything (which is why I put “OSS” in quotes here; it’s more than that), and the results are correlated and made available from a repository.  From there, it can be conveyed in various ways an interconnected to various external systems.

Automated Workflow is also very important, and probably the focus of the specific integration with Blue Planet.  Right now, as I’ve already noted, Blue Planet is a very low-level tool, something only a bit higher than an open-source NFV MANO implementation.  What Automated Workflow would add is the generalized service-order-driven lifecycle automation that operators are looking to get.  You need the rest of the stuff to do this right, but for Ciena the functional improvements DonRiver brings to the table would likely be connected to this piece first.

DonRiver’s stuff, overall, could bring a lot of the ingredients of a true zero-touch automation solution to Ciena.  In fact, the combination of Blue Planet and DonRiver could be very near to a complete solution, but that doesn’t mean that Ciena is going to reap boundless benefits from the deal.  Ciena under-leveraged Blue Planet considerably, for two key reasons that will apply as much or more to the DonRiver assets.

Reason one is that optics is on the bottom and service lifecycle automation is way up top.  There’s no natural connection, no natural symbiosis, and not all that many leverageable contacts common to both.  Ciena doesn’t call on CIOs who run OSS/BSS.  Yes, DonRiver has their own assets in the area, but most of these M&A deals stand or fall on how well the acquiring company can manage its new assets.  Ciena hasn’t set the world on fire above the optical layer.

Reason number two is that in the end, all the DonRiver assets leverage considerable professional services skills, skills to support the kind of across-the-board integration of management and operations that many operators are not yet prepared for.  Those that are, those that have faced the problems of lifecycle automation and understand the issues and needs, will find the Ciena toolbox well-stocked, but for the rest it will be a challenge to get projects moving.  Particularly, I must add, when the scope of an integrated strategy admits perhaps to too many possible project sponsors.  Who is your buyer?

I know a lot about DonRiver from some of my friends in the network operator space, and they’re uniformly impressed by DonRiver’s people, particularly their knowledge of the ins and outs of operations/management integration.  Can these people, the feet-on-the-street professionals that have made things at the top of the pyramid work so far, somehow reach out and guide the senior management of a firm whose own products are in the basement?  That’s exactly what has to happen, and only Ciena can make sure it does.

Sometimes in business you make big, tough, bets.  Sometimes they turn out well, and of course there are those other times.  Right now, we have two players in networking making those big bets, one vendor (VMware) and one operator (AT&T).  Right now, they’re looking a bit sketchy but still just possibly viable, if they players get smart.

AT&T is a poster child for a lot of truths about the network business.  First, they have been experiencing the almost-universal compression in profit-per-bit numbers.  Second, they’ve been quite aggressive in working on the cost side of the equation to buy some legroom.  Third, they have a new revenue strategy that they hope will pick up once costs are controlled, and finally they have a fundamental disadvantage in demand density that means all their efforts will be more difficult.

Demand density, for those who’ve not read my blogs on that topic, is roughly the GDP per square mile, a measure of the opportunity a network can harness.  AT&T’s is less than 15% of rival Verizon’s, which means that things like large-scale FTTH just aren’t going to pay back for AT&T.  That was a problem because video delivery, in the form of channelized TV, was the most credible revenue driver for wireline services.  AT&T, with U-verse, learned that you can’t really make channelized video work over DSL, which is what led to the DirecTV deal.

Now, satellite TV and channelized TV in general is under threat.  AT&T wants to move to a new model for TV, a model that’s based on streaming over IP and in some ways harkens back to the old U-verse approach.  However, the new DirecTV Now model doesn’t have specialized delivery technology.  It rides on any broadband connection with enough capacity, which means it rides on other operators’ broadband services too.  DirecTV Now has been a growth leader in the streaming TV space, achieving second place in the most recent numbers, behind slow-growing Sling TV.

There’s always been a connection between AT&T’s streaming TV plans and its mobile broadband services.  The most recent development in that space is a new offering called “Watch TV”, which offers limited (at least for now) channels at a very low ($15) per month charge, but free to AT&T mobile customers with a high-end unlimited plan.  Unlike other offerings (including DirecTV Now), Watch TV is actually more targeted to non-TV use than to streaming to the TV.  Ah, but there’s still a problem—several, in fact.

One problem is that DirecTV Now is suffering from growth pains.  In many areas of the country, AT&T experiences regular problems with viewing, particularly during prime-time hours.  The rate of outages reported online is high, and the outages sometimes last long enough to make people miss shows they want to watch.  I did a blog on DirecTV Now, and a fair number of users contacted me over the last 6 months to say they’ve dropped the service because of viewing problems.  One who had switched from DirecTV satellite to DirecTV Now said “it’s worse than satellite”.

The other problem is profitability, particularly for the Watch TV offering.  AT&T wants the industry to move to a different model of channel content licensing, a model based on actual viewers rather than just a license for the content, and that’s going to be a very hard sell to an industry that’s worked the other way from the first.  Harder, if other TV providers don’t put that same pressure on.

These points align to create AT&T’s big bet.  If they can’t make DirecTV Now work, they have a major challenge making TV work, making the Time Warner deal pay off, and keeping themselves in the TV game.  Absent that TV story, they’d be forced to compete with other mobile operators and broadband ISPs on price, and as I’ve said, Verizon has much better geographic fundamentals to work with.  AT&T would almost surely lose.

VMware is a vendor I’ve written about regularly recently, largely because of their own big bet.  Here’s a company who literally pioneered virtualization (what do you think the “VM” in VMware stands for?) and who’s been seeing their stature (and market share) in the enterprise space steadily eroded by open-source VM solutions (OpenStack) and containers (Docker, Kubernetes).

The biggest reason for that erosion is public cloud computing.  The public cloud providers, uninterested in paying VMware for the foundation software, have elected to build their own, often from open-source tools.  As it became clear (as it should have been from the first) that enterprises were going to be 100% hybrid cloud users, creating some technical symbiosis between data center and cloud was seen as valuable, and data center virtualization took a more cloud-centric turn.  So not only did VMware not get a big piece of public cloud hosting, it’s started to lose traction among hybrid cloud users.

Then along came carrier cloud.  As I’ve pointed out in blogs for literally half-a-decade, carrier cloud is the largest single source of incremental cloud deployment opportunity in the marketplace.  By 2030, we could see one hundred thousand new carrier cloud data centers, each obviously equipped with a nice array of hyperconverged servers and running a host of virtualization software elements.  No wonder VMware has been touting the enormous potential of carrier cloud.

The problem is that carrier-something has been a touted giant of opportunity for everything from frame relay and ATM to third-party API support.  None of these things panned out, and my data shows that something on the order of 7 out of 8 new technologies that the CTO people explore never achieve widespread deployment.  That, we must note, applies to products that are primarily directed at the network, where operators are comfortable.  Imagine how difficult things would be for hosted processes and experiences?

VMware aspires to a win in carrier cloud, but I’m not sure it has plans.  I don’t think VMware really understands the potential drivers for carrier cloud, except for the hosting of cloud computing services.  That driver has little chance of shaping carrier cloud vendor decisions, either in the near or long term.  They also have little experience dealing with a buyer who exhibits the classic “You can lead a horse to water, but you can’t make it drink” behavior.  In fact, their marketing and positioning of their carrier cloud stuff is mediocre at best, so even the “leading” part is at risk.

I don’t know of any major vendor who has ever made such a gigantic bet on a single market initiative.  VMware, if they were to get this right, would become the leader in cloud/virtualization technology to the point where everyone else would be a footnote.  If they get it wrong, they may well end up being a footnote themselves.

So there we have it; two players in different parts of the industry, each making a very risky bet that could spell a great victory or a crippling defeat.  The common ground?  We’re seeing a networking market in turmoil, driven by the collapse of old business models and the uneven opportunities the new models create for the players.  It’s not surprising that many in this market, even giants, will have to take a deep breath and do something risky.  It’s not surprising that we don’t know now how these bets will play out, and how they do will shape our industry.