Month: October 2014

We have some financial news from the industry today, and we can weave it with some of the technical topics that have been buzzing around to pose a question.  How would SDN and NFV transform the competitive landscape?  Will the business of networking, the vendors who drive it, be significantly impacted by these technologies?  The Street is obsessed by that point, and while I don’t favor shared obsessions, I do think we should consider the impact of change on the business of those who must drive or resist it.

My models suggest that SDN and NFV combined will account for about 14% of capital spending by operators in 2018, and that the number will increase slowly to about 18% beyond that.  However, the mix of equipment purchased will be more dramatically impacted.  We’ll see lower-layer technologies (fiber and first-layer electrical) increase by almost 60%, traditional routing and switching decrease by about 25%, and server spending explode.  Total capex will actually grow through the remainder of this decade, but shift away from Layer 3 (and to a slightly lesser extent Layer 2) to move upward and downward.

If we assumed that SDN and NFV were productized—you could buy an NFV like you can buy a router—the impact of this on vendors would be fairly clear.  You’d see competitive pressure increasing and margins decreasing for the traditional network vendors and you’d see increased focus on being the “enabler” of these changes so that you could pull through your own products by framing the projects in your own terms.  Thus, if you are a network equipment vendor the best SDN/NFV strategy would be to field a product that could quickly address the benefits that will drive all this change.  You can then re-frame your own products and strategies to capitalize on the moves you’re driving.

If you’re an IT player, it’s more complicated.  The largest capital investment made in either SDN or NFV is likely to be servers.  The problem is that the servers will be under enormous margin pressure from the first.  COTS (commercial off-the-shelf) servers are already so price-constrained that IBM doesn’t want to sell them.  So can you differentiate your servers?  Never.  That pressures you to field a complete SDN/NFV solution so you can drive the market’s evolution yourself and make room for your own stuff.  If you don’t, others will drive the deals and you’ll get the leavings.

What makes it complicated is that if you decide to try to drive the deals, you end up competing with the network equipment vendors who have a better position in the current market, better control of the accounts.  So there’s a tendency for the IT players to think in terms of providing servers into what they hope will become an open solution to SDN and NFV.

All of this can be seen in the way the industry is acting this year.  Capex is under pressure, not because of SDN and NFV but because operator return on infrastructure is declining.  SDN and NFV could, if aggressively and correctly applied, fix this problem.  That means that much of the decline in network-equipment capex would happen with or without NFV and SDN.  The things we fear are actually what we are depending on to save us.  And for the usual reasons of protecting incumbencies, we’re not moving much.

You can see from the financial reports this week that vendors like Alcatel-Lucent and Juniper are increasingly securing profit growth by cutting costs rather than by raising revenues.  That’s because they won’t or can’t be aggressive enough to be drivers of an SDN/NFV revolution.  They need to offer operators either higher revenues or lower opex, or capex pressure will continue.  While Alcatel-Lucent has a decent strategy for both SDN and NFV, their positioning is weak.  Is that because they don’t know any better, or because they don’t want to drive changes just yet?

Two winners emerge from this—Huawei and Ericsson.  If we have capex pressure and no systemic response to improve operator return on infrastructure, we eventually kill margins for everyone but the price leader, which is Huawei.  I told one of the traditional network vendors about five years ago that I wasn’t listing Huawei as their “competitor” because Huawei wasn’t a competitor—they were the winner if everyone else decided not to compete.  That’s true.

Ericsson’s case is more interesting.  Remember that I talked earlier about SDN/NFV productization as the logical course?  All the Street pressure on near-term financial performance tends to force vendors to neglect revolutionary technology because revolutions take too long and also tend to further suppress current capex until the new stuff is proved in.  But SDN and NFV conceptually advance (yes, slower than they should) and operators don’t want to see their networks become loss leaders.  If I need the technology, and if there are no productized versions of it, what do I do?  Answer:  Integration.

Ericsson is the leader in network professional services.  They are essentially taking a position that there will not be a cohesive set of SDN or NFV offerings available for years to come.  Your problems, dear buyer, are here and now and these other vendor competitors of ours are building little islands where you need massive continents of new stuff.  We will bridge your islands and build you those continents.  Sign here, please, and be saved!

My model says that an integrator-driven model of SDN/NFV evolution would hurt every class of equipment vendor involved in networking other than the integrators.  It would lower margins on servers, switches, everything.  And because an integrator has no real incentive to build a cohesive tinker-toy product architecture, it could inhibit full realization of an open architecture.

It also says that integration-based approaches will take longer because they’re adopted more as a last-ditch defense than as an offense.  Capex in networking could fall by 8% more by 2020 in an integration-driven model, because fewer benefits will be realized early on to improve things.  More hurt, sooner hurt, isn’t a good thing.

The moral here is that every vendor in both the server and network equipment space is at risk not to the rapid success of SDN and NFV but by delays in achieving what either/both could do.  They won’t tear the heart out of networking, displace everything we have now.  They might add enough benefits to the pot to stop margin erosion and capex decline.

A couple of you dropped me an email after my last blog and expressed an interest in hearing more about what I’d described as “functional” versus “structural” orchestration in NFV and even related technologies (SDN and the cloud).  OK, here goes.

If we start with the service example I gave in yesterday’s blog, we can see that a simple VPN service might consist of two logical or functional elements—the central VPN and the access technology.  If somebody ordered a VPN, we’d give them one central VPN functional element and as many access elements as they had endpoints—branch offices likely.

An operator who offered a service like this might well want to start by defining these same functional elements.  They could define the properties of each, the range of performance (the SLA parameters), etc.  This sort of thing is technology neutral, in that the functional elements are “black boxes” that could be created by any means that allowed the required properties of the element to be met.  SDN, NFV, legacy, it doesn’t matter.

OK, now suppose the order comes in.  The “functional model” of the service as a central circle called “VPN” and ancillary circles called “broadband access” is first fleshed out with the specifics—where does the service access have to be presented, what’s the SLA, and so forth.  Once the model has become an order, we have to instantiate it—commit resources—to make the service real.

This is the point where we have to dip out of functional and into structural.  Suppose that the central VPN element is going to be created with a standard IP VPN using standard routers.  That means that the abstract VPN object has to decompose into the manipulation of network behavior via a management interface.  If that VPN element is to be created using OpenFlow and white-box switches, we have to drive a Controller to build the required paths.  If we were using software-hosted routing, we’d first have to deploy the software elements where we want them, then parameterize them as needed.  The point is that each of these tasks requires an organized set of steps and processes, and so they can be defined as a model.  That’s what I’m calling “structural” modeling and orchestration.

But we can dip even deeper here to learn something useful.  It’s very likely that the reason why we’d have multiple options for instantiating an element relate to where the service is being offered.  Perhaps VPNs confined to a single piece of an operator’s service area can be built entirely with SDN, but those that are wider in scope will either have to use classical routing or a mixture of the two technologies.  So our functional element, VPN, has to be decomposed differently depending on the location of the service users, the endpoints.  Each endpoint also has to be supported using whatever technology happens to be located there.  I think all of this is self-evident.

What may not be self-evident is that this means that we can’t author a service that combines function and structure in the same model unless we want to build a model that describes every possible twist and turn of network functionality, vendors, etc.  If we allow the “how” of deployment to get intermingled with the functional “what” we write infrastructure dependencies into our service models, meaning that we’d then have to change the models when infrastructure changed.

On the other hand, if we separated functional and structural models, the same “service” at the order level could be instantiated on whatever happened to be there as long as the transition from function to structure was made correctly.  You could add new options for any function simply by creating structural models for them and policies/rules on when to use those new models.

In my ExperiaSphere material, I’ve noted that it’s also true that the functional/structural transition takes place at a point where the service goes from being a logical grouping of features to being a specific commitment of resources.  I’ve proposed that a “service architect” builds the functional model of the service by assembling “behaviors” that are created by a “resource architect”.  So when we want to provision a VPN in a given area, we might look first at our resource model and ask what geographic structural model best contained that service area.  We’d then go to the resource model selected, dip down to find the behavior (the function) we needed, and get the structural model for it.

The TMF actually has, or had, a corresponding structure.  Services decomposed into “Customer-Facing Services” and “Resource-Facing Services”.  The former would correspond to my functional modeling and the latter to my structural modeling.  That approach, at least in terminology, appears to be phasing out which I think is unfortunate, but perhaps they could put it back.

The notion that I’ve called “binding” can now be explained.  The first “binding” that’s needed is that the service has to be bound to resource models that are selected by policy, probably largely based on geography and the topology of infrastructure overall.  This branch is in New York, so I first bind to the New York resource model.  I then seek a structural model for my access object (staying with the VPN example) within the New York model, because that’s where I record what can be done in New York.

Once I know the structural model I need, I then decompose or orchestrate it to combine the elements needed to fulfill the functional mission I started with.  I need to record what I do at this point because first I have to commission the resources as needed (deploy, connect, parameterize) and second I have to manage them on an ongoing lifecycle basis, which is hard if I don’t know where my functionality is actually being generated.

We have a number of current technologies that are well-suited to structural modeling, including OpenStack and Yang.  We have at least one (TOSCA) that I think could be used to describe both structural and functional models.   But whatever we do, it’s my view that it is absolutely crucial for the success of NFV that we keep the two models separate, and that we recognize that one model is based on what the service does, and the second on where and how it does it.

I’ve been blogging that the SDN and NFV evolution we’ve been engaged with had been approached top-down instead of the other way around, things would have been different.  I offered a quick view of what top-down NFV might have looked like.  Of course, I know as well as you all that we can’t roll back the clock and do things the other way.  It could be helpful, then, to ask what specific points appear to have been missed in the way things were done.  Perhaps they can still be addressed.

My main point is management.  When you build something based on any form of virtualization, whether you’re virtualizing a router network with SDN or virtualizing a service with NFV, you are creating abstractions to represent functionality, abstractions representing resources, and binding these abstractions together when you deploy.  It’s pretty easy to see that this means you are managing abstractions.

How?  If we construct an abstraction to represent a functional element of a service or the thing the element runs on, we should at the same time construct the management properties of that abstraction.  If I assemble a service from widgets, I have to manage widgets.  If that’s the case, then my construction of the “widget abstraction” has to construct its management framework at the same time.  You can’t expect a management system to understand widgets when there was no such thing before you built it, nor can you expect virtual resources to be manageable in the same way that real resources are managed.  Multi-tenant properties alone demand you frame management views specifically for the service and user.

A second point is the portability of the software elements that make up a service—the virtual network functions or VNFs.  Should a VNF run on any NFV platform or can vendors create platform/VNF combinations that are unique to them, proprietary?  Every single network operator I’ve talked to says that VNFs should be portable across NFV implementations, and I agree.

But what “platform” do they run on?  I’d argue that the answer is “whatever they run on now.”  We should, as a goal, demand that any NFV implementation on-board current network functions from open platforms like Linux.  If you have a piece of code like a Linux firewall, shouldn’t you be able to run it as a VNF?  If there are any new APIs that network code is expected to exercise in order to run as a VNF, then that software will have to be rewritten or “forked” in open-source terms.  If the APIs are proprietary, then there may be no way to make the VNF portable at all.

Point number three is the representation of our abstractions.  A “service” is a collection of virtual functions.  A commercial VPN service, for example, is a combination of a virtual-router function in the center connected to access on-ramp services at the edge.  You can augment this by sticking in firewalls between access and central virtual-router, or add virtual DNS and DHCP to it.  So logically speaking we could model this service as a collection of functions.  The process of deployment would then be the process of mapping these functions to resources.

Here there’s a risk, though.  Realizing a virtual-router function on a network depends on the topology of the network, the features of the real devices, and a bunch of other factors.  Presumably there would be a “recipe” associated with a given function that would build that function on a given network.  Thus, there are really two levels of modeling—one to represent functional relationships and the other to describe the mapping to resources.  If we try to combine these two models, we risk having to change the service model to accommodate changes in the network.  So we have functional and structural models.  Do we need to share these, or can operators build them for their own services?  Perhaps we share only one, the functional, and let structural modeling be provider-specific.  Might that then mean we need only to define our functional model in a language?  We need to talk this through.

Speaking of operators, do we expect network operators to build their services end-to-end with no participation of partners?  That’s not how we do services today.  The term “federation” is often used to describe a relationship between operators where elements of a service are shared.  It’s also used to describe the mechanisms for sharing.  How do we “federate” NFV?

Federation was originally declared to be out of scope for the ISG, but if we build a complete description of how to model a service and deploy from that model and leave out the federation requirements, can we be sure that they could be retrofitted on at some later point?  I don’t think we can make that assumption.

The final point I want to make is the big one.  We have OSS/BSS systems and processes today.  We have network management and network operations center processes too.  In our virtual world, the world of both SDN and NFV, we can use virtual-software smoke and mirrors to make things look the way we’d like them to look.  It follows that we could take the whole NFV process I’ve described here and push it upward into the OSS/BSS, which would mean that SDN and NFV would be essentially a new set of devices.  But we could also push all of this down into what would be called “element management”, so that virtual function collections for services like my VPN example would appear to the OSS/BSS as a single element.  Thus, we can make NFV an OSS/BSS issue or an NMS issue, or anything in between.

Which do we want?  The decision on where this stuff fits in the current operations model could have profound impact on what has to be changed to make optimal use of SDN/NFV.  It certainly has profound impact on what specific standards groups could play a role in the definition of things.  It likely has an effect on how quickly we could drive meaningful changes in service creation and management.

There’s some good news here.  I think that it would be possible to consider these points even now, make insightful decisions on them, and apply the results to the emerging implementation models for NFV and SDN.  Despite the media hype, we have no statistically significant commitment to either technology today; we have time to fix things.  But we are moving from standards into reference implementations, and those have to incorporate high-level issues quickly or the design and development may never be able to accommodate those issues.  Then the choices I framed for each of my points above will have been made…by default.  That’s no way to run a revolution.

I’ve talked a lot about the importance of NFV to the industry at large, and about the fact that management/orchestration (MANO) is the heart of NFV.  As the term itself suggests, MANO is the fusion of two interdependent processes that also happen to be phases in a service lifecycle.  To most involved in NFV, the deployment of services using or based on NFV is a process of orchestration, and once the deployment is underway or complete (depending on your view), it’s up to management to take over.  This dualism is interesting because it impacts both where NFV has to go in a functional sense, and what specific case studies or proofs of concept are most relevant.

Let’s look for a moment at three “NFV services”.  One is the mobile/LTE service that consists largely of IMS and Evolved Packet Core (EPC) functionality.  The second is an enterprise branch access service-chaining application, and the final one is a multi-featured cloud-based collaborative relationship.  All of these have been suggested by someone as a target for NFV, but they’re all very different in how they balance the “MAN” and the “O” in MANO.  We’ll start with deployment and move through lifecycle stages to see what the differences in these services can tell us.

Our mobile/LTE service is going to be deployed when mobile LTE is offered in a geography, and once it’s deployed it will remain in place as long as LTE is sold.  Yes, there will likely be in-service changes and repairs and so forth, but you don’t deploy IMS with each call.  In fact, mobile/LTE is inherently a multi-tenant service.  Deployment or orchestration, our “O” in MANO, isn’t something that happens very often.  It’s also something that isn’t exactly extemporaneous; operators plan for years for cellular deployments.  In fact, you could install the service components manually, and orchestration is valuable only to the extent that the functionality is exercised as part of scaling, problem response, etc.

With our enterprise branch access application, the service is instantiated when the customer orders it, and it stays in place for the life of the contract—a year or two, perhaps, or more.  It’s possible that the service might be sold as “Branch-OnRamp-To-VPN”, in which case it might be sold each time a new branch comes online.  “O” is a little bigger here, more likely to happen.  Our branch service is also inherently single-tenant, which means that we have to instantiate it for every customer rather than once for all customers as we did with mobile/LTE.  We also have to pay a little attention to the provisioning delays, but because branches don’t spring up like weeds it’s not likely that the service would demand instant response to an order.  Finally, we need to think about the fact that some of the service orders might be fulfilled by hosting part of the functionality in a local device, some by remote hosting, and some even by just sending a custom box as before.  That’s complicated  .Orchestration is valuable here because it automates a task that’s going to be repeated pretty often and be variable in details, meaning it could be messed up often if it weren’t systematized.  Also, labor costs for manual operation could be pretty significant.

Now we come to our collaborative application.  Here we have a function that’s likely to be deployed for a period of hours or minutes, and is also inherently single-tenant.  Depending on where the participants happen to be, the range of facilities that might be required and the optimum location for features to be hosted could be highly variable.  We might even need ad hoc multi-provider federation of resources.  Given those parameters we simply can’t expect to offer the service at a price buyers would pay unless we can do something about the amount of manual activity and costs, and reduce the time it takes for the service to be rolled out when requested.

Let’s now look at sustaining the service during its active state, clearly part of the “MAN” in MANO.  Again, we’ll explore the three services separately.

Our mobile/LTE service is going to be a major user of resources, resources committed to the service for the long haul because the service is essentially perpetual.  Just as we could orchestrate the service deployment manually, we could make management connections manually.  It’s also true that IMS/EPC works on the presumption that you manage collective resources to achieve a grade of service for calls, not that you manage every call.  Thus, “service management” is really not a major issue here.  What we do have to worry about is whether the resources used for this service are shared with other services so that we’d have to be aware of the boundaries.  In most cases, IMS/EPC is likely to have dedicated resources, so management isn’t much changed here.

With our branch access device service, we have a number of complications.  First, service management has to be considered distinct because the buyer of the service is going to expect to manage the logical or functional device, whether we elect to send a box or build part of the functionality by assembling VNFs in a chain.  We see the first real management issues with this example, then.  Second, the hosting point for the VNFs associated with this service could be local in an agile edge device, distributed into a server farm somewhere, or both.  The resources used in distributed hosting are almost certain to be shared.  This introduces a second management issue, which is isolating shared resources from interference created when one user of the resource attempts to exercise what the user thinks is normal service management.  These two factors combine to suggest that management functions will need to be virtualized in parallel with service elements in NFV.  Otherwise we can’t compose the two and insure they are harmonious through the management lifecycle.

How about our third application, collaboration?  Here we see an interesting dynamic because as the application becomes more pervasive, it moves from looking somewhat like a short-cycle branch-access service deployment (specialized resources per user/instance) to looking like a multi-tenant service based on shared resources, like our mobile/LTE application.  If we had a large and active group of collaborative users, we’d certainly provision the service like any shared service.  For a small specialized group, we’d handle it like a one-off.

What we learn from this is that the thing that matters the most in NFV isn’t the application itself, it’s the dynamism and scale of the application.  It’s whether “service management” is seen as a specific need or not, whether virtualization impacts what’s visible to the service buyer, not just impacts the service.  If we want to get the most from NFV, we should be testing the agility and dynamism of proposed services and measuring their effect on both “MAN” and “O”.  Otherwise we risk running tests and demonstrations that don’t move the ball.

Juniper had their earnings call yesterday, and the refrain was hardly unexpected given general market trends and Juniper’s recent earnings calls.  CEO Shaygan Kheradpir started by saying that the company had made significant progress and the disappointing results were due to “industry headwinds”.  That may be different words than the last Juniper CEO used to use, but the sentiment was the same.

Like IBM, whose focus on near-term shareholder value above all else was the subject of a recent editorial, Juniper is spending money to buy back shares and raise the dividend, both of which have the effect of boosting or at least propping up the stock price.  However, the measures aren’t resulting in unqualified success in sustaining share price, and they’re killing Juniper’s long-term prospects.

Of all the companies in the networking industry, Juniper should be the one facing the transformation to come with the most confidence.  Since its founding about 20 years ago, Juniper had a reputation for technical excellence, and over those years it’s done some of the most innovative and forward-looking things any vendor ever did.  Juniper’s IPsphere initiative, about a decade ago, was in fact a harbinger of SDN and NFV change and had aspects yet to be addressed (but critically important) by both technology revolutions.  They predicted cloud computing, they actually had a product that separated the control plane processing and offloaded it onto a server blade.  They even developed a chip set that could have blurred the line between traditional network hardware and software.

Juniper’s problems arose, IMHO, in part because of a management change—Kevin Johnson and the “Microsoft club” took power—and in part because of the crash of 2008 that put pressure on spending.  Nearly all the critical insights that Juniper had were wasted for lack of execution or improper positioning.  The company’s M&A launched opportunities in both mobile and content delivery, and in both cases the efforts came to nothing.  This, at the very time when both technologies were on the cusp of revolution.

IPsphere and Juniper’s chip and product architectures should have prepared them for SDN and NFV, but the company waffled even to the extent of not positioning announcements for NFV as NFV but as SDN instead.  Their new CEO, brought in so it’s said by a board under pressure from activist investors, decided to “build shareholder value” through financial/accounting means and with that decision funds that could easily have established Juniper as a leader in SDN and NFV bought shares back instead.  As I said, it’s not done all that much for share price.  Juniper’s stock is trading about where it did on the launching of NFV in 2012 and on the one- and two-year anniversaries of that event.

All of the companies in the network equipment space have booted SDN/NFV to at least some degree, IMHO, though Juniper may have the distinction of selling itself shorter than any of the rest.  There’s a valuable lesson to learn from them, though, especially when you consider them in contrast to players like Ciena and Infinera.  If you are selling gear above Layer 1 of the network, then you are in the intelligent network services business whether you acknowledge that or not.  Carriers are shifting their strategies for basic connectivity/transport down the OSI stack in favor of capacity creation and away from the layers that have traditionally supported bandwidth management.  The “Why” is critical to applying a fix to this dilemma, which is critical if you supply switches or routers.

The electrical layer of a packet network is really about aggregation and multiplexing.  Since the seminal report (by the Rand Corporation in 1966) on packet switching, networking has advanced in features and performance by dividing up user flows into packets and multiplexing the packets on a web of physical media (soon optical) trunks.  This provided for full connectivity without dedicated optical paths, something that was essential with cost per bit so high.  But optical prices in cost-per-bit terms have fallen sharply and the cost of managing electrical-layer networks has risen sharply.  In more and more cases it makes sense to dumb down the electrical layer and simply throw bits at the problem.  That’s one of the fundamental forces in the networking space today.  We’re learning to do with agile optics what we used to do with core routers.  Soon we’ll move that understanding further out into the metro networks, where most of the investment is anyway.  When that happens, the impact on the electrical-layer gadgets will be profound.

NFV and SDN have been portrayed as other steps in the diminution of switching/routing layers.  That view is likely why Juniper and others didn’t jump into either of the two as aggressively as they should have.  But the perception that the only thing you can do with new technology is to cut costs is likely a bias among CEOs/CFOs who think the only way to raise their own profits in what they see to be a steady long-term revenue decline is to reduce their headcount.  NFV and to a lesser degree SDN are ways of linking new services, higher-layer services, OTT-like services, to the network.  They are the thing that the network operators need to have.  Even that enterprises need to have.  But you’re not going to get them to fulfill this truly valuable and revolutionary mission by handing the future of SDN and NFV over to bean-counters.  You need revolutionaries.

Everyone has had some of these people, including or even especially Juniper.  I suspect that at this point, with the CEO’s strategy for the company’s future made clear, most of Juniper’s have moved on to greener (read “nearly any other”) pastures.  In the good old days these people would have started companies, but VCs these days only want quick social-media flips, not incipient revolutions.

Ten years ago, Juniper decided not to get into optical.  They’ve decided now, at least implicitly, not to get into SDN/NFV revolution.  As I said, to be fair, so have most of their competitors.  But there is going to be a network revolution over the balance of this decade.  It will either be a transformation of Layers 2 and 3 into the service value network or it will be a transformation of those layers into a simple on-ramp to agile optics.  You either build valuable bits or you just push bits around.  Which mission do you want, dear vendor?  Juniper, sadly, has made its choice.

The relationship between Cisco, VMware, and EMC has been a great source of sound bites in the last year or so.  When EMC and Cisco partnered to create VCE, a kind of orphan acronym that likely stands for “Virtual Cloud Environment” but which the VCE “About” page fails to define, there was speculation that the union could be revolutionary.  Well, the union is pretty much off with the announcement that EMC will buy most of Cisco’s stake and that VCE will join EMC in the same status as VMware.  The revolution?  Let’s see.

The basic notion of VCE is that cloud infrastructure and virtualization are first and foremost the big thing in IT in general and the data center in particular.  I’ve noted that in my surveys, it’s clear that for enterprises today data center planning and networking are driving the bus for all IT and network spending, and that companies with influence in the data center influence everything.  Even product areas they don’t sell into, in fact.

The second notion behind VCE is that the cloud is a vast whirling assembly of stuff whose integration can easily get totally out of control.  Building a cloud or adding to one could easily become a task so formidable that planners would break into sweats and take the day off.  The VCE solution is the notion of packaged infrastructure—Vblock Systems.  VBlocks have models just like the mainframes of old, but they contain not just the compute but also storage and networking elements.  They are hardware platforms out of the box, things you could align to your business needs and augment as needed.

I was never sure how sensible this approach was, frankly.  It’s not that the basic notions behind the venture are false, but that the project seemed doomed in providing what was really needed, in part because of the fundamental competitive rift I opened this blog with.  It’s not that VMware is a Cisco competitor despite the former’s acquisition of Nicira, a virtual network play.  The problem is that VMware is driving a notion of networking and application-building that Cisco thinks threaten their own efforts to increase their server market and salvage as much traditional routing/switching as possible.  Remember, whoever rules the data center rules the budget.

At any rate, the Cisco/VMware dynamic makes it hard to build a truly one-stop-shop “block” solution for virtualization and the cloud because the real solution would have to include all the platform software.  Go to the VCE website and look at the product descriptions and you find more mentions of Microsoft and SAP and Oracle than of VMware.  While it’s not impossible to create a block/platform strategy that’s missing the software platform ingredients, it’s darn sure sub-optimal.  It also begs the question “is this just another hardware player?”

IBM, no slouch at reinventing itself in times of turmoil, has determined that the commodity server (x86) business is something you can’t be in and be profitable.  Frankly, I think they decided you can’t be in any hardware sector and be profitable, but they can’t strand their proprietary-platform users.  So just what is it that VCE is supposed to do?  Replace IBM as a server company?  Combat HP at a time when turmoil in the market and in HP’s business strategy weaken it?  Darn if I know, but VCE starting as it did as the classic horse-designed-by-committee, seemed from the first to have little going for it.  I think the current situation proves it didn’t.

So what now?  VCE, as an EMC satellite, can definitely create a software-centric vision of a virtualization/cloud platform, but what’s different about that without specific compute hardware?  Will they continue to incorporate Cisco UCS (forget what they say; this is a period of maximum defensive positioning for everyone)?  Will Intel, another minority investor in VCE, step up and field its own commercial server line (risking alienating its current server customers)?  And in any event, how would a software-centric positioning of a Vblock look different than the positioning of VMware’s offerings?

One potential benefit for EMC of a satellite VCE would be as a framework for absorbing (rather than spinning out) some of its strategic elements, like VMware.  VMware’s own growth is becoming more problematic as the market matures, and storage is still something that fits into an architecture rather than forms one as far as enterprise buyers are concerned.  It would certainly help EMC to be able to tell a cohesive story, to frame a combination of things as strategic when any individual piece of that pie was going to look pedestrian.  But EMC would have to do that positioning, or have VMware do it, and neither of them has been very good at singing and dancing.

That may be the foundation reason behind the Cisco/EMC split.  Cisco, marketer extraordinaire, may have concluded that either 1) VCE will fall on its face, embarrassing Cisco and leaving a hole in its positioning, or 2) Cisco would make VCE into a powerhouse that would eventually end up combined with VMware to pose a greater threat than before.

All of this of course ignores the two foundation points; data center control and increased platform complexity.  Neither of these is going away, which means that every vendor with any product in networking or IT is eventually going to have to address them.  Do software-centric players (which means IBM, Microsoft, Oracle, VMware) build up a notion of the platform of the future as software that envelopes and commoditizes servers further?  Do hardware players try to bundle software with hardware to undermine the influence of companies who want to provide software only as an independent overlay?  Do network vendors embrace server/software integration or try to stand against it and position against the current trend?

Probably all of the above, but as you likely guessed my view is that none of these is the right approach.  If complexity is the problem then something that can directly manage complexity is the solution.  I don’t think the NFV ISG undertook their task optimally but that doesn’t mean they didn’t contribute some critical insights.  The notion of MANO (management/orchestration) may be the key to the kingdom here, no matter what kingdom you’re aiming for.  Automation of the relationship between application components, resources, and users could be the glue that binds all we have today into a new software architecture.  That would be a prize to any of the groups, the vendors, I’ve named.  Enough of one to make VCE and EMC a true strategic player if they seize it, or a true strategic loser if they don’t.

VMware reported its quarter, and while the company beat expectations overall, the report still raises several questions and doesn’t answer some of the bigger holdovers.  I’ve been talking about the “Novell effect” in prior blogs, and it’s obvious that VMware faces the risk of simply saturating its market.  While there are exits from that risk point, it’s neither clear that they’d sustain growth nor that VMware is capable of driving the good outcomes.

Over the last couple of years, VMware’s growth has come increasingly as a result of large deals with enterprises and governments—what the company and the Street call “ELAs” or enterprise license agreements.  The shift toward revenue derived from megadeals has made VMware’s revenue more lumpy, which means that a small shift in timing can have a big impact on the quarter.  However, you also have to consider the old adage that the problem with selling to the Fortune 500 is that there are only 500 of them.  Targeting big companies inevitably results in your running out of buyers, and so the Street is always looking for signs of that saturation softness.  The ELA lumps can look like those signs, so everyone’s skittish.

The company doesn’t do itself any favors.  The issues associated with ELA lumps must have been known but was only just articulated, making it seem like management was holding back or that the current story is just “spin” they came up with.  On the flip side, though, the Street doesn’t understand the real issues and so is looking for the wrong problems downstream.

Virtualization is a tool to help companies utilize hardware better, and it’s valuable because the power of new servers continues to grow while the needs of applications are growing slower.  Historically, users tended to put many applications on dedicated boxes because a server was needed to run a given application, but as server power grew there was a desire to “consolidate” servers.  The important points here are 1) that virtualization is simply a mechanism for sharing servers between applications that weren’t designed to share nice, and 2) that consolidation eventually has to run its course.

VMware, like other companies (Novell comes to mind) has addressed the inevitable by expanding its scope to include networking, storage, and so forth.  Novell added directory management and other things to file/printer sharing; same principle.  The problem of course is that the more complicated your offering is the longer your selling cycle is and the more difficult it is to prove to buyers that the incremental gains from upgrading are worth the cost.  The longer and more consolidative the sales cycle, the more the revenue per deal needed to justify the effort, and eventually you get mega-ELAs and lumps.

The cloud, which the Street is perpetually worried about, is less a risk to VMware than a potential path of escape.  The notion that the public cloud would replace or retard virtualization growth isn’t complete myth, but it’s certainly exaggerated.  The megadeals that VMware now does are with companies whose internal economies of scale are simply too good to make public cloud services a slam dunk financially.  Yes, cloud consideration could further complicate sales cycles, but it’s not a killer.  Private cloud, meaning the addition of additional application agility tools, could help VMware by adding a feature that most buyers think is valuable.  Yet VMware is rarely seen as a cloud leader, and in no small part because they’ve avoided being a big public cloud player.

On the call, VMware’s CEO Pat Gelsinger talked about “fluid IT” which is not an unreasonable way of describing where we’re headed or what’s needed in the way of server platform tools.  However, what he’s describing is really at the minimum an argument for cloudbursting and at the other extreme a world where applications are built to be more directly coupled to workers’ activity and thus more agile.  In either case, you can argue that this is a story about the cloud, DevOps and MANO, and eventually a whole new collaborative/empowerment model for workers.  That could be a nice story.

But VMware doesn’t tell it.  They have treated the cloud defensively almost from the first, and have allowed open-source tools like OpenStack to steal the thunder of the cloud in both the public cloud space and among cloud planners in those big enterprises VMware covets.  They have been laggards in DevOps, simply supporting it and not trying to drive it, and they’ve been almost non sequiturs in NFV, an activity that could well be producing (perhaps by accident) the orchestration model for applications in the future.

Any multi-tasking operating system lets applications share hardware.  Linux containers offer enough isolation of applications to suffice in single-tenant clouds like the private clouds that VMware users are contemplating.  You don’t need to have platform uniformity to cloudburst if you’ve designed everything right.  There is no natural need to have rigid hardware virtualization continuing to expand into the future unless you believe that the issues of server efficiency justify a band-aid and never drive changes to application design to render the issues moot.

The Street is right that VMware faces major risks, and right to think that management is groping more than driving the bus here.  They’re wrong thinking that public cloud is the threat; public cloud is yet another mechanism to address utilization issues and challenges for smaller companies in sustaining required IT skills in-house.  What VMware has to do isn’t defend itself against cloud, but use cloud evolution to expand its own opportunity.  And even there, it will have to look increasingly to the tools that make it possible to build and deploy agile apps and not to the simple platforms that they run on.

Nobody thought that LAN operating systems like Novell’s Netware could ever run out of steam, and yet it should have been clear from the first that if networked-resource features like file and printer sharing were valuable to users, OS providers would simply include them.  That’s the risk now for VMware; they could become the lemonade stand sitting at the roadside near where a new mega-restaurant is being built.  Being a one-stop shop can’t become being a one-product shop.

Today we had the interesting combination of Apple and Verizon quarterly reports, and it’s worth looking at the two in synchrony because of the (obvious, we hope) linkage between the service provider space and the premier provider of consumer mobile technology.  There is in fact likely a bit more synchrony than you’d think.

Verizon slightly beat on revenue and slightly missed on earnings, but the most interesting contrast was between wireless services (up 7%) and wireline (down 0.8%).  It’s clear that for Verizon as for most of the big telcos, it’s wireless that’s making the money.  Verizon is also talking about its capex focus on capacity augmentation for 4G LTE, rather than about how much more it’s spending on FiOS or wireline in general.

For about a decade, carriers have found revenue per bit higher in the wireless space for the simple reason that wireless users pay more for broadband bits than wireline users.  As long as that’s true, money is going to flow more into wireless, but it’s also clear when you look at global trends that all of the factors that have driven down revenue per bit on the wireline side are already pushing at wireless.  Unlimited usage plans, even with data metering to prevent users from running amok, can only do for wireless what they’ve done for wireline years ago—commoditize bits.

In some countries, notably the EU, we’re also seeing regulatory factors pressure wireless.  Roaming charges have been a way for wireless carriers to make their own services more sticky, but the EU has been at war with higher roaming rates and so that factor is both putting revenue at risk and also creating competitive churn at a higher rate.  You don’t see as much of that in the US of course, but were there to be a major shift in neutrality policy that enveloped wireless services, it’s possible there might be a similar regulatory-driven impact here.

The churn thing is where Apple comes in, I think.  What all wireless operators want is for their customers to renew contracts by habit, but in most cases the renewals are tied to handset upgrades.  Apple users are the most likely to upgrade their phones, and so Verizon and others have tended to focus their new plans on Apple.  Verizon rival Sprint, for example, has a new plan that offers low-cost unlimited usage for iPhone 6 only.  Apple is essentially building the prizes in Crackerjack boxes, and so of course they’re riding the wave of carrier churn management.

Underneath the current situation are a couple of complications for both companies, and some unique ones for each.  Top of the joint issues is what I’ve called the “Novell problem”, which means that users can’t be made to upgrade constantly unless you can radically grow utility with each upgrade.  That, we know from other experiences in tech, isn’t likely to be possible.  However, churn-driven upgrade policies could be curtailed even before users succumb to feature boredom if competitors like T-Mobile and Sprint stop putting the pressure on the major providers by promising special deals to users who upgrade their phones.

Most operators are already reporting ARPU growth has plateaued or even reversed, so only increases in wireless TAM or market share will help drive up revenues.  Clearly those sources aren’t going to contribute to radical shifts at this point.  LTE build-out is nearing maturity too, which means that capex augmentation in wireless will be less likely.  Wireless is becoming less a growth business, less a driver of infrastructure change, for the simple reason that it’s just another bit-based service and will surely be impacted by the same forces that have already hit wireline.  To my mind this tamps down speculation that Verizon might spin off its FiOS business, which I’ll get to in a minute.

Apple’s challenge, then, is what happens when one of the forces that are driving handset upgrades begins to lose steam.  It’s unlikely other forces will emerge, and so over time iPhones will taper.  Apple’s tablet numbers were a disappointment and it’s clear that the Mac isn’t going to drive the company to double-digit stock price appreciation either.  That makes Apple dependent on new markets, such as the wearables that its watch offering represents.  The fact that Apple indicated it would not break out watch revenues once the product becomes available suggests it’s worried that lack of hockey-stick growth there will sour investors.

Verizon’s challenge is similar.  Its major revenue growth comes from the consumer side; revenues from non-consumer sources were off.  All the forces we’ve talked about make it unlikely that consumer revenues will grow forever; wireless market shares will plateau and FiOS penetration has slowed as well since Verizon isn’t entering new areas.  It’s this force that is putting pressure on capex.  If you can’t raise revenues every year to justify stock price increases, you have to cut costs.  While network equipment vendors don’t like this equation for their customers, they apply it relentlessly in their own businesses.

What I think is indicated here is the exploration of a more valuable relationship between mobile devices and mobile services.  This has to go beyond the simple substitution of payment by iPhone for payment by credit card, too.  The question is what the service might be, and I think it’s likely that it would involve combining user presence/context in the broadest sense with voice-based personal assistant technology like Siri or Cortana.  The challenge in this transition will be daunting, though, and not for technical reasons.

If you combined personal assistant technology (speech recognition) with improved AI-aided contextual search, you could generate something that could approach the movie “Her” in sophistication and utility.  However, this is a marriage of cloud and handset and that means there’s likely be a war to determine where the most valuable elements of the relationship would be hosted.  Apple would obviously like the differentiation to be in the handset, but operators like Verizon would rather it be in the cloud.  Further, hosting complex analysis in the handset would mean pumping more data out there, which would in an unlimited-usage mobile world raise carrier costs.

Apple was up slightly, pre-market.  Verizon was down slightly.  No big movements, because there’s no big news.  The question for investors, and for those of us who watch telecom overall, is whether the forces that have driven the two in semi-synchrony will now separate them, and whether that separation will then contribute to tech under-realizing its potential even further.

According to one of the financial pundits, “IBM needs revenue growth.”  Forgive me, but that’s not going to win any profundity ribbons, gang.  Every public company needs revenue growth unless it wants its stock to decline at some point.  Recognizing that is probably less useful than recognizing a blue sky on a clear day.  What would be useful would be for companies who need revenue growth to look at the implications of that need.

Buyers will spend more on IT if they can obtain a benefit from the spending, such that the excess of the benefit over the cost exceeds their ROI target.  Probably every CFO on the planet and most first-year students of accounting or economics would know that.  So it follows that if you want to sell more stuff so your revenue increases, you should provide your buyers a greater benefit.

The “benefit” of IT is in almost all cases associated with improved productivity, which means that it can make people work more efficiently.  I’ve personally watched our industry progress from punched card processing to analyze transactions after the fact, to real-time systems and now to point-of-activity empowerment via mobile technology.  The problem is that we tend to think of these steps along the path as being driven by technology.  We had mainframes, then minicomputers, then PCs, then smartphones.  We forget that the reason why these technologies succeeded is that they filled a need, provided a benefit.

For much of the summer and fall, the Street has been whining about the lower levels of carrier spending.  Why are operators dragging their feet on capital spending?  It must be some complicated financial cycle, perhaps the juxtaposition of several refresh cycles that all happened to be in the wane at the same time, right?  Well, why couldn’t it be the fact that operators are earning less revenue per bit every year, and are thus not inclined to increase spending per bit?  Again, it comes back to benefits.

For IBM, though, the big revenue shortfall they just reported is very bad news.  Of all the tech companies we’ve ever had, IBM has been the very best at navigating the twists and turns of the relationship between IT and benefits.  I’ve blogged at past IBM earnings announcements that IBM seems to have lost its way, and I think now it’s clear that they have.  What is less clear is whether IBM really dropped the ball—the problem is IBM’s alone—or whether IBM’s challenges are simply a litmus test for the ills of the industry.

Tech in the last 20 years has been revolutionized by populism in a business sense.  We have seen an enormous expansion in the market for computers, for networking, because we’ve extended computers and networking to the masses.  But where do you go after you’ve done a mass market?  An intergalactic market?  That’s Cisco’s challenge with its “Internet of Everything” story; it’s hard to see what the next tag line would be.  And all of this is foolish for the same reason (which isn’t simply semantic).  Increasing revenues by increasing total addressable market will eventually run out of steam because you end up addressing the total market.  At that point, you have to increase ARPU.

In enterprise IT and networking, which is where IBM is, increasing “ARPU” means harnessing more productivity gains so you can justify higher IT investment.  The problem IBM has had for the last five years is that, as my own surveys have consistently showed, it lost strategic influence with buyers by not being on the leading edge of IT justification.  There was a time when IBM’s views commanded senior management attention automatically; those times have passed.  IBM needs to get back in the lead by showing it has new and credible and different strategies for applying IT to productivity.  They started, belatedly, down a track to work with Apple to develop mobile symbiosis with IT for point-of-activity empowerment, but all they’ve done so far is announce the deal.  They need to show results.

For networking and IT in the broader sense, it’s a consumer market.  The problem with that consumerism is that growing TAM can be accomplished only by lowering costs, which means that there’s a downward pressure on ARPU at the same time there’s a hope of growth in the total market base.  We know from enterprise IT that you can saturate a market—there are only so many “enterprises” possible.  It should be obvious that it takes years to build a new consumer, and that at some point you can’t look to population growth as your strategy for revenue gains.

IBM in IT and Cisco in networking have both been sticking their heads in the sand.  IBM has wanted to believe that companies would figure out their own paths toward higher per-worker investment; they have not done that.  Cisco has wanted to believe that consumer pressure to do more online would force the network operators to spend more on switching and routing even if their ROI on those investments falls sharply.  We are seeing, in both networking and in IT, the signal that this sort of silliness just can’t be tolerated for much longer.  The market will impose logic on firms who refuse to impose it on themselves.

But what I find the most astonishing about all of this is the response toward SDN and NFV.  Networking is an enormous market.  IT is an enormous market.  SDN and NFV create a kind of shunt between the two, to allow an IT company to become a networking giant or vice versa.  Talk about TAM gains; you could potentially increase the size of either the networking or IT markets by stealing from the other.  Cisco could become “the new IBM”.  IBM could become the “next Cisco”.  With a stroke, the problems of one space could be solved by robbing from the other.  So why is nobody doing this?

You can see my concern here, I’m sure.  Have we gotten to the point where we want easy answers and social-media flips instead of incumbent insight or real investment in a revolutionary technology?  For all the hype about the relentless progress of SDN and NFV, the fact is that neither is progressing relentlessly.  We can see, in both areas, the need of network buyers to do better.  Does “better” mean cutting costs by 30% or 40%?  If that’s the case, then winning for the Cisco’s of the world will look a lot like losing.  Same with IT; IBM can introduce cloud computing and new software paradigms, but unless those introductions bring new benefits, their introduction will succeed only if they lower costs to the buyer.  That means lowering IT spending.

IBM is telling us that we have a systemic problem of benefits here.  We’d better listen while there’s time.

SDN and NFV are revolutions in a sense, at least.  They both offer a radical new way of looking at traditional network infrastructure, and that means that were they to deploy to their full potential they could change not only how we build networks, but what vendors make money on the deployments.  A lot of really good, and bad, things can happen to people in the networking business.

But what will happen may be a lot more pedestrian.  The future of SDN and NFV is a classic example of the “irresistible force and immovable object” paradox.  It made for a nice song in the days of my youth (“Something’s Got to Give” for those interested, a theme I’m sure you know I’ll be returning to here).  It’s likely to make for a messy five years or so, and thus it’s important we understand what the “forces” and “immovable objects” are in my analogy.

Let’s start with the force of declining revenue per bit.  Networks produce bits as their product.  Yeah there can be higher layers to deliver experiences, but the network itself is a bit-producing machine.  Network equipment moves bits around, and as the price of using these bits declines in marginal terms (price per bit), there is corresponding pressure on equipment vendors to provide the bit-producing gadgets cheaper.  SDN and NFV are not transforming carrier capex, what’s transforming it is financial pressure.  If SDN and NFV don’t present any more favorable cost points, either something that does will be explored or eventually investment in bits will slow and stall.

There’s a financial immovable object, too, which is the residual value of current infrastructure.  Operators have hundreds of billions of dollars of sunk costs, assets they’ve purchased with strung-out expectations of useful life so they’re written down over a period of years.  If an asset with two years of a five-year depreciation cycle is replaced, you bear 40% of the cost of that asset (assuming straight-line depreciation) when you toss it.  That’s over and above what the new gadget costs.  That means that any new approach that comes along will likely have to be gradually phased into the network to avoid big write-downs.  That, in turn, creates a pressure on buyers to stay the course, and in particular to manage their expected benefits and expected costs very carefully to avoid having to go through another replacement cycle a year or so down the road.

In the network operator space, over the last ten years, we’ve experienced rapid declines in revenue per bit.  Wireline broadband was impacted first, but you can see that as users shift more to mobile services we’re also seeing declines in return on infrastructure for mobile.  It’s these declines that are putting pressure on the vendors, not onrushing SDN or NFV.  Some operators are fleeing their home markets to invest in services on other continents because they can earn a better return there.  We got rid of regulated monopolies in public networking in the ‘90s, and so the operators of today have as much a right to earn a profit and shareholder return as the vendors do.  That may turn them into businesses less dependent on bit-pushing.

Obviously we get now to the “something’s got to give” phase.  If you define return on infrastructure as your total service revenue divided by your total cost of network ownership, you have to raise the former, lower the latter, or both.  What could be done?

Capital cost management is an obvious approach, and in fact it’s the one that drove the founding of the NFV Industry Specification Group about two years ago.  The notion was simple; shift from custom devices to hosted software-based features on commodity servers and save money.  The problem is that operators quickly realized that the gains likely from this source were less than 25%.  One operator’s response to that was “If I want those kinds of savings I’ll just beat Huawei up on price.”

Why isn’t 25% enough?  In part because of the financial inertia existing infrastructure poses; we can’t change the network quickly so it would take three or four years for net benefits from NFV to be fully available.  In part because NFV is a lot more complicated than just sticking a gateway device at the edge of a customer network.  Read the ISG’s public documents and you see all the steps they want to support—scaling, optimization of selection of locations…you get the picture.  Complexity costs, and even in today’s networks the total operations costs make up about half of TCO.  Suppose we cut capex by 25% and raise opex by 30%?

This is how we got to our current vision of what SDN and NFV could do—they could improve operations efficiency and enhance service agility, raising revenues.  These benefits are in a sense more credible than capex reductions—we can’t disprove their value.  The only problem is that we can’t really prove it either.  Just how do we improve operations efficiencies with SDN or NFV?  According to operators they’ve not run trials that can establish the operations efficiency of NFV or SDN, largely because there is at the moment no firm way of operationalizing either one of them.  We’re hearing a lot about how faster deployment could lead to higher service revenues, but what it really leads is to revenue acceleration.  If somebody orders a corporate VPN with a bunch of features and you can deliver it two weeks earlier, you get two weeks of revenue.  I saw an article that said that could increase service revenues by 4%.  Wrong.  It only applies to new services, and it presumes that the customer would be prepared to accept the service two weeks earlier in all cases.  My spring survey this year asked buyers how much two weeks’ improvement in service availability would change their total spending for the year, and the result was chilling; a quarter of one percent was the consensus.

We are almost exactly two years from the seminal white paper that launched NFV, and over three years from the dawn of SDN.  We’re busily defining protocols and processes, but are we addressing those irresistible forces and immovable objects?  Not yet, but I think we will be.  Every day that we move forward is a day of greater pressure on operators to improve revenue per bit and return on infrastructure, and a day of lower guidance from equipment vendors whose own plans are starved by buyer budget constraints.  Watch this market, particularly operations, in 2015 because (let’s all sing it!)  “Something’s got to give, something’s got to give, something’s got to give!”