The voice services space may be demonstrating the fate that any “basic” service of connection will face, and also some of the technical opportunities that could still be realized. Acme Packet, one-time darling of the financial analysts, has taken a hit and the “Why?” says a lot.
Acme has been a provider of session border controllers for VoIP services, a market that at one level you’d think would be going well given the voice transition we’re in. But the voice transition is being driven by free overlay voice services like Skype and Google Voice, and any time you face free competition, your own price and cost will be under pressure. In the SBC space, Acme has been forced to push a software-SBC model, and obviously that’s going to sustain a much lower margin. Just as obviously, in the longer term, the P2P voice model is going to win out and SBCs will be a thing of the past.
OK, doom and gloom in voice is nothing new; most people have realized that voice services will ultimately be incrementally free and thus based on the lowest possible technology cost. As we move to smartphones and tablets with easy gadget-based access to multiple online message, mail, and voice services there’s little reason to worry even over the issue of interworking among providers. Let the device bridge the gap. And video obviously breaks the old PSTN calling model. But is there anything good that might come of this?
One thing, I think. As we move toward the notion that services are a feature that’s hosted rather than an element in hardware (SBCs are software, remember?) we move to a model of cloud services that just might embrace the network devices themselves. After all, where’s the boundary of a cloud? Let’s suppose we had a service architecture where all features were represented by a URL and where all devices from the phone/tablet in your hand to the deepest data center, INCLUDING the routers and switches, might host stuff on demand. It’s a cloud model that lets not only users join and applications run, it lets resources join. When they do, the resource’s location relative to the user and to other resources would be used to decide when to host something on it versus elsewhere.
You could argue that the Mozilla Firefox OS concept could promote a notion of “agile resource fulfillment”. Incorporate an API into an app and it needs to be satisfied somewhere. Why not bind apps to APIs more dynamically, so that if the handset has a capability it can be drawn from it, but if not the API could realize to a cloud service? If you want “location” you call for it, to either draw on handset GPS or carrier triangulation. The notion is to abstract what elements make up a service and then utilize what’s best suited. If the cloud can assign applications to resources, why stop with server farms? I don’t think we can, or should, or will.
One interesting possibility in taking a step in this direction would be to adopt a kind of Firefox-OS-ish model for basic orchestration and control of network behavior. Microsoft and Joyent have been pushing a server-side Javascript architecture with “node.js”. Could you compose “service pages” and then execute them? Could you extend the architecture with some broad API-discovery mechanism like UDDI? Could equipment vendors host node.js on network management platforms to provide a link to their own exposable assets? Could we secure a distributed service/cloud architecture? There are other approaches to node.js, of course, but at least this is an option for a broad architecture at a time when we darn sure need one.