Month: April 2014

Any time somebody makes a networking announcement these days, they seem to enlist a Heavenly Choir to sing “SDN!” or “NFV! In the background.  Most of the time, song is about all there is to the announcement.  Yesterday, Overture Networks announced something for SDN and NFV without the choir, and in fact may have announced the most understated NFV asset of all time.

At the basic level, Overture Networks announced the availability of the components of its Ensemble OSA framework for service orchestration and management.  Ensemble Service Orchestrator (ESO) is the controlling logic for lifecycle management of SDN/NFV services, and Ensemble Network Controller is the link between ESO and standard network hardware.  The final piece, Ensemble Solution Pack, is a combination of pre-integrated higher-layer service features that augment business connectivity services, and an ecosystem to encourage contribution and development of additional features.

We’ve had stories about SDN, NFV, and business virtual function deployment before.  RAD has its “Distributed NFV” that creates a premises platform for hosted functional extensions.  NetSocket uses a server-like appliance to provide a very generalized edge platform on which functions can be hosted.  Cisco and Juniper also have device-hosted examples of service chaining, the same application that Overture focuses on, which they variously call “SDN” and “NFV”.  On the surface, the Overture story seems more of the same.  It’s not.

In my current vision of management and orchestration, we have a two-layer model where some form of management/orchestration rides on top of a series of “Infrastructure Managers”.  One of the “forms” of management/orchestration the model recognizes is “Service-Specific Orchestration”, and the idea is to say that some operators wouldn’t necessarily need a complete solution for MANO, just a solution that works for the specific services they’re offering.  Overture, on the face, is an SSO approach focusing on the union of NFV principles and carrier Ethernet.  That’s a fairly narrow mission, but what makes Overture different is that they did something broad and general and are only positioning it for a narrow mission.

Most of the service-chaining or distributed NFV or edge NFV offerings presume that there’s some high-level process elsewhere doing most of the NFV heavy lifting.  Thus, they are more like Infrastructure Managers in my terms, rather than complete NFV solutions.  If there’s no higher-level process up there to appeal to, then functionality is limited.  Right now, most of the time, there won’t be.

Overture Ensemble OSA is applied as Service-Specific Orchestration but executed via a fairly generalized Infrastructure Manager that could support both virtual-based (OpenStack) and “real” infrastructure (primarily but not necessarily exclusively Overture’s own carrier Ethernet gear).  Overture includes real orchestration based on the Business Process Model and Notation (BPMN 2.0) framework.  They also provides a lifecycle-based approach to NFV that starts with the on-boarding of virtual functions and transitions through to the “Operate” and “Maintain” phases of service and service template evolution.  Finally, they have something called Ensemble Service Intelligence that provides a management-repository model for decoupling and composing management data.  I need to look a bit more at this part of the offering, but on the surface it looks promising.

One reason this is different, even unique, is that Overture has accepted what I think is the most important of all NFV premises; you must support network functions out of the box, without customization, to be VNFs.  There are no proprietary APIs to write to; everything including basic parameterization of VNF images can be handled by ESO.  Overture does provide, through its Solution Pack strategy and partner ecosystem, pre-configured and integrated VNFs but it would be possible to on-board pretty much anything that could be made to run in a VM.  They also support both in-cloud and on-device hosting of virtual functions, and can optimize function placement based on policies (via BPMN).  Operators are starting to realize that proprietary VNFs with vendor-specific APIs for management and orchestration are no more open than proprietary boxes, and Overture’s approach could get them out of that mess.

And it goes on.  The Overture model lets service architects build service components from primitive building-blocks and catalog the result, making it then a building-block to be dragged into (literally, via a GUI) a higher-level service.  They also support both virtual-function and legacy devices, SDN northbound models, multiple controllers, and so forth.  There’s even horizontal scaling of ESO domains, either to work-share or to divide up infrastructure.  That means that the architecture supports basic federation.  All of this adds up to something that is aimed at creating my “structural” level of orchestration, but with the twist that the “structures” can be built up from complex primitive services.  That positions Overture at the low end of functional orchestration, which is a position a few others aspire to but none have demonstrated with a real you-can-order-it product.

There are specific things that you need for functional orchestration that Overture doesn’t purport to have, including strong integration with OSS/BSS systems, explicit multi-operator federation, totally open infrastructure support, and totally derived management.  The interesting thing for me is that they may not purport to have this stuff, but they’re not far from delivering it.  Their blurring of functional and structural orchestration boundaries may be a very good way to tie all the disparate NFV trials operators are embarking on.  If Overture works on that mission, they’d likely be induced to add in many of the features they’re missing, to the point where they might be able to link to open-source tools at the operations level to do the rest.

The net is that  Overture’s Ensemble OSA is pretty darn close to being not just a Service-Specific Orchestration strategy but a complete NFV MANO implementation.  Certainly it’s as close as any actual product offering that anyone has demonstrated to me, and closer than most of the stuff that some of the big vendors have announced.  It’s going to be interesting to see how it could be married to an operations-level toolkit, because that combination could give the Heavenly Choir I mentioned something to sing about.

I’ve blogged quite a bit about management and orchestration and the management challenges of next-gen services.  Connection services are largely defined by their management challenges, since they connect users and experiences rather than creating features themselves.  When we look at more advanced services, leading up to the cloud and SaaS, it’s a different matter.  For these services we have a kind of fork in the road—service management on one side and service logic on the other.

Most services have an architecture in a service logic sense, meaning that they have a model that describes how the features of the service, hosted somewhere, interact with each other, with the underlying connection services of the network, and with users.  In most cases today, the logic and architecture are created by the relationships among the devices (switches, routers) that create the service.  A service like the Internet, though, has a distinct service architecture because there are feature elements that support basic connection capabilities—things like DHCP, DNS, NAT—that fall outside the devices that push the bits.  Service functionality may not be dead in its tracks because you’ve lost DNS and DHCP, but the average user of the Internet couldn’t get online or do anything there without them.

In the area of network services, we’re confronting the notion of a service architecture most directly in the evolution of NFV.  The more you say that network functions, having been virtualized, now have to be instantiated and integrated in some way, the more at risk your service is to having some piece not working.  When you deploy a series of virtual functions you use a MANO process to do it, but once deployed these functions create a service architecture that has to represent the functionality the user expects.

This also happens in componentized applications—classic “SOA” or service-oriented architecture.  The “work” of the application is passed between components in some way, usually through some kind of service bus and perhaps mediated by something like BPEL.  Components without workflow are just anarchy; they don’t add up to any cohesive, consistent, or even logical experience.  Workflows are created by steering principles that the service architecture (in this case the application architecture) defines.

One of the questions this all raises is whether we need to have a service architecture template or framework for advanced componentized services of any sort.  We might not have a single model of workflow for a componentized application, for example, but we do have standardized components from which all the workflows can be built.  Such an architecture could define not only standard ways that components could relate to each other to do standard things (access LBS and social presence, for example) but also provide a framework to introduce management tools based on dependable principles.

All cooperative services need cooperation, and all componentized services, multi-stakeholder services, and composed/orchestrated services are cooperative.  Right now, we leave it up to the component designers to frame interfaces, and that’s OK as long as we recognize that defining chapters in an arbitrary language means either imposing a burden on the reader to be multilingual or a burden of translations.  A little order up front saves a lot of effort down the line.

Even at a basic level, though, service architecture issues are complex.  Virtually all service processes have to be visualized as state/event activities (finite-state machines to purists) in that they are stateful because people are contextual, and they are event-processors because there’s a lot of stuff inside a service and linked with it as a user/resource that might end up demanding attention.  The simplest model of a service architecture is the state/event table that associates handling instructions with each combination of service state and event.

But what about situations where you say “if I get this condition and that condition and maybe this additional thing all here, in close proximity, then I need to recognize that as being something special, something different?  We have “Complex Event Processing” systems that look for that sort of thing, and these are particularly useful when we’re looking at a stream of stuff and trying to decode events out of the mess.  Think of CEP as a kind of real-time correlative analytics, and if you use it right you can often simplify the state/event relationships by reducing the number of times you have to use states and events just to see if you really have a significant event in the first place.  Our individual this-and-that combination would need states to decode; with CEP we might not need them.

This sounds complex, but not all services will have this kind of service architecture problem.  It’s possible to visualize many mobile services as being brokered through the device app itself.  It’s also possible to simplify the problem of coordinating activities in a complex system by having a series of “function-broker” elements that perform high-level tasks by invoking a more complicated set of underlying services.  For example, imagine the hypothetical service “IsShopping” or “IsBusy”.  We could call one with the identity of a user (“Tom”) and find out based on LBS, calling behavior, search or app activity, habits, and so forth what the probability of “Tom” being in the referenced state.  Now we don’t have to orchestrate that complexity into an application.

But, of course, as Heinlein once said, “There’s no such thing as a free lunch”, meaning that disguising complexity with agency simply moves it into the agent.  It does make a helpful point though, which is that as we move into advanced service architectures, we’re likely to find function hierarchies to be useful tools.  Create abstractions that envelope stuff to help make the higher-level processes more agile with less effort.

You may see in this a similarity with service management too.  I’ve advocated “orchestrating” management and deployment of services, and it just might be possible to think of service logic in the same way, composing workflows in the same way that we compose the service deployments or management processes.  Unifying service logic and service management, at least in terms of creating a structural model that defines both and thus allows both to be derived from a single “picture” would be a help for all in an era where service complexity is likely to explode to the point where we’ll all need help.

We live in an age of virtualization, abstraction.  We’re facing an onrush of changes in our basic technology platforms driven by the cloud, by SDN, by NFV.  We’re told that these new technical options are more, or maybe less, secure.  According to my fall survey of users, nearly 90% of businesses said that they felt that security concerns would be greater with new technologies, but at the same time almost 80% felt the new technologies would help to address security.  It sounds pretty confused, but it may capture the issue with security in our onrushing virtual age.   So let’s look not so much at what we know can be done (which we have little practical history to validate) but at what we know cannot be done.

The first thing we know is that you cannot make a give service model secure by implementing it differently.  If you look at things like hacking and DDoS and other Internet security problems, they’re problems related to the fact that the Internet offers uniform addressability and at the same time anonymity.  You can initiate a packet that doesn’t carry your return address (if you don’t expect a reply), and you can send to anyone who has an address in your address space.

We hear that SDN would eliminate these kinds of threats, but the fact is that we could eliminate them now if we wanted to surrender one or both of these Internet service-model attributes.  The fact is that there are things that SDN could do with security, but we don’t hear about them because they would create a fundamental change in the IP service model.  That’s hard to harmonize with current infrastructure and also with our culture of leaving the Internet alone.  So in this respect, don’t expect any good security outcomes any time soon.

The second thing we know is that you cannot allow any shared infrastructure to exist in the service data plane of a tenant.  Think about it; suppose your competitor can address the switches and servers that your company uses for cloud hosting, SDN application control, or NFV virtual function elements.  You’d be OK with that, right?  Yet today we have control-plane and management-plane visibility to all the elements of infrastructure in our “network”.  We can’t have true tenant isolation in the cloud if we can’t isolate all the shared stuff from all the tenants.

One seldom-recognized corollary to this is that you can’t make management interfaces to shared server/platform and network devices visible to the tenant networks or applications.  A MIB that gives you control over a shared switch lets you diddle with its behavior to suit your own interests, but that diddling might be cutting off the other tenants.  In a virtual network, everything about management must be virtual or you have a completely insecure situation with no possible limits to your risks.  Management APIs are the biggest Achilles’ heel of virtualization today and we’re not talking about that risk enough, even in NFV discussions.

Speaking of NFV, the concept of cooperative virtual function  components creating experiences creates another risk, one that is in fact shared with cloud applications or any componentized service.  We know that you cannot allow anything to run that cannot be positively authenticated as being what it’s representing to be.  All forms of dynamic binding of elements into services or applications creates the risk of not only inviting the wolf into the fold, but cloaking the wolf in a sheep robe before the introduction.  And guess what?  Signing stuff per se isn’t the answer.  A component might be perfectly good in some role or another, and come from a known source, but create fatal instability or security compromises when it’s introduced somewhere else.  In componentized services and infrastructure, signature must be role-specific, which means that when we bind stuff into cooperative behavior we authenticate that the pieces bound will serve as we expect.  Yes, we have to start with who provided this component and what it is, but we have to go beyond that.

That introduces another thing that we know, which is that secure, stable, componentized applications and services cannot allow components to bind other components directly.  You can’t let Thing A load and run Thing B anymore.  You must always demand that components signal for the loading of something, even if that something is another copy of itself being created for scale-out.

I’ve always disagreed with prevailing practices and even emerging NFV specifications over this issue.  Scaling something creates both a major change in functionality and an opportunity to introduce our wolf again.  What we’re saying is that in a cooperative, multi-component, system every management lifecycle process has to be outside the service plane where it can enforce absolute security/compliance practices without interference or being bypassed.

And encryption of data paths?  We know that in a cooperative service framework with significant component reuse we cannot make traditional public-key systems scale to support the number of component/role combinations we might have.  Too many pieces have to know too much, and anything that knows your keys and my keys knows how to leak stuff between us.

We have had incident after incident relating to compromise of security certificates and public keys, yet we keep believing against all odds that the practice that’s failing under relatively little complexity stress today is going to succeed for us when we make even more demands on it.  Tell me how that’s logical?

I’m not crying wolf here (though I referred to one!)  I’m of the view that there are solutions available to every challenge I’ve posed, but I’m also of the view that we’re demonstrably not addressing the challenges with the available tools.  In most cases this is because all the nuances of our revolutionary technologies haven’t been explored.  It’s also true that vendors and the media have cried “wolf!” in security for everything from baselining networks to basketballs, and everyone is just worn out with the barrage of claims.  The thing is, we are at a moment in the securing of our future network and IT models where we can get the job done fairly easily and painlessly simply by addressing what we know can’t be done, can’t be allowed, right now, while the architecture is malleable and the investment in place manageable.  That’s not going to last long.

We in tech are clearly an industry in transition.  How’s it going?  That’s a question important to all, and at the same time hard to answer.  Our only hope of tracking progress is to look at some companies who represent clear paradigm shifts and see if the paradigms are…well…shifting.  Let’s try that today.

Amazon reported its numbers, and there was no sign of rampant growth no matter how hard bullish analysts worked to find it.  It’s not that Amazon is a bad business as much as that everyone is realizing that retail has its natural limitations.  For online retailers to succeed they have to offer quick gratification and low prices, and yet shipping costs are a big barrier to harmonizing these two points.  Amazon’s supposed interest in fulfillment on its own (starting a kind of inside-FedEx) is likely, IMHO, to be a foray into manipulation of the real shippers by posing a threat of at the least taking away the business Amazon has brought them.

Since Amazon never broke out its cloud growth, it’s not possible to say what it was exactly.  The main point, cloud-wise, is that the category into which AWS in all forms is lumped is the smallest revenue area, a quarter the size of Amazon’s media business.  It’s also notable that Amazon has cut pricing significantly and that it’s not reporting it plans to make a huge incremental infrastructure investment.  It didn’t even bring up AWS on its earnings call; the cloud came up only in questions that frankly Amazon’s management did not answer.

I think that what we’re seeing here is a clear indication that Amazon does not believe AWS will be their source of future expansion in sales and margins.  If they did, they’d be putting more into it, be worried less about same-day shipping and shipping costs, and be talking it up in terms of revenue expectations.  That’s not what happened and so I think it’s clear that the success of the cloud is going to be more complicated than many believe it will.  Cloudsourcing, as an unqualified opportunity, isn’t qualified.  There are special situations where the cloud is a better answer than internal IT, but not enough of them for Amazon to bet on the cloud alone—so it’s not going to do that.

One of the issues with Amazon’s cloud opportunity is the notion of project justifications.  Yes, it might be possible to save money in the cloud versus internal IT for as much as a third of all IT applications, but that’s not the issue.  You have to save enough money to provide both a return on incremental project investment and to overcome buyer risk premiums.  Right now, successful cloud projects are creating ROIs of about 34%, which is only slightly above the minimum level.  That is why Amazon is cutting prices.  And ROI may also be a big factor in Ericsson’s quarterly slip, which is my next topic.

Ericsson turned in a disappointing quarter, and their call seemed to be calling on future turmoil like the cloud and M2M as the things that will pull them back into strong growth.  I think they’re overlooking their main challenge here, which is that same ROI issue.  Ericsson is no longer a leader in network equipment, they’re focusing more and more on professional services.  That’s OK at one level, but there are some major risks with such a move.

Risk number one is that our surveys have always shown that buyers want their major integrator to be a major product supplier as well.  They are very reluctant to give professional services business to a third-party, reasoning that would only add another finger to the finger-pointing game that usually accompanies problems.  Risk number two is that buyers resist projects that are substantially professional-service costs, on the basis of the fact that without product foundation to baseline capabilities and future evolution potential for their infrastructure, they can’t be sure every new service or issue isn’t a new cost.  They’re at risk to being one-offed to death, in short.

But perhaps the largest risk is the overall cost.  Customization of a cloud, SDN, or NFV approach is sure to be more expensive than buying a solution off the shelf.  Ericsson has set itself up as a company whose stated goal of professional service dominance runs counter to any strategy of productization, yet buyers are asking more and more for product-based solutions and not customization.  I can see this in the carrier push for open source.  Can you do SDN, NFV, and the cloud using open source?  Sure, but how much you can do depends on the specific value proposition driving your project.  What is the open solution for unified service operations in the age of SDN, NFV, and the cloud?  The operators don’t know (which is in part why I’m working to publish an architecture that has minimal need for custom coding and is based on open-source).

If we knew just what justified the cloud, SDN, and NFV, then Ericsson could launch professional services to produce that, presuming they could start with a strong product base.  We don’t know it yet, and in fact we’re finding out that the simple justification that all three of these are cheaper in a capex sense isn’t going to cut it.  That value proposition, if true on a large scale, would be generating so much AWS business for Amazon they’d be justifying the capex increases to the Street and they would not be reducing prices to spur demand.  Ericsson would be making a bundle on professional services contracts to bring the revolutionary trio of technologies to everyone, and that’s not happening.

We have a tech revolution facing us, in the areas of the cloud, SDN, and NFV.  The inhibiting factor for them all, though, is the pace at which they can realize benefits, limit transition costs, and reduce the risk premium management assigns them.  That’s an architecture problem in part, but also a marginal utility problem.  Going back to the cloud and Amazon, it’s not enough for Ericsson, Amazon, or any other provider to offer something that’s “cheaper”.  It has to be cheap enough to create significant ROI, and for all three of our tech revolutions we are seeing clear indications that it’s not.

And only product can help.  We have never, in the whole history of IT and networking, had a revolution based on professional services or any other kind of “service”.  The door is still open for somebody to get the right answer to justifying and driving our tech revolution.  Don’t despair because Amazon is so far ahead; be glad they’re taking all the early risks.  Don’t be worried because Ericsson has professional services locked up; be glad they’re not locking up a product or architecture.  There’s still room for a lot of success in our triple-revolution industry.

“Got a good reason for taking the easy way out” is a good old song, and it’s also a pretty good theme on which to hang the analysis of a couple of news items.  Apple had an OK quarter but the financial sector thinks it’s coming to an end of the easy money period.  The FCC has formally indicated it will end the broad interpretation of “neutrality” that VC-biased Chairman Genachowski had initiated, and that may mean the end of the social-network-startup craze.

What do these things have to do with my song, you ask?  The answer is that there’s a good reason why Apple has relied on consumer faddism for profit, and why OTT players and VCs have flocked to build consumers of capacity and forget the production side.  The reason is that it was easier that way, but we should know by now that all easy things tend to end someday (to paraphrase a different song).

Let’s start with the FCC, and here I want to point out that in the mid-90s I was the co-author of the first RFC to address the need for peering and settlement on the Internet.  At that time, which was before the notion of media-driven tech hype waves and the dot-com boom, the Internet community itself was largely behind settlement.  Boardwatch, the ISP pub of the time, even suggested that if the Internet didn’t police itself with respect to peering policies and prices, they’d have to recommend the FCC step in.  That says a lot.  But neither of these things happened; we took the easy way out and to promote “growth” we initiated practices that were based on unlimited usage and bill-and-keep.  Since that time, we’ve seen two levels of distortion in the Internet created by our ad hoc decisions.

First, the need to have content delivery with some reasonable QoE encouraged providers to cache content locally to the access ISP to eliminate peering transit delays.  This gave rise to CDNs, and make no mistake, CDNs are “paying for handling” just as much as Internet QoS for a fee would be paying for it.  Make no mistake, CDNs would inhibit the entry of “small” players into the multimedia services markets just as much by raising the charges VCs would have to cover and lowering their ROI.  And worst of all, we spent money on researching and deploying ways of generating traffic and not on carrying it.

SDN and NFV and the cloud are not in any way at risk because of a shift away from Genachowski’s position on settlement and provider-pays QoS.  The opposite is true.  If we are forced to face the rational truth—everyone in an ecosystem has to profit to sustain their role—then we know that rational exploitation of these new technologies depends on creating a sound financial path toward that profit for all concerned.  All three could help operators, could improve our whole notion of “the Internet”.  But investing in them is going to be critical, and operators are the ones who build the network.

What we have to watch out for here is insuring that “best-efforts” doesn’t become “explicitly crappy” by osmotic pressure.  If operators can charge for premium handling then they have an incentive to let non-premium handling slide.  The key to making sure that doesn’t happen is the notion of full settlement.  If any player online knows that there are some paths better than others, and if consumers know that too, then ISPs who decide to widen their premium opportunity by suppressing normal QoE will find the market is more effective at stopping them than regulations.  And in any case lowering the “effort” of “best-efforts” isn’t much of a risk because that could have been done all along, even under Genachowski’s unenlightened leadership.  The more we let Internet transport become a business end-to-end, the faster it can become a good one.

Now let’s look at Apple.  They’re a cult computing company that became a success through a shift into consumer electronics.  They played effectively on a combination of style and elitism, a powerful combination for as long as you can exploit it.  Apple had a better OS than Microsoft before the first iPod came along, and they could have funded a cadre of technology excellence in the software and cloud space just as easily as pushing a new i-something model.  They didn’t because the profits were easier to achieve, faster to realize, with another i-gambit.

If you’ve read my stuff before, you know that I’ve been warning that you can’t take personal electronics to unlimited ends.  Even Cisco’s “Internet of Everything” is a cheap ploy for the broad market, and for Apple wearable or personal electronics is simply an invitation to find reasons why your belly-button needs to communicate with your elbow.

Apple needs to be focusing on point-of-activity empowerment, meaning the adding of value to network relationships by adding insight and context into information requests.  That’s very much a cloud mission, and Apple is the most behind of all the major technology companies in exploiting a compelling cloud vision.  Something that would make sense in this critical mobile space wouldn’t be much harder than doing another i-thing, and what Apple needs to do now is understand they’re at a crossroads.  The easy way out turns into a slippery slope very quickly.

That’s also true for “neutrality”.  We are going to have some issues here, some changes, some risks.  Regulators could go too far, not far enough, or move too late.  Of the risks we face, the ones I fear are the latter two.  Public policy in telecommunications has to accommodate, as a UN report once noted, both the quality of consumer experience and the cost, but also the “health of the industry”.  I favored full settlement and QoS charging almost 20 years ago, and I favor it now.

Let’s get on with it, Apple and the FCC.  Remember the end of that song:  “…a one-way ticket, yeah.  It took me soooooooo long to find out, but I found out.”

Juniper reported their numbers yesterday, and so did one of Juniper’s key clients, AT&T.  Just a day before, AT&T had announced that Juniper (and Amdocs) were added to AT&T’s “User-Defined Network Cloud”.  Now, some contrasts between the two companies’ reports create a worthy topic for analysis.

When you read through Street analysis on AT&T, it’s clear that the only thing that’s making much of an impression is wireless growth.  This isn’t surprising given that wireless is the key driver for profit for all the operators, and in fact the bright spot for capex that would be most likely to drive vendor success.  Every analyst who covers AT&T talks about the company’s prospects in continuing to add customers, the notion of reduced churn, and whether AT&T can upsell existing post-pay smartphone customers to tablets.  There isn’t a single word about “infrastructure” or the cloud program Juniper was selected for.

The benchmark comment on Juniper from ISI makes an interesting parallel read.  They say that they’ve “…long viewed Juniper as the ‘network innovator’…” but that like many such companies, Juniper had “reached too far seeking growth in adjacent markets and lost sight of OpEx discipline.”  The company was now coming back to its roots by imposing a stark cost-cutting program and shedding some of those adjacent lines of business.

Juniper’s primary area of growth was switching, which can reasonably be linked to the cloud (and thus to Juniper’s AT&T Domain 2.0 status).  But the number of cloud mentions in AT&T’s call was limited—three.  Juniper mentioned it over 30 times.  What this reflects is the fact that while cloud investment might mean a lot to the vendors, it’s still pretty much background noise to the network operators, who are faced with the same dilemma their suppliers are—making the Street happy about the current quarter.

I’ve known, and worked with, Juniper since literally the week their first CEO started his job.  The company has always had strong technology, and their vision of what was next—which included the first articulation of the cloud opportunity by any vendor—has also been unparalleled.  The problem they’ve faced has been one of marketing/positioning.  Only one Juniper CMO has ever shown the necessary fire to drive the company’s vision forward.  That one left years ago.

The notion that Juniper “reached too far” in seeking growth is valid only when viewed through the lens of this marketing deficit.  Juniper’s MobileNext family could have been a strong contender in the space that the Street is now watching most closely—wireless.  They had a content strategy that could have been one of the top approaches to that other important space.  But these strategies lived only in the technical sense.  Juniper could never explain them to outsiders, never link them to the specific customer business goals that would have validated them with buyers and earned revenue.

There’s no option other than “reaching” in the network equipment role.  Anyone who’s not spinning their own private delusions surely knows that without a Congressional mindset that effectively bars Huawei from selling into the US carrier space, Juniper would not have seen anything good in terms of top-line growth.  Routing and switching are commodities, and you win in either space mostly by being an ecosystemic player.  AT&T’s notion of creating roles and zones of procurement have helped save Juniper from the real risk, which was not reaching enough.  And that is the risk that Juniper now faces.

Juniper cannot win in “the cloud”.  You build clouds with servers and software, and Juniper has none of the former and has never “reached” appropriately in the latter space.  If any network vendor will own the cloud, that vendor is Cisco because of UCS.  The Street’s determination to force strategic contraction on Juniper is simply pushing it into a niche that can never again be defended against commoditization.

The Domain 2.0 win Juniper has achieved is interesting considering who else was named—Amdocs.  If you talk to service providers today (or in fact at any point in the last eight years) you’d hear that they need vendor support for their transformation process.  One area of critical concern is the junction between services and the network, the place where service agility and operations efficiencies are created.  Juniper’s only hope, then and now, is to utterly own that space.  It’s represented by a combination of SDN and NFV, and that combination is another of the things Juniper’s positioning has booted.

Contrail, in its technology, is a responsible solution in the SDN space, but you don’t need an SDN controller win to pull Contrail through, and demanding one as a condition of success will have the inevitable and unfavorable result of promoting the “nothing” path of the “all-or-nothing” choice.  Juniper needed only to look above the northbound APIs to find differentiation.  That’s also where NFV lives.  But to do any of this means both a strong marketing position and an understanding of the software side of networking.  Juniper’s old CEO from Microsoft (Johnson) didn’t understand network software.  The Street has made it clear that they want the new CEO only to understand how to shed businesses and people to cut costs.

Part of Domain 2.0 is aimed at creating operations layers that will pull service value up out of the network and into hosted software.  What AT&T would like more than anything else is for that software to be totally open-source.  A year ago, I think that operators would still have accepted the idea that their vendors can lead.  Now, the problem is that the Street is imposing requirements on those operators as much as on the vendors, and these requirements dictate revolutions in operations.  Amdocs is the real potential winner in Domain 2.0, but there would still be room for Juniper (and others) to build something that acts as the shim between the highly monolithic and historically unresponsive OSS/BSS space and both the agile customer opportunity and the evolving network infrastructure.  But time is running out, unless Amdocs boots their own chance of creating that layer.  And they well may do that.  For Juniper, now, only mistakes by others can save them from themselves and their parasitic financial friends.

One of the issues I’ve gotten concerned about regarding NFV is the openness of a vendor’s NFV architecture.  The NFV ISG clearly intends to have a high level of interoperability across NFV elements and solutions, but there are some factors that are hampering a realization of that goal.  Most of these aren’t being discussed, so we may be on track for some NFV grief down the line.

The first issue is incomplete implementation of NFV despite claims of support.  There are three elements to NFV according to the specifications; the MANO or management/orchestration core, the virtual network functions (VNFs) themselves, and the NFV infrastructure (NFVI).  According to my rough count, less than 10% of NFV implementation claims even represent all three functional areas.  It’s not necessary to actually offer everything, but what I think a vendor has to do is express where each of the three pieces are expected to come from and how they’re integrated with their own stuff.

The biggest NFV offenses come from vendors who provide NFVI or VNFs and call it “NFV”.  Virtually anything could be claimed to be part of NFV infrastructure.  For servers and platforms, all you really need to do is be able to run a VNF, after all.  For network connectivity, you need to be able to support SDN or some form of explicit virtual network provisioning.  The question is whether an “NFVI” vendor offers a handler that exposes a logical abstraction of their infrastructure.  NFVI credibility depends on that.

The second issue in openness is supersetting of the VNF-to-MANO interfaces.  I am not a fan of the idea that VNFs even talk directly with MANO, simply because there’s no MANO today to talk with and thus no current code that can call on MANO services could be available.  That implies everything has to be rewritten for NFV.  However, even if we’re willing to do that, it’s already clear that vendors are going to define their own “platform services” for VNFs that are not called for or specified in the NFV documents.  That means that a given vendor’s VNFs could pull their MANO through because nobody else could support its extended VNF-to-MANO interfaces.

Every NFV implementation has to start with something, and that means that there will be a limited number of VNFs to be used.  If those VNFs can create a kind of walled garden by their relationship with proprietary extensions of the NFV specification for VNF-to-MANO connections, then every new service might end up pulling in its own MANO, and any hope of securing efficient operations is lost.

The third issue in openness is that of management integration.  The NFV ISG presumes that there will be a management element integrated with the VNFs, and that this element will then expose management interfaces and capabilities.  There are several issues with this approach, IMHO, but the “openness” problem with that is that the way by which VNF managers manage the subordinate VNFs isn’t standardized.  A management system could be pulled into an NFV deployment by the customized management approach a vendor offers, then that management system could pull in the vendor’s other VNFs and even NFVI.

Of the specific problems we face in NFV openness, two stand out.  One is the challenge of abstract infrastructure.  The ideal option for NFV would be to have a set of “models” that define both hosting of virtual functions and network-building, in such a way that any server and network platform (respectively) could be harnessed to implement the model.  That includes all the current network devices and EMS/NMS service creation interfaces.  I’ve yet to see a truly compliant standard approach to this kind of definition; OpenStack’s Nova and Neutron come close, but that’s all.

The specific issue is the management side.  Here we have to deal with a couple of new wrinkles in modern virtualization-based services.  One is that any “virtual” or “abstract” service is presented to higher layers as an abstraction, and abstractions have to be managed as what they look like and not just by managing the subordinate elements.  A buyer who gets a virtual branch access device needs that virtual device to look like the real thing, yet the NOC that supports it has to see the components.  This kind of management dualism is critical.  The second wrinkle is that unless we have an accepted standard for higher-level orchestration—one that recognizes all the elements of the service end-to-end, we can’t cede management tasks into MANO.  Doing so would mean that an implementation of MANO would have to rely on non-standard mechanisms to present management views and parse a tree of service structure from the user level down to the resource level.  That’s the end of openness.

This raises what might well be the most critical question for NFV openness, which unfortunately may not have anything to do with NFV per se.  NFV is about virtual functions, yet it’s likely that no future service will have more than about a third of its functionality virtualized.  We’ll still be using traditional VPNs to provide connectivity to all those virtual branch access devices.  NFV’s MANO is not directed at solving the management/orchestration problems for these complex services.  Nothing else is either, at the moment.  So the question is whether we can define how part of a service is managed/orchestrated without knowing the big management/orchestration picture into which it must fit.

Some analyst firms have indicated that NFV field trials will start this year, and they’re right.  Many say that no real deployments will happen this year, and they’re sort-of-wrong there.  There will be deployments that vendors and even operators will represent as being “NFV”.  Those deployments will be almost totally lacking in the essential elements of an open strategy.  Part of that is because the ISG specifications for NFV are not complete so they can’t be complied with yet.  A bigger part is that most vendors don’t want open NFV, they want an NFV solution that only they can supply.  That kind of opportunism is to be expected in a profit-driven world, but that doesn’t mean we have to turn a blind eye to it.  If operators want an open NFV approach, it’s going to be up to them to force the issue—or more directly force the resolution of the issues I’ve exposed here.

We’re starting to get some earnings reports from tech bellwethers now, and so it’s time to take a reading of the space and try to assess how tech might develop through the balance of 2014.  We’re still early in the game, particularly for networking, but we do have some insights from the IT hardware side available in Intel’s and IBM’s numbers.  We’ll start with Intel, whose quarter was a combination of good, not-bad, and unexpectedly (and maybe seriously) bad.

Data center revenues were up for Intel, particularly for cloud-related stuff, and that’s clearly a good thing for Intel.  Given that the cloud could be one of those rob-Peter-to-pay-Paul things, the fact that data center products overall were strong suggests one of two possibilities.  First, perhaps the cloud isn’t going to rob Peter as much as expected.  Second, perhaps the cloud investment leads the impact of cloud hosting on data center spending by more than expected.  I think it’s a bit of both, but mostly that the real impact of the cloud won’t come from displacing current in-data-center hosting of applications but in creating new applications that are cloud-specific.

PC client chip revenues were stronger than many had expected, though I think that it’s clear that the impact of tablets on PC sales has been overestimated.  There’s a chunk of the market that will stay with the PC for a very long time, perhaps even perpetually, and the biggest impact of tablets will likely be erosion of average selling price for the PCs, something that isn’t likely to hit Intel as hard as it would the PC vendors themselves.  However, it’s likely this is what has caused Intel to take a hit on gross margins.

The big issue for Intel is the big miss in mobile, which was down a whopping 61% year over year.  The company hasn’t been able to gain any real traction in the LTE space, largely because the Windows smartphone designs that would be most logically targets for Intel chips aren’t selling well compared with competition from Apple and Android (and likely won’t do much better any time soon).  While Intel has been successful with its “Internet of Things” activity built around the Atom CPUs, their success has been limited to vehicle entertainment systems and POS terminals.  That Intel has decided to wrap these applications into a glamour title “Internet of Things” suggests to me that they realize they’re not going to gain much in the mobile space and so they’re preparing a substitute strategy.

The challenge for Intel is that there’s no brand recognition with either of their success stories in IofT, and that where brand matters (tablets and phones) they’re not a player.  Given that it’s very doubtful that Google would let Intel do something distinctive in terms of software features to brand an Android device, Intel is again dependent on Windows no matter how many Android designs they spin out, and what Intel needs is a brand of its own, something more updated than “Intel inside”.

And “brand” is something that could come from the software side.  I was disappointed that Intel had no comment on software on their call, especially since Intel’s Wind River activity has arguably the best (and maybe only) NFV server platform story out there, and NFV servers could be the largest incremental server opportunity in the market for the balance of this decade.  Intel needs to be thinking about what IBM did, and of course that leads us to the IBM call.

IBM also had its mixture of news.  Service margins were up, but the most significant upside was that of software and WebSphere in particular.  IBM is essentially admitting to not being a hardware company in the longer term (it’s selling off its x86 and its other hardware lines were all disappointing), and they can’t be a service play alone and differentiate over others like Accenture.  Thus, software.

To me, the problem is the fact that IBM is explicitly betting on the cloud, and yet it’s not linking the cloud convincingly to its software.  In my surveys last fall, IBM was behind HP in terms of customer regard for their cloud story, even in the enterprise sectors where IBM was strongest.  The reason was that IBM didn’t seem to be able to articulate a cloud strategy as much as a series of cloud tactics.  Look at this from the call:  “In the quarter we announced a $1.2 billion investment to globally expand our SoftLayer cloud hubs. We launched BlueMix, our new platform-as-a-service to speed deployment of hybrid clouds. We acquired both Aspera and Cloudant to extend our capabilities in big data and cloud.”  Where is the strategy here?  You can’t say “My cloud strategy is to say ‘cloud” a whole bunch of times.”  I counted 31 “cloud” references on the call, but not a clear statement of why IBM’s approach was better.  OK, you can say that this was a financial call, but I think you can make the same statement about the collateral on IBM’s website.

What’s frustrating is that IBM has all the pieces, at least as many as anyone else and perhaps more.  In what I think is the critical fusion of cloud, SDN, and NFV, IBM has the asset base that maps to the right answer better than anyone else does.  Yet IBM’s position in that critical fusion can’t be explained by carriers or IBM’s customers in general.  Outside of IBM’s base, we found few enterprises who could explain IBM’s cloud position, and that was also true of carriers.

All of this still seems to be rooted in the waltz into sales/technical without taking the detour through marketing.  Marketing is what’s supposed to build your brand, to link you to the trends that matter to your prospects.  Marketing should have articulated the IBM cloud vision, made that vision compelling, and then associated the vision with specific IBM initiatives.  Should have, but hasn’t so far.

It would be risky to say that IBM is in serious trouble here, given the company’s reputation for transforming itself successfully through a half-dozen revolutions in tech.  For now, the problem is that hardware isn’t going to get better, and the loss of x86 systems is going to disengage IBM from a lot of package opportunities.  There is a cloud business for IBM to build, but they need to be able to explain just what that business is, and differentiate their vision from that of HP.  And that, friends, is likely to be the challenge for many IT and networking vendors in this earnings season.

You have to love a market that, when faced with seemingly insurmountable contradictions in business and technology trends, proceeds to generate new ones unapologetically.  We had that yesterday with the story that Sprint was considering shutting down the WIMAX assets of Clearwire, then another story that Google might be aiming to be an MVNO.  So how is it that wireless is “good” for Google and bad for Sprint?  Is it just WIMAX or something else?

WIMAX is a licensed wireless technology (at least in Clearwater form) that is likely best to support the access of “migratory” users rather than “mobile” ones, using laptops or tablets and not phones.  You could think of it as a kind of for-fee super-WiFi that could cover a much larger geography.  It’s that angle that seems to make Sprint’s decision odd—if people are jumping all over hospitality WiFi, then why kill off it’s bigger brother?

The probable reason is that hospitality WiFi is killing it.  There are only a finite number of places where yuppies and bored teens can roost to get online, and in most cases the establishments themselves are using WiFi access to attract them.  It’s free.  There are other locations like airports where network operators, cable companies or even municipalities have provided WiFi access that’s free or at least has only a modest episodic cost.  Sure, these choices aren’t going to cover that wonderful park in the city or a nice bench along the river, but they cover enough to dampen the whole WIMAX business model.

And remember, you don’t have to say that there’s no value for WIMAX, only that the spectrum would be more valuable if you used it for 4G, and that’s the deciding factor here I think.  If you look at return-on-cell, LTE is likely to do you more good, given the hospitality WiFi competition I’ve already noted.  So what this says is that the mobile user is more valuable than the migratory user.

But what can we deduce about Google’s purported interest in being an MVNO; there’s no spectrum or spectrum value involved?  For those who don’t know what that is, an MVNO is a Mobile Virtual Network Operator, a retail carrier who buys capacity on somebody’s wireless network to serve their customers instead of building out their own network.  Obviously Google would have to pay the wholesale partner for that capacity and the margins would be thin.  If Google picked only one partner they’d probably alienate every other carrier, who might then punish Google by removing or weakening their support for Android.  It’s said that Google is interested in offering its wireless MVNO service in its “Google Fiber” footprint locations, but that’s kind of impossible unless you think a mobile user in that footprint would never go anywhere else.  Google has to market and support any MVNO service nationally, IMHO.

What Google gains from MVNO status in my view isn’t fiber-footprint competition with the incumbent LECs.  Anyone who thinks Google wants to be a general access provider is delusional.  The current guys would fall into fits of unbridled joy at the mere prospect of such a move from Google because Google’s margins on that kind of business would be razor-thin and they’d have to become opponents of neutrality just to stay alive.  Nor do they want to compete with the wireless carriers; how could you undercut the guy you’re buying from, and anyway who has more wiggle room to operate at thin margins, Google or a LEC?

What’s likely underneath Google’s move is leveraging its brand.  Google wants to have a success in IPTV.  It wants to be a giant in mobile LBS, in advertising in general.  But deep inside Google knows that at some point every OTT player has the same underlying problem, which is that the global budget for advertising won’t keep their stockholders happy even if it all gets turned into online ad revenue.  The fact is that online advertising is probably lowering adspend because advertisers use online capabilities to target more tightly, reducing their costs overall.  If you stay ad-driven you’re a termite in a lifeboat—you inevitably eat your salvation.  Google has to sell something at some point. Selling means exploiting your brand.

But there are two questions arising from this.  First, Google could unquestionably deploy WiFi on a large scale, and has already done deals with retail chains and also “Muni-Fi” deals.  Given that most people do content-viewing and real searching while roosting rather than walking, could Google get more traction from its own WiFi?  Second, what is it that Google might sell to leverage with an MVNO deal?

The answers here could be related.  If you assume Google’s primary target isn’t the migratory user but the true mobile user, then it makes sense to think in terms of MVNO rather than to think about WiFi.  And second, if you assume that Google wants to sell contextual services to mobile users, then everything makes sense.

Contextual services are services that are designed to recognize what the user is doing when they make a request.  A user’s location is part of context, and so is the location of other users who are close socially, and local traffic conditions and weather conditions and perhaps who’s being called or chatted/SMSed with.  Google has a lot of stuff that establishes context in a search or query sense, and they may just be thinking about leveraging all of that stuff to create one or more mobile-paid services.

Microsoft’s Cortana personal assistant is something that just might have generated some Google concern, and of course there’s Apple’s Siri.  Everyone is trying to get to the “Her” stage, a personal agent that can accept speech questions and provide answers.  As I said in an earlier blog, “Her” is a Hollywood dream if you want to get gestalt with the gadget, but you could narrow the interpretive/response range if you could assume context generated the question.  Might Google see contextual agent applications as their money tree?  If they do, then MVNO makes sense for them.

We’re hearing a lot about how analytics is going to change networking, how they’re essential in SDN, NFV, the cloud, and maybe also critical in improving your social standing, good looks, financial health, even maybe make you run faster.  How big can “big data” get?  Apparently the sky’s the limit.  As usual, most of this is just crap, and so we need to look at the question of applying “analytics” to network services to sort out any good ideas from the inevitable chaff of marketing claims.

First, “Knowledge is Power” not “data”.  In order for “data” to become knowledge, you need the critical notion of context.  When I know that traffic is heavy, it’s nice.  If I know what road it’s on and when, it’s nicer.  If I know it’s on the road I plan to use, it’s power.  The point here is that collecting information on network behavior does little good if you can’t apply that data contextually in some way, and there are two approaches you can take to get to context.  Then you have to turn that “knowledge” into power separately.

The first approach to data context in network analytics is one of baselining.  If traffic is “heavy” it has to be heavy relative to something, and in baselining you attempt to define a normal state, as a value of variables or more likely a range of value.  When data falls outside the range at any point, you take that as an indication of abnormal behavior, which means that you undertake some action for remediation (the “power” part).  However, getting baselines for variables won’t create context because you can’t relate the conditions across measurement points with anything in particular.  Baselining, or simply range-testing in analytics, isn’t particularly helpful, and most people who do anything with it that’s useful really mean past-state analysis when they say “baselining”.

What some analytics approaches advocate is to look at the state of the network holistically, with all variables considered individually relative to their accepted range of values.  You then essentially pattern-match to decide what past state this present one corresponds to, and you accept the way that past state was interpreted as being the context of the current conditions.  The NOC said this was Friday-and-I-have-no-date traffic last time it happened, so that’s what I’ll call it this time.  Presumably, if we can determine the remedies taken last time and apply them (or at least suggest them) automatically, we can respond correctly.  However, we have to assume that our baseline map has 1) accurately established context based on past-state analysis, and 2) that somebody has created rules for response that can be applied to the current situation.  Most analytics processes don’t really address the latter of the two issues; it’s up to an operations specialist to somehow create general scripts or policies and make them runnable on demand.

The second approach to gaining context is to take a service-driven approach.  A network asserts a service set that’s consumed by its users.  Each service is dependent on resource behaviors that fulfill it, and if you understand what behaviors are associated with a given service you can correlate the state of these behaviors with the services.  Now if “Behavior 4” has a variable out of range, you can presume that means that the services depending on Behavior 4 will be impacted.

The critical requirement in a service-based analytics application is that there be a correlation between the data you collect and “services”.  That means either that you have to measure only service-specific variables and ignore resource state, or that you understand the way resources relate to the services.

Resource relationships to services depend on whether the service network is a provisioned resource or a connection network.  In a provisioned resource, you make a specific connectivity change to accommodate the service and so you presumably have some knowledge of how you did it.  In cloud networking, for example, if you use Neutron to set up connections among hosted elements, you know what connections you set up.  In connection networks, the members of the network are mutually addressable, and so you don’t have to do anything special to let them talk,  Instead you have to know how a given connection would be carried, which means an analysis of the state of the forwarding rules for the nodes.

One thing all of this demonstrates, if you think it through, is that there are really two networks here—a service network and a resource network.  There are also then two ways of looking at network conditions—based on how they impact services directly (the service-network view) and based on the health of the resources, working on the theory that healthy resources would support services as designed.

You might think this means that the service context is useless, but the opposite is true.  That’s because there are two levels of “service” in a network.  One level defines the “functional behavior” of the service and is created and sustained by maintaining functional relationships among elements, and the other defines the “structural behavior” of the service, which is created by that connection network (or networks).  Resources, or infrastructure, asserts its own services.  When we talk about a service view of something in relation to analytics we’re not talking about the retail functional relationships but rather the structural relationships—which is good because it’s the resources we have data from.

For new technologies like SDN and NFV I think this dualism is critical, both to allow analytics to be used effectively and to make operations of a network practical.  Where a “service” is coerced from “multi-tenant” resources by network/service policies, you can’t spend a lot of time fiddling with individual connected users and applications because you set up the multi-tenant connection network to avoid that.  In that case, you have to consider the whole connection network as a service.

The final point here, the “power” part of knowledge, is making something happen with what you now know.  The service-based framing of network analytics means that you have something ecosystemic you can use as context—the connection-network service you defined.  Logically, if that’s your framework then you have to be able to take service experience and pull resource conditions out of it to create your analysis, which means that analytics has to be related to some sort of service, and in a way that allows you to collect resource data for that service on demand.  This is the thing you need to look for when somebody talks “network analytics” to you.