Network and Telecom Strategies Blog

BT + Cisco Deliver Cloud-Based Telephony

posted by: Mark Cortner

The viability of cloud-based UC took a significant step forward earlier this month with an announcement by BT and Cisco on the launch of a global cloud-based IPT service from BT’s Onevoice UCC portfolio. The hosted IPT solution will be the first global offering based on Cisco Hosted UC Services and is currently available in the UK. The offering will be available in the USA and EMEA in 2010 followed by Asia Pacific. BT is working with Cisco to build the virtualized infrastructure and leverage its cloud computing technologies to deliver a cloud-based UC service. The relationship between virtualization of telephony applications and cloud-based UC was highlighted in a previous blog post; BT and Cisco have taken virtualization to the next level to deliver a cloud-based UC solution including hosted IPT.

BT’s service offering will enable businesses to access services using a utility-based pricing model; the cloud-based services now include telephony, voice mail, unified messaging, and conferencing. The service is delivered over BT’s MPLS network service and can be blend the cloud-based telephony services with existing legacy TDM and IP voice infrastructures—enabling enterprises to migrate to cloud-based IPT services based on their business requirements and in consideration of existing investments. I look for BT to offer solid a SLA with these services, anticipate availability metrics between 99.9 to 99.99%, and to leverage the use of SIP-based connectivity introduced earlier this year. The ability to enable the cloud-based IPT solution to “integrate” with existing legacy TDM and IP voice infrastructure will be interesting to watch, and the terms “integrate” and “interoperate” often hold different meanings to service providers and customers. Furthermore, although large enterprise customers will appreciate the ability to support blended telephony solutions, they will also seek the ability to support hybrid unified messaging and collaborative application environments … the first step has been taken.

UC and Virtualization

posted by: Mark Cortner

The recent announcement from Avaya related to its new virtualized UC offering is an interesting development for the UC industry. The single-server UC solution is based on Avaya’s Aura architecture which was introduced earlier this year. In early 2008, Mitel announced a single-server solution that signified the first application of virtualization technology to enterprise real-time communications applications.

Avaya’s initial virtualization solution, Aura System Platform, is currently targeted to the midsize market with a maximum scalability of 2400 users. The solution includes the core components within Avaya’s Aura architecture—Communications Manager, Voice Messaging, SIP Enablement Services, Application Enablement Services, Utility Services, and Media Services deployed on a single server.

I fully expect more announcements soon from the UC industry that take advantage of virtualization for not only asynchronous applications but also real-time communications and collaboration applications. I also expect the scalability of virtualized UC solutions to rapidly increase; anticipate that single-server offerings will evolve to effectively address enterprise requirements within the next year … and one step closer to cloud-based UC.

Cisco the Computer Company, Act IV

Posted by: Eric Siegel

After a few months of rumors, Cisco made its Big Announcement today: The Cisco Unified Computing System (UCS) is here. (See http://www.cisco.com/go/unifiedcomputing)

Based around Cisco's low-latency, lossless 10 Gb/s network fabric, it can grow to 40 chassis with up to 320 Intel Xeon compute nodes and thousands of virtual machines. It is sold as a complete system, and Cisco kept emphasizing that it would be scalable and managed as a single system.

I immediately thought of my previous blog entries (see Cisco the Computer Company, Act III) that had predicted Cisco would become "the intelligent, coordinating backplane" of a multi-server system. And I thought, gee, I was thinking too small -- Cisco is going to sell the whole smoking ball, the whole mainframe, not just the backplane.

But I kept thinking... and problems appeared. This is starting to look like less that it seemed at first. Maybe I was thinking too big, at least for the current announcement.

And the crux of the issue is systems management. Yes, Cisco talked a lot about how UCS is "managed as a single system." But the Tandem Computers (now HP Integrity NonStop) system really IS "managed as a single system." To the operator, it appears to be a single mainframe, even though it may contain hundreds of CPUs and a hypercube embedded switching fabric. I think that the Cisco UCS looks more like the old IBM SP ("scalable POWERparallel") mainframe, which was a rack with a lot of IBM AIX processors and a fast interconnect. It surely wasn't a single mainframe; the operators and users were very aware of the fact that there were a lot of separate processors there. On the Tandem, the entire thing is configured, backed up, managed, and programmed as a single machine. On the Cisco UCS (and, to a great extent, on the IBM SP), you can create templates, or service profiles, for processors, but you're still very aware of each individual processor in the system and, for example, if you want to back them up, you'll have to handle each one separately, I think.

So the Cisco UCS isn't a mainframe; it's a collection of blade servers around a high-speed interconnect with a nice template-based management package to handle configuration and provisioning. (BMC Software's BladeLogic is tightly integrated with the Cisco UCS Manager, and apparently will provide a linkage into BMC's Atrium configuration management database, etc.)

And there were no signs in this announcement that Cisco has implemented the idea of creating an "intelligent, coordinating backplane, where programmers could drop an inter-process message into that backplane (for example, with a SOAP header giving the name of the destination process) and be sure that it would be delivered to that process exactly once." Or that they've developed a diagnostics package that could easily trace transactions across that coordinating backplane.

Cisco could really shake up the computing industry if it introduced a real way of making a single mainframe image out of a collection of virtual machines and processors and network fabric. But this doesn't appear to be it. Instead, this appears to be a minor evolution of existing systems; the news is that Cisco is entering the market, not that Cisco is introducing a smoking hot new technology.

And see the Burton Group's DCS blog "Beware the Ides of March..." for more discussions of Cisco UCS!

(Note: Ten years ago, I worked for Tandem Computers as the coordinator and technical lead for all networking specialists worldwide, and I still have a warm spot in my heart for the place and for the famous Beer Busts on Friday!)

Network and Systems Management: VMess

Posted by: Eric Siegel

OK, now I'm worrying about how we're going to manage VMs without losing our minds.

You see, I've been hearing great stories about how there are going to be huge racks of servers containing zillions of VMs: virtual servers, virtual switches, virtual routers, virtual firewalls, virtual performance optimization appliances, virtual everything! And the system will instantly adapt to changing workloads, spawning new, fully-configured servers with their complete environment, along with switches, routers, whatever.

And if a newly-spawned virtual server is too many virtual-router hops away from closely-coupled applications or processes, well, then, that new virtual server will be automatically re-provisioned and re-configured closer to where it should be for minimum latency!

Yes, the entire mass of virtual whatevers is going to be in constant, thrilling motion! Everything is going to be moving around, minute by minute! Total efficiency in hardware utilization! Minimum transport latency! Automation! I just can't wait! It's going to be just totally wonderful!

Until it breaks.

And when it does break (and it will), I don't want to be the miserable technician trying to figure out where everything was when that transaction failed, trying to track down precisely what subtle interaction of data flow, firewall, optimization device, VLAN, switch... you get the picture... was the source of the difficulty.

It'll be like yelling "STOP!" six hours too late at a frenzied set of hyperactive squirrels loaded on caffeine and springing among the trees while chattering at each other. Now, where were they six hours ago, when the problem occurred? All the actors in the drama will have melted into thin air. I'll bet the guilty one won't even be there any more; he appeared, messed something up, and then vanished into the virtual fabric, leaving just the rack behind.

What will the vendors give us? Probably only the assurance that the virtual servers and switches and routers will have virtual MIBs, just like the real ones. But I know where the real ones are, and I can put my hand on them and monitor them. What happens if a virtual switch appears, switches a gigabyte or two, and then vanishes -- poof! -- inside of a minute? Where did it go? What did it do while it was alive? We'll be MIB-less in the fabric, without any vision.

I can already see a rule I'd like to impose on this mess, which will tie in with the "triage-based incident management" discussed in my post "Network and Systems Management: Over the Edge." It's this:

"Just because a production group can create a maze of unmeasured real and virtual servers, network components, and interconnections that change from one minute to the next is no reason it should. Edsger Dijkstra wrote a famous letter to the editor titled 'GO TO Considered Harmful' (Communications of the ACM, August 1968) in which he made the case for more program structure and less intertwined process flow. The same applies to IT infrastructure." [This is from my new Burton Group paper, "Using Network Management Platforms for Triage-Based Incident Management."]

I'll bet we network folks are going to be stuck in the middle of this VMess, and a miserable place it will be. We'd better start figuring out how we're going to handle it when incidents occur. And I think that triage orientation, with clearly-defined diagnostic domains and rules to ensure that the virtual servers providing a service are all grouped within the same domain, where we can evaluate them as a group with active measurement techniques, is a good place to start.