Optimize Real-time Communications with Cloud-native SBC

Migrate real-time communications to the cloud - know how to avoid cloud myths
The first webinar in our two-part series took place on Wednesday, April 25th. This webinar focused on how a cloud-native session border controller (SBC) can ensure successful migration of real-time communication (RTC) services to the cloud. In this webinar experts discussed the state of the market for deploying SBCs in the cloud; the differences between virtualization, network functions virtualization (NFV) and true cloud-native design; and gave insight into the business rationale for migrating from an SBC as a hardware appliance to a cloud-native SBC. Learn how a cloud-native SBC securely and effectively operationalizes real-time communications in the cloud from those who have successfully done it.

Watch On-demand


Achieve real-time communications cloud reality with a cloud-native SBC
Our second webinar digs into some of the more technical innovations that ensure successful deployment of RTC in the cloud. Many vendors state their products will run in the cloud and are "free from hardware constraints," but it does not always mean their products are designed to be cloud-native. True cloud-native design adopts a microservices architectural approach, takes advantage of innovation for load balancing and reliability, and leverages emerging technologies, like Graphical Processing Units (GPUs), for media services.

This webinar will give you a deeper understanding of the requirements for RTC in the cloud and how a cloud-native SBC delivers the security, scale, performance, and flexibility you expect.

Watch On-Demand


Dan Teichman, Senior Product Marketing Manager, Ribbon Communications



Cloud Reality with a Cloud-Native Session Border Controller

Welcome everybody to the series as we've just said, this is the first of our two-part series and so as you can see here we have a pretty full agenda. What I'm going to do basically, as Elizabeth also pointed out, is provide some background and some clarity with respect to the evolution of telco networks to network function virtualization and ultimately tell you how you can deploy session border controllers in a cloud environment. For many of you, I presume you were like me, when I started looking at this subject a while back, I was a bit confused by all the terms and I wasn't sure how it all fit together. For that reason, I really want to start with a definition of terms. I will be referencing these terms as I go through the webinar, so it's kind of important and it kinda sets the stage.

So let's start with the hardware appliance. Nothing new here, this is application software running on typically proprietary hardware and typically with a fixed set of scaling that goes with whatever that appliance capable of providing. Virtualization: application software running on a commercial off-the-shelf platform typically an Intel-based x86 server. It's not optimized or designed for a cloud to point them up, but it's a virtual version of what was running on that proprietary hardware. Network Function Virtualization (NFV): started as an ETSI-defined framework so standard body out of Europe and worked with many players in the industry and has driven an industry adoption using open source implementations. I'll talk more about that as we go forward. NFV is application software as virtual instances called Virtual Network Functions (VNFs) that can be orchestrated for many things primarily starting with on-demand scaling but there are lots of other things we'll talk about. It's still not truly optimized for the cloud, although it runs in the cloud, in most environments. Truly the endgame here is to be a cloud-native design so this is taking things like adopting a micro-services model (again I'll explain that more later). But being able to take that Virtual Network Function and break it into its components, which allows people like us, to provide our customers systems that have the individual focus on performance on scale and reliability on deployment flexibility. Basically, we're creating a framework that enables customers to do whatever they want with that application software, in this case, we'll be primarily talking about an SBC. And the applications designed to take advantage of the cloud attributes. So all of this will make a lot more sense I hope as we go through this but keep this in mind as we go as I talk terms.

But before I do that I want to give you a little bit of background on the marketplace. So I want to start here with this first quote from Rajesh Ghai, who's the research director of carrier network infrastructure at IDC, a leading market research firm. So from their market research report in December of 2017. Rajesh made this point that there's a strong business case that exists for Network Function Virtualization at the network edge. The point that is really important here is this market research firm looks at the market looks at the dynamics, looks at the future revenue, and says, "This is real, there's a business case and people should be doing this." Now what's more important is the second quote, where he says "While their short-term business benefits in the form of lower acquisition cost the long-term business case truly rests on the advantages that accrue from simplicity, flexibility, and agility for being able to deploy a service or network service." In this case, as we'll come back to, that network service is as a Session Border Controller function. So what I think I really want people to understand right from the get-go, is this isn't just a, "Hey there's a technology and I'm looking for a use case." This actually has a valid business case reason. It's happening now and it's happening because it makes business sense for operators to be moving to NFV.

Cloud Reality with a Cloud-Native Session Border Controller Pt. 2

Welcome everyone to the second webinar in our series well I think you'll see here is that we've got a full agenda. My intention here is to continue from where we left off on the first agenda and provide more in-depth information on how and what needs to really be implemented to successfully deploy a session border control in a cloud environment. Again the reason for that is because we enable real-time communications in the cloud environment. So with that let me go ahead and jump right into it. First, let me recap from our last webinar and give you guys just a heads-up on what we talked about there in case anyone can't remember the key points we had.

So the VNF software market is going to be a pretty big market 15 and a half billion dollars by the end of 2021 and 25% of that software markets can be represented by IMS, SBCs, Diameter Signaling Controllers (DSCs), that are sourced from IHS markets. So it's an important segment, it's an important thing that we believe that our customers want to understand how to get there. The SBC VNF revenue, the revenue associated with Session Border Controllers (SBC) as a Virtual Network Function (VNF), will grow from 40% in this year to 76% that's as a percentage of total SBC revenues. So the physical hardware appliance portion is going down and the software only version is going up. Clearly, as I mentioned last time, the market is in movement people are implementing things already there's an opportunity here for people on the webinar to take advantage of that industry learning curve and to jumpstart the path to NFV. There's a lot of good learnings that are going on I'll share some of ours today. I think that's really a big help to people who are looking to move going forward. We talked about several cloud myths for virtualization, security performance, load balancing, reliability and the point there was we'll be aware of what those cloud myths are and focus really on what's actually a reality. As we said last time native SBC something that's designed operating the cloud can deliver the success criteria that are needed to enable real-time communications in the cloud.

So with that let's go ahead and jump into today's content. One of the last things I discussed in the in the prior webinar was that a well-designed cloud-native SBC is built on several important factors and one of the most important ones is this architectural approach called microservices. So what microservices is at a simple explanation level is an application that might have previously been built in a monolithic services architecture where everything is all bundled into one piece of software microservices now takes that and breaks it into loosely coupled components. So instead each of these pieces can then be separate and managed separately yet they provide together an application. So that's shown on the right-hand side. Where a series of functions are broken out and together they make up whatever application is being used here. With this modularity comes a lot of benefits. The independent scalability of each of the microservices, the ability to replace those components with new software, or to just upgrade them independently and being able to isolate and make changes in terms of technology choices. However there is a bit of a complication, it's not really important that you know you can't be overcome and I'll talk about how we did it. It does add the complexity that now each of these software components are talking to each other. In a monolithic service design they already were talking to each other, just kind of underneath the covers, now they're talking to each other through API's and there are things that have to be handled.

So what actually has to happen? Well as we went through our journey to microservices we learned a couple really important things and I want to share those here now. First and foremost was really being able to take a hard look at that underlying architecture and make those decisions on how granular you want to break down your function or your application into microservices. That granularity becomes really important because the priority here is that you have a trade-off between the chattiness of the inter-component communications and the scalability of the solution. And what we found is some technology choices look good on paper, but you really got to do prototyping at scale to really understand how that behavior works. When we looked at it we had a bit of an advantage we had already architected our physical session border controller into functional components that were already discretely implemented. It's just nobody knew that because it was all under the covers. So for us, it was a really relatively straightforward choice to break things out but we still had to manage this trade-off between chattiness and scalability. The other thing we learned was about process change so we found that as we exposed more of these internal functions, our operations teams and ultimately our customers operations teams became more dependent upon the design team to take care of some system level functions - automated discovery and self-control behavior, things that were going to be important to make that microservices version, in this case, an SBC, work properly work without a lot of overhead burdens.

Ask Us Anything!

Ribbon's team of professionals are ready to answer your questions, guide you to the right solution or help you with your network design.