This morning's announcement from Avaya about virtualization for mid-size Aura implementations is pretty significant. As Allan notes in his post, it's not the first virtualization announcement in the enterprise communications space--that honor goes to Mitel. But according to Bruce Mazza, director UC market solutions at Avaya, the Aura release is the first to comply with key virtualization standards, specifically the Open Virtualization Format (OVF) created by the Distributed Management Task Force (DMTF--not to be confused with DTMF).Avaya lays out its virtualization vision in a white paper commissioned from IDC, authored by Abner Germanow and Jonathan Edwards (Update: link here, registration required). It's basically a three-stage progression for the enterprise that embarks on virtualization. Stage 1 is the current proliferation of physical servers; Stage 2, which is where Avaya has arrived with today's Aura announcement, features certified communications applications running together on virtual servers within a single hardware server; and in Stage 3, which occurs sometime in the future, communications apps run alongside other applications on the same hardware platform, but on separate virtual servers.
Germanow and Edwards write:
Because VOIP and other real-time communications technologies are resource intensive and response time sensitive, consolidation with other applications on a physical server is risky. Avaya purposefully engineered its approach to virtualization to leverage some of the benefits of the technology but to specifically avoid critical failures to real-time applications relative to application availability, end-user experience, and QoS.
Unified Communications is notorious for the number of servers it requires--Brent Kelly of Wainhouse Research memorably said that "it takes a village...of servers" to run Microsoft Office Communications Server (OCS), but in fairness, OCS isn't the only UC product that fits this description.
The three-stage migration that IDC and Avaya describe looks like a good way for enterprise communications shops to work their way into virtualization. You probably wouldn't sleep very easily knowing that your communications apps were running on servers with other applications, and you may not be ready, from an organizational perspective, to be sucked into the overall datacenter operation anyhow.
It reminds me of the early days of voice over IP. All of our friends in the telecom organizations were fretting about running voice over the crappy IP networks that the networking teams had built. All the while, it turned out, the networking folks were horrified by the idea of putting that pushy, demanding voice traffic on "their" IP networks.
I suspect the datacenter teams today may be similarly unlikely to welcome your voice apps onto their virtualization servers with open arms. Putting UC on virtualized servers that remain separate from other enterprise application servers seems to make the most sense for now.
