Ask the Experts: Key Elements of Data Center Design

Welcome to Ask the Experts, brought to you by In this video, Intelisys’ SVP Cloud Transformation Andrew Pryfogle talks about softswitch and the key elements to data center design with Evolve IP’s CTO Scott Kinka. Find out more about how customers can benefit from cloud-based data centers from Scott and the Evolve IP team here:

Andrew: Hey guys, welcome back to our next Ask the Experts session. I’m here with one of our great friends, and one of the smartest guys I know in the cloud space and the UCaaS space, Mr. Scott Kinka, CTO of Evolve IP. Mr. Kinka welcome again to the studio, my friend.
Scott: I’m thrilled to be here. You always make me feel so important when you give me that intro.
Andrew: That’s right. We’ll have to dumb this down a little bit next time, maybe.
Scott: Yeah.
Andrew: Yeah, we all need a little humility at times, don’t we?
Scott: Certainly.
Andrew: Hey listen, here’s the question I want to ask you, man.
Scott: Sure.
Andrew: We’ve been talking about the architecture of the service provider data center—namely the softswitch that goes there, the role that the softswitch plays—but also all the other elements that come into the design and build of a service provider data center. I wanted to ask you: what are some of those key elements and most importantly, when it comes to a hosted, cloud-based UCaaS solution, how is it that a service provider data center is far more robust than what an end user customer could ever practically build on their own? Speak to that real quick.
Scott: Got it. So, we’ll start by breaking down the carrier softswitch. Every softswitch is a little bit different, but we’ll talk about it in terms of elements. The first is related to security in and out. At the front end of any carrier infrastructure will be a thing called a session board or a controller, which is essentially a VoIP firewall, we’ll call it. It’s brokering connections in and out from a voice protocol perspective.
Then you get down into the particular softswitch. In some softswitches, these are combined. We happen to be BroadSoft, so these are separate layers, but essentially you generally have a network services layer—this is communication to carriers and communication out to end points through the service, the session border controllers. Then you’ll have an application layer, and an application layer is generally that component that’s managing all of the things that the end users see. Routing, the buttons that they’re pressing, the interface and the portals. Then you generally have a media services level: media gateways. These will do things; it will play messaging, they’ll record voicemails, they’ll be places where media is played—background hold music–all that kind of stuff is generally at that media services level.
Then, in our infrastructure we have some additional levels for integration in from third parties. We call them Xsi in BroadSoft landing, but those are places where application communication is brokered in from external parties or external applications on in. Those are separated from that core infrastructure because when you get to a carrier class network, you want to give customers the flexibility of being able to say, “I wrote this thing and it talks to you,” but you also have to make sure that that thing they wrote doesn’t interfere with the operation of the core infrastructure.
They’re brought in sort of at these ED servers with gating between them to make sure that it doesn’t interfere. Those are sort of the components, and the next piece would really be—and this would differ based on provider—but you’ve got the local redundancy of those units, right. How many network servers, how many application servers, how many Xsi, how did they fail to each other.
Then, in our world as well and others, you’re then talking about how do you take those stacks and make those geographically redundant. I’ve got multiple application servers here, and multiple application servers someplace else. I have multiple session border controllers here, and multiple session border controller someplace else—but all at the same addressing, right? So that the end customer can register and work with any of them, regardless of what the geographic condition happens to be.
I think that that last piece is really the primary difference between a service provider and an end user, right. It’s really in the strength of the redundancy. It’s in the strength of the geographic load balancing and redundancy. It’s in the strength of, frankly, the data center facility itself, and that has a cloud computing kind of implication as well. Power, cooling, all of those things that go into a professional data center.
Then certainly that tiering of those applications we talked about. It’s not a common thing in a premise-based PBX, and that’s done our way so that we can break those levels up, and problems at one level don’t necessarily effect all of the other levels of the application. There’s a lot of complicated things in there to talk about and I’d share a lot, but I think the key is heft.
Andrew: Yeah.
Scott: Heft, and redundancy and elasticity.
Andrew: Cool. Now that makes a lot of sense. Spend just a moment on power and cooling.
Scott: Yeah.
Andrew: Because I think some people may overlook the importance of that. We’re not just talking about plugging something into a wall here. How do you . . . the environmentals around the data center are really critically important. Why should customers care about that?
Scott: I mean, the key about environmentals is—we have this funny picture we have hanging in the office, which is like, it’s literally a toilet and then there’s like a rack on top of it and it says, “Data center, you’re doing it wrong.” Obviously that’s a funny example, but the reality of it is most data centers are now purpose-built and that’s the key. So purpose-built—and I’m using that example because you brought up cooling, right. Cooling is the area where purpose-built is the example. It’s got to be up to the hard deck. It’s got to be built and the rows have to be in ways to be able to move air and retrieve air.
Most customer data centers are frankly, “Find the office at the end of the hallway that we can put a locked door on.” You know what I mean? You generally find the hole cut out at the bottom of the door and things of that nature. Why cooling so important–cooling is really the piece that burns out components at the end of the day. Fans have to work harder, which stresses processors, which stresses boards—you know, all of those pieces. Temperature is incredibly important; and then of course, power relates to that. So if you think about this: the more of a cooling problem you have, the more the box is working to be able to cool itself. The more power it’s consuming, right, the more power you create, the more heat it’s consuming. It becomes this sort of follow-on event. More power needed, more cooling needed, which means more power needed, which means more cooling needed.
Most non-purpose-built call data center rooms are really challenged in the environmentals department.
Andrew: Got it. Very cool man, great insight. Thanks for breaking that down for us, man. I think there’s a ton that obviously goes into the design and build at the core of the service providers network, and customers can gain tremendous benefit from that, right?
Scott: Absolutely.
Andrew: I mean, to be able to access that kind of technology—that kind of redundancy and diversity built in, power, cooling and all those, all the environmentals that wrap around it—you can never do that with a premise-based solution. Not practical.
Scott: Not at all.
Andrew: Very cool. Guys, that’s Scott Kinka—the enormous brain of Scott Kinka. There, I did it again. I just overinflated his ego.
Scott: Yeah. Wow.
Andrew: That is Scott. Evolve IP, the CTO. Make sure you check out their learning center, guys. They’ve got some amazing information there and it will help you sell more services with Evolve IP. They will absolutely help you sell more cloud, more UCaaS. You can definitely grow big with Evolve IP. We’re big fans. Scott, thanks for your time, my friend.
Scott: Thank you.
Andrew: All right.