I’m seeing some progress (perhaps, at least) in the evolution of a logical structure for operator-hosted OTT services. One startup, UXP Systems, has created a kind of shim layer that orchestrates and manages the OTT form of a number of operator services, including voice, messaging, and video. The idea is to provide componentized, orchestrable, services by adding a layer above traditional services and using APIs that expose those traditional features. It COULD be a major step, but I have some reservations largely arising out of positioning.
UXP talks about the goal of “multiscreen” delivery, which means the ability to deliver a service in an arbitrary appliance context. The concept is a bit hard to get your head around, not because the term is hard to understand but because it’s hard to understand just how UXP proposes to build a service foundation to support it. First, the paper on the topic is long and complicated (you’re at Page 9 before they introduce the product, called MINT). Second, there’s relatively little time spent on the details of the implementation. The website isn’t helpful either, and all of this may be why media coverage of their approach has been off the mark.
The hopeful part is that UXP does identify a reasonable set of platform components for next-gen services, and a broad architecture for making a shim layer of this platform so that it intermediates between new services and users on top and legacy infrastructure and OSS/BSS on the bottom. If these guys have what they say, and if they could articulate it and apply it more broadly, they might be contenders for some operator projects in the service layer. We’ll have to see how it develops.
Another item that may be worthy of more attention than it’s getting is an HP announcement about Virtual Appliance Networks. The notion of a virtual appliance comes from the growing popularity of database and analytics appliances, which are hardware/software combinations deployed as functionality in a box. Obviously the same functionality could be represented in the cloud as a kind of SaaS, providing that you could deploy it as a unit. That’s a task for the project area known as “DevOps” that fuses development and operations to permit seamless cloud (and other) provisioning. HP apparently intends to lay some claim to this space too, and that may be because Cisco is already there with its Donabe project, something I’ve blogged on before and that we cover in some detail in Netwatcher for April.
HP has a vision for OpenFlow, but as I indicated yesterday it’s not a very differentiable one. If HP also has a vision for DevOps in a cloud context, the question is whether they might try to unify these visions to create a mechanism for a software-defined network based on OpenFlow to learn and apply the connectivity requirements. A Virtual Appliance could “carry” policies as easily as a “Container” or “Charm” in DevOps. The problem is that it’s not clear what HP intends to do here, or even if HP knows what it wants. The same can be said for Cisco, who has yet to make Donabe any official product/policy element. You can search for the term “Donabe” on Cisco’s own website and you don’t get any hits.
IBM? With their Green Hat buy, IBM could field a development and deployment kit that would span the data center and extend all the way to mobile devices. That would let them pull the devices themselves into the cloud model, which would extend the utility of any orchestration/logic or DevOps process. Search on “DevOps” on IBM’s site and you get nearly a million hits; you get none on HP’s or Cisco’s sites. I’m not hearing much from users or operators about IBM’s position here, though, and it’s certainly not being picked up much in the tech media. Still, I think that with this kind of positioning groundwork being laid, it’s more than likely that IBM has something planned. Which may be what’s behind HP’s moves.