Month: January 2014

I’ve blogged through all of 2013 that of our three “revolutions” of cloud, NFV, and SDN, it’s the cloud that’s the senior partner.  The transformational aspects of SDN and NFV depend to a very large degree on our harnessing cloud capabilities to host network features.  We’re also hearing that Amazon is on a tear, with Credit Suisse estimating their cloud revenues at $3.5 billion and their growth rate at 60% or more.  From this, you might think that our cloud senior partner is going to be a runaway success and drag the other stuff along.  Well, maybe.

The challenge for the cloud today is simple; myopia.  If you believe that IaaS by itself, the hosting of applications that could have been run on dedicated servers or virtualized ones, is a revolution, then you’re likely someone who’s avoiding real stimulation.  There is simply not enough value in IaaS-cloud versus virtualization versus just shared hosting like we do every day for web pages or email.  So the cloud has to be more to be a revolution, and it has to do more than IaaS to support SDN or NFV.  What?

Amazon has been quietly answering that question with what I’ve called platform services.  A platform service is a web service presented through a network interface via an API, and designed to effectively extend the set of APIs that operating systems and middleware normally provide.  It differs from platform-as-a-service in that a cloud architecture based on platform services says in effect “I don’t care what you do to satisfy traditional operating system or local-middleware APIs; make your own choice and build a machine image.  But in your application, do cloud-specific things using platform services that are cloud-optimized.”

Amazon has been adding platform services to EC2, ranging from caching and HTML acceleration to flow optimization and desktop-as-a-service.  All of this stuff lets you build “cloud applications” that would have been impractical/impossible without the cloud, which is IMHO the only way you can generate a lot of true cloud migration.  As large as Credit Suisse’s estimate for Amazon’s cloud revenue stream is, it represents only about a quarter’s worth of server revenue for HP or IBM.  We’re going to have to do a lot better than that to create a revolution, and that’s exactly what platform services could do.

Could already be doing, in fact.  Some of my sources tell me that almost 60% of Amazon’s cloud revenue comes from applications that have a significant platform services component, which means that it may depend on a more-than-IaaS model of cloud computing.  Furthermore, those sources tell me that at least three-quarters of Amazon’s cloud revenue growth can be attributed to these platform-service-consuming applications.

For all of the importance of platform services, we don’t really know too much about them except by example.  Obviously you don’t want to make every operating system or middleware service into a platform service because it wouldn’t add any value.  Disk operations is an example of something that could be extended as a platform service, and many cloud providers offer distributed data operations.  Caching is necessarily a platform services because you have to distribute caches to make them useful.  Amazon’s flow-related stuff (AppStream an Kinesis) are clearly platform services because they draw on specific cloud elasticity features to work.  But there are many other kinds of platform services that could be defined as well.

One example is in the area of information services.  An application doesn’t know much about a user other than what the user is doing with that application, but network applications increasingly depend on understanding the context of the user at the time.  Location-based services could be considered platform services, both because they rely on knowledge of where a user is at the moment that could come from a variety of sources.  Other services related to the user’s current context/presence could also be viewed as platform service.  Is the user on a call, is the user stationary or moving, or in a restaurant or theater?  You can see that this information could be valuable to applications that wanted to apply policies based on what their user was up to, and we’re not going to write all of that stuff into every application individually.

The information services linkage demonstrates that platform services can extend to the API-based services already offered by many social networking, search, and network operator  firms today.  That’s not a bad thing; most revolutions build on the past rather than demanding that everything change radically.  What we’re doing with the cloud is making it possible to define, or compose, applications by assembling information and IT resources from a variety of sources, in an application component set that runs where and when it’s convenient—and runs how it’s most profitable overall.

If you look at SDN and NFV in this light, you can see how the cloud can be a supporting revolution to both.  It’s far easier to understand how an application could define network services if we assume a set of platform services that offer the control of the network, apply policies based on what the user will pay for, how the network’s stability and security can be protected, and what mix of resources will earn the best return with suitable performance and stability.  It’s easier to visualize what a practical NFV service would look like if we assumed that the virtual functions might themselves define platform services and that static features defined as platform services might get composed into a retail offering alongside virtual functions.

A final interesting point about the platform services side of the cloud revolution is that it’s really the unifier of “the Internet” and “the cloud” because as information services offered as platform services evolve, the notion of a web application and a cloud application converge.  At the API level, they’re increasingly the same; the difference between them would likely be primarily whether the hosting of the components had to be very dynamic because of shifts in usage or geography, or could be static as they would be today with a dedicated server or VM in some ISP or OTT data center.

So when you think of the cloud in 2014, don’t get caught in the IaaS trap.  That’s so 2013.

I’ve been on a couple trips recently that featured, at some point or the other, the classical multi-armed signpost telling me how far I was from New York, Beijing, Rio, or whatever.  And, while there’s never been a road junction at one of these signs that could take me to all the destinations, you can surely get there from here.  That the converse is true isn’t necessarily obvious, but you can get to any given place from a lot of starting points.  That’s one reason our current network-evolutionary trends are sometimes confusing.  What we need to do is travel the road less taken, I think.

What operators want in networking is what every business wants, higher revenues and profits.  The challenges they’ve faced in that regard is that communications services aren’t infinitely expanding or consumable.  People have historically spend a fairly constant piece of their disposable income on communications, and businesses have done likewise.  That means that average revenue per user (ARPU) tends to flatten over time, making the industry dependent on subscriber growth for revenue gains.

On the profit side, the challenge we’ve faced for literally decades is that service prices have been in decline but costs have not declined along the same curve.  Stu Elby and other operator executives have been showing the charts that illustrate the future cost/price collision, the point where infrastructure isn’t profitable.

So what operators want is to find other stuff to sell, and other ways of producing that stuff that offers lower cost points.  Simple, right?

SDN and NFV are technology-shift solutions that are arguably aimed primarily at the cost side but that could also offer new service benefits.  There are some indications that you can raise network utilization with SDN or improve the economics of high-touch features with NFV, but the biggest benefit of both would be to shed proprietary fetters and empower commodity devices.  This notion got, and still gets, a lot of media attention even though operators themselves are saying that they could likely get the same cost reductions by “beating up Huawei on price”.

Another strategy that has a lot of merit from the operator perspective is a shift away from multi-layered hierarchical networks to something very simple.  An extreme example is an optical network with a ring of electrical on-ramps around the edge.  You take advantage of the declining price of an optical bit to create a network that doesn’t “aggregate traffic” to save money because aggregation likely costs more in device and operations costs than it saves.  This is of particular interest to operators in the metro networks, and I’ve been blogging all this year that metro is where the profitable traffic is (and will be) found.  This approach is sometimes called “flattening” the network because it tends to eliminate some OSI layers, but the real goal is simplification, not flattening layers.  Less to manage means less management cost.

It’s this point that creates the traffic jam on our road to a profitable destination.  SDN and NFV both have a tendency to increase the number of elements in a network.  Pre- and post-SDN, do you have fewer boxes or just different ones?  The latter, I think.  In the case of NFV, do I end up taking a fifty-dollar box and converting it into a couple of hosted functions that require deployment of cloud stacks, hypervisors, servers, data-path acceleration, vSwitches, and so forth?  If so, how much is it going to cost to operationalize all of this new stuff?

What SDN and NFV should have taught us is that we’re at a fork in our converging set of roads—a place where we have to decide whether we’re going to remake operationalization while we remake networking, or try to do network management and service management largely as we’ve done in the past.  The path of change is often called simply service automation, but that covers a lot of diverse ground.  How do you automate a service?  You make the service lifecycle processes event-driven and capable of acting based on complex policies rather than based on human judgment.  You reduce or eliminate autonomous behaviors that are non-deterministic, like the way router networks adapt to failures.  And you do this not only for the new SDN-ish or NFV-ish elements of networks but for the legacy stuff.  That’s not going away completely, no matter what some may think, and particularly not in the near term.

But that’s only one of my forks; what’s the other?  It’s aggressive device commoditization.  You can’t build unprofitable networks, so you’ll skin the needed margins from something.  If it’s not opex it’s capex.  You start by favoring price-leader vendors (does Huawei come to mind here?) and you then drive down cost further by offloading features and further dumbing down the devices (SDN and NFV).  This path flattens metro networks, emphasizes capacity generation over capacity management, and generally picks the pockets of the network vendors.

But this is the path vendors are taking.  I’ve been involved in five projects aimed at service automation in the last eight years, and none of them have received any helpful vendor support.  Vendors have blown kisses at operationalization by using acronyms like “TCO” that cover vague assertions that their gear is somewhat lower-cost to operate.  The problem is that “operations’ means everything from creating a service from piece-parts in a lab, through rolling it out and selling it, to managing its availability and performance during its billable life.  The network vendors have declared most of this out of bounds for them, so they’ve not fixed operationalization and given operators no choice but to seek cheaper devices as their path to their profit goals.  The OSS/BSS vendors have declared all the low-level network stuff out-of-scope too, and nothing is bringing the two groups together in a useful way.  Why, otherwise, would it take two to eight weeks to sell a VPN service?

We have the solution to network profit and vendor profit staring us in the face, and it’s the same solution for both.  We need to rethink the notion of “services” and the notion of “infrastructure” to match a cloud model.  That has to include on the creation of an agile platform for hosting features and a cost-effective platform for pushing bits around, but it has to focus on an architecture that can optimize everything in the virtual-resource and virtual-service worlds at the same time for diverse sets of missions and trade-offs.  Who makes this?  Nobody, today.  Somebody, soon, I think, and that’s the company I’m going to watch.

 

 

Well, it’s 2014 and so it’s a good time to match up the looking-ahead and looking-back parts of analyzing our industry.  One good way to do that is to look at how the network vendors’ stocks have fared in the last year.  If you go to any of the financial sites and run a chart (as I did), you’ll find that the major players divide themselves into three groups based on how much their stocks have risen since last New Year’s Day.

The “bottom” group, Cisco, Ericsson, and Juniper, are up less than the proverbial “Q’s”, the NASDAQ 100 index.  The “middle” group is one company, Ciena, who beat the NASDAQ but didn’t exactly explode, and the two inhabitants of the “exploding” category are Alcatel-Lucent, whose stock was up by over 200% versus last New Year’s Day, and Nokia who was up over 100%.  The topic for my blog this first working day of 2014 is what these companies need to do in the coming year, to achieve success or secure it as appropriate.

The companies in our “Exploding” group are interesting because both Alcatel-Lucent and Nokia have lower price/sales ratios, meaning that their stock price is high relative to their revenues.  You can argue that this means the Street is expecting some radical change in operating practices.  In my view, one of the companies is too broad to produce that change easily, and the other too narrow.

Alcatel-Lucent has a lot of strong areas, and a lot of weak ones.  Net-net, it has so many areas that it’s almost impossible for it to be successful somewhere without the same trend driving that success creating a weakness in other areas.  The company needs to do two things; build an ecosystem and not a bunch of products, and cut what doesn’t fit.  There’s too much cost in premier assets like Bell Labs for Alcatel-Lucent to easily shrink its portfolio, so it needs to be able to create a broader value.  Given it’s a product-silo player, that’s not going to be easy.  CloudBand, Alcatel-Lucent’s cloud flagship, seems to be morphing into something that could lead the cloud, SDN, and NFV initiatives within the company, but for that to happen the product guys have to let a broader story get told.

Nokia has the opposite problem; its focus on wireless and 4G in particular makes it a one-trick pony that is simply too vulnerable to competition.  Wireless is currently the best of bad spaces; we know wireline margins are declining but wireless isn’t great, it’s just not as bad.  It’s obvious that operators on a cost-cutting mission are going to hurt higher-margin vendors in every space they target, and Huawei is an enormously effective cost-based competitor in wireless.  For Nokia, it’s got to be the service layer at this point.

In the middle group we find Ciena, another player with low price/sales ratio, in this case likely because they have very low operating margins.  Optical-layer stuff tends to generate low margins, but right now the industry is working on a way of building networks that spends more on optical transport and less on aggregation at higher layers.  That would benefit Ciena, but they need to be on top of that trend and right now they’re only riding a bit of the wave.

In the bottom group, we have Cisco, Ericsson, and Juniper, and in my view this group is driven by two different trends just as the top group was.  Cisco and Juniper are in a space that’s been performing well historically and is now facing what’s likely to be continued downward movement of margins and gross opportunity—switching/routing.  Ericsson is attempting a transition to professional services as a driver, banking IMHO on the long-term commoditization of networking to create a need for such services as price pressure squeezes out any hope of “included” support.

Cisco and Juniper both have high price/sales, and Juniper also has the highest current operating margins and P/E multiple of the major network vendors.  The Street thinks they can pull something out, but the question is whether they can be “affirmative” and do something that’s actually revenue-and-profit-accretive, or whether they’ll have to cut costs or shed business units to make shareholders happy.

Cisco needs to make the cloud a success, plain and simple.  It’s the only networking giant that has the credentials as a true cloud player, and so it can gain considerable differentiation from making what’s unique about Cisco into a unique asset.  To do that, it has to become not an IT player but a software player.  The cloud is about software, not hardware.  Cisco has an OpenStack distro that’s practically unknown; it needs to be building its own cloud identity by building on that asset.  It can build networking into OpenStack much more effectively than other players, more effectively than the current Neutron effort.  Open Daylight might be a good way to do that, but it’s hardly differentiated.  Cisco needs to think about what it could do that would be Cisco’s alone, and the answer is northbound applications.  SDN and the cloud link there, and that’s where Cisco needs to be.

Juniper’s big problem is expectation.  If you valued Juniper at Cisco’s multiples the company stock would be in the toilet, but unless you can generate some credible reason to believe it has better potential three years down the road than Cisco, its current multiple is hard to justify.  It will never sell enough switches and routers to make up that multiple difference, especially when its operating margins are high and so it’s vulnerable to commoditization.  It tried to be a software company under the prior regime, and it didn’t work.  What’s left?

The only possible answer for Juniper is network functions virtualization.  Kevin Johnson, the former CEO, was a lover of TCO stories.  There is a major need for operational efficiency in the network today, something that the operators are already seeing, and something causing them to shift their NFV focus away from capex alone.  Juniper can morph a TCO story into a full-bore operationalization story through NFV, and also use that as an on-ramp to a more effective SDN position and even a service-layer story.  But it has to get moving because every other group in our three-zone market could also view NFV as a way of moving forward.

NFV builds ecosystems like Alcatel-Lucent needs.  NFV can create a true service-layer architecture, as Nokia must.  It can define the cloud for Cisco, frame professional services and integration opportunity for Ericsson, and help Juniper get some meat on its TCO bones.  But NFV to do any of these things will have to be more than most proponents see it today, more than any vendor is positioning it to be.  So while it’s possible for all of our vendors to get to the promised land in their own way, it’s also possible that how they position their NFV strategies will be the “tell” that shows whether they’ll end 2014 up…or down.