Month: September 2012

Well, Apple finally did the iPhone 5, and there are already sharp differences in how the launch is perceived in terms of the significance of the changes and what they say about Apple.  I think some of these differences arise from perspective; some care only about Apple’s share price, some about its long-term future, and some are just Apple junkies who want to be cool.   My interest is in the long-term systemic issues of the market, and there I fear Apple may be missing something critical.

Think for a moment about smartphones or even tablets; they are intelligent, network-connected devices.  So are PCs and servers.  The difference between the classes here is portability, which brings with it the ability to integrate these devices into a more general role in supporting one’s lifestyle or work.  I can use smartphones for things I don’t use servers for because I can put a smartphone in my pocket.

What makes things complicated here is the cloud.  I don’t need to put a server in my pocket in order to use it; I can use a thousand servers cooperatively from a simple device, providing that device can call on the resources of that server community and marshal them to my task.  Because of this, it’s my view that the mobile devices are really GUI machines; what matters for them is the quality of the user interface because the user interface is the inescapable requirement for something that’s representing the user’s wish fulfillment—whether that fulfillment is accomplished locally on the device, by accessing simple web APIs, or by coordinating cloud activity.

LTE was the only thing that was significantly, functionally, new in the iPhone 5.  Some, including Forbes magazine, have suggested that the LTE connection now available on the iPhone will make it better at supporting business functions, like analytics.  Analytics on a smartphone?  Come on!  Anyway, the smart strategy for an analytics application directed at mobile workers would be to use the device as a simple GUI platform to invoke a cloud-resident analytics agent process.  Otherwise you have to drag the data to the device (what Forbes apparently thinks LTE would be better for) and pay the data plan cost of that decision.

Mobile devices have two polar futures.  We can assume that they will become powerful computing centers themselves, becoming capable of Forbes’ analytic tasks, or we can assume they become increasingly capable windows on a cloud world.  I’d be astonished if anyone believes the former; whatever technology advances make smartphones as smart as PCs make PCs as smart as servers, and so forth.  The future of all mobile devices is to fulfill simple needs and pass complicated ones, including all those that involve data analysis, to a cloud-resident agent process.  I think Amazon sees that, and is driving Kindle Fire in that direction.  I hoped to see a signal from Apple that they see it too, and no such signal was given yesterday.

If Apple is “under-clouding” their planning, there are continued indications that network equipment vendors may be “over-clouding”.  Brocade’s analyst event is positioning the company’s new data center strategy, a strategy that like others seems based on the notion that fabrics and virtualization via SDN will be the driver of future revenue and profit growth.  The problem is that network virtualization is so far convincingly valuable only to multi-tenant applications, meaning that it’s a cloud-provider-side technology.  Let me get this straight; we’re moving IT to the cloud to take advantage of economy of scale there, but somehow we’re going to end up with zillions of cloud data centers, each with their virtualized fabric?  Or will enterprises decide to build fabric-linked data centers to connect all those servers we’re proposing are being outsourced to the cloud and thus won’t be there to connect?

Fabric technology isn’t necessary to build cloud data centers.  Fabric technology is necessary to build data centers that are highly integrated horizontally, meaning data centers that support componentized applications.  That can happen in the cloud (and it will) and it can also happen in every data center a large-ish enterprise runs.  Thus it’s not that fabrics aren’t valuable.  The issue is that multi-tenancy isn’t valuable except to those who are hosting tenants, meaning providers.  We should be looking at the broader issue of componentization of applications and how the cloud would impact that, and then looking at how data centers would evolve based on this componentization driver overall.  Brocade, if they want to take a position in the cloud data center space, should have taken a deeper look at the issues and done something new and insightful, which is certainly possible at this point in the market.

The cloud is more than Apple’s current positioning suggests.  As a driver of data center opportunity, by itself, it’s less than Brocade suggests.  But what both companies COULD suggest is that the cloud is the description of a new, universal, virtual computer platform.  Apps run on it—anywhere—by pushing their components to the places in that virtual platform where price/performance is optimal.  Devices, from phones to servers, host a piece of the virtual platform and run some of those components.  This is what the cloud becomes, if it’s ever anything beyond marketing hype.  This is what Apple and Brocade and of course all their competitors have to prepare for, or they abandon a place and role in the framework of the future.

 

It’s obvious that software defined networking is the “next big thing”, at least from the perspective of the media and those few VCs prepared to invest in infrastructure.  In the last couple weeks we’ve seen some new details on SDN plans from Plexxi, a long-standing stealth startup in the space, and news that “MPLS fiend” Kireeti Kompella has left Juniper for another SDN startup, Contrail Systems.  These developments have a narrow and broader context, and I propose to address both, with the broader one first.

In our industry, “next big things” are always characterized by a phenomena I’ll call “tagging on”.  A player in the market knows the media loves novelty (which is what “news” means, after all) and so they know that a story on SDN is going to play better with editors than one on data center switching or fabrics.  Thus, they bend the outlines of the concept of SDN a bit to make their own stuff fit, and sing away.  The result is that popular notions quickly lose shape and substance.  That’s surely the case with SDNs.  Software defined networking, as I’ve pointed out, isn’t “software defined data centers” or “software defined virtualization”.  A network is a cooperating collection of devices that generate the service of connectivity, and to software-define it is to software-define how that service works.  I don’t think that you can call an approach that software-defines a piece of a network or one of its missions as an SDN.

That doesn’t mean that these things can’t be a piece of the SDN puzzle, or that these missions can’t be contained within the broader SDN mission.  In fact, the interesting thing about SDN is that there are things—lots of things—that belong in it and aren’t being put there.  Let me give you the biggest example; APIs.

All sorts of network devices and network software elements expose application program interfaces.  Presumably the purpose of these interfaces is to control behavior of the devices/elements, and since they’re “network devices” and “network software elements” the thing they’re controlling is the network, right?  OK, let’s continue on this track.  An API is exercised by software, right?  That means that EVERY NETWORK DEVICE OR FUNCTIONAL API SHOULD HAVE A PLACE IN AN SDN FRAMEWORK.  Otherwise we’re controlling the network with stuff that’s outside the scope of the concept we’ve designed for application control of the network!

Before you rush to the barricades on a wanton expansion of things like OpenFlow, let me explain that I don’t mean that SDN standards have to embrace every API out there.  SDN concepts are based on the familiar principle of abstraction; a network is a cooperative system and can be represented by a black box that is described by the relationship between its inputs and outputs, another way of saying “by its services”.  A high-level network abstraction (like “LAN” or “Tree” or “Line”) has to map downward to devices to create the cooperative behavior we need.  The SDN standards will eventually have to deal with how those high-level abstractions are communicated, but they also have to deal with how they’re decomposed to the device level.  That’s critical in building SDNs from current equipment and also critical for building SDN equipment, if it comes to that.

Every single vendor who purports to support SDNs should be providing us with a nice map that shows how their SDN solution builds upward from devices to a set of abstractions that an application could be expected to use as its description of the network services it needs.  Pretty much every vendor in the network space says they support SDNs, and yet we don’t have that map from any of them.  I, for one, want to see it from them all because only with that sort of map can we relate the current infrastructure with the evolution to SDN.

On the narrow side, you can see from what Plexxi has said and by the limited comment on Contrail Systems’ website that their focus is on the data center.  Plexxi is an optical-linked data center fabric; Contrail’s details aren’t yet known but its focus is the same.  Why the push on the data center?  I think there are three reasons—budget influence, infrastructure inertia, and the cloud.  Network budgets have been controlled by the data center for years. Infrastructure in the broad Internet has too much sunk cost to be quickly displaced, so it’s an unattractive startup target.  Finally, the cloud is first and foremost a network of IT resources, which is a data center network.

But a data center network is not SDN, or at least not all of it.  The data center focus, which is a focus of convenience, is a part of the network but not the whole of it.  To get to the rest, you need to envelope the notion of data center virtualization in a real SDN abstraction, then link that abstraction to the APIs that control current device and network behavior.  This is the SDN mission that incumbent vendors should embrace, not only because they have that current equipment and APIs but because they then elevate the marketing dialog to a level where they can win over limited-focus startups.  Unless, of course, one of those startups does the job first.  Might Plexii or Contrail or Big Switch do that?  We’ll see.

 

With Apple (supposedly, at least) ready to launch a new iPhone this week, it’s also facing what might be its real “second pole” of competition with Amazon’s Fire HD.  The new Kindle is iPad-sized, but more significantly it expands the notion of free wireless for some content downloads to a cheap LTE plan that could nearly cut cost of ownership in half.  But that’s not the half of it.  Fire HD aims at Google and also has the potential to redefine the relationship between service providers and device vendors.

Aims at Google, you say?  Isn’t Kindle Fire HD (like all Fire models) an Android device?  Yes, perhaps in the sense that it uses the open-source Android core, but Amazon has taken control of the higher layers and isn’t connected in any specific way to Google’s own Android release train.  That means that Kindle Fire is likely to diverge more from “stock” Android over time, and since it’s already the number one Android tablet you have to take that separate thread as a separate threat.

From the network operator perspective, Fire HD is the first clear example of a device vendor going MVNO.  While both Kindle and Nook from B&N have offered wireless service connections for book ordering, the new HD has a wireless plan for under fifty bucks per year.  The data quota isn’t going to let you watch even a significant YouTube video, though, and you have to wonder why Amazon would put this kind of deal together.  I wonder if the reason isn’t that the relationship it struck with AT&T helps that operator dodge an FCC neutrality rule.

The FCC has taken the position that content owners can’t subsidize content delivery costs in the form of premium QoS.  Many, including me, believe that this could mean that the FCC would also look suspiciously at the idea of offering users content outside of their data caps, which in effect subsidizes content.  But Amazon might well take the burden off AT&T by saying that it would deliver content sold from its store to consumers outside the cap.  That, after all, is what it already does for ebooks.

If this is in fact what Amazon and AT&T plan, it might make MVNO status for device vendors essential in a content-competitive market.  It might also make hosting MVNOs attractive to network operators because the fees they could get could include items that regulatory rulings would bar were the operators to try to collect them directly.  In short, we may be seeing the dawn of the device-vendor-MVNO age of wireless.  And if that’s true it won’t stop with tablets.  Such a deal might be why Amazon is looking at becoming a smartphone player.

Which brings us back to Google.  Android is the top OS for smartphones, but it’s not the top for tablets if you pull Amazon out of the numbers.  If Amazon gets onto smartphones it’s almost sure to take the same approach it’s taken with tablets, which means it would be creating an Android phone that became steadily more different from Google’s Android.  And since it’s open-source, it might attract other phone vendors.  Google, in short, is at risk to lose its own creation just as it’s trying (finally) to organize the community and make Android a real brand and not just a rubber stamp.

But how about Apple?  The Amazon move seems to me to further pressure that giant to move to being an MVNO, regardless of what Google might do.  It may also put pressure on Apple for the cloud, because Amazon could easily host mobile device features on its EC2 infrastructure and use that to differentiate its offering.  Remember that Fire already has a cloud-accelerated browsing feature.  So might Apple make an announcement similar to Amazon’s?  Might rumors of such a move have prompted Amazon’s Fire HD data plans?