Paradigm Shift: Virtual to the Cloud

We live in a world where communication solutions can be hardware-based, run in a virtual machine on a local server or be situated in the Cloud. The paradigm for communications solutions has been shifting from hardware to software to virtualization as I’ve discussed in my recent posts. Once a solution is virtual, in principle, customers have the flexibility to control their own destiny. They can run solutions on their own premises, in the Cloud, or with a hybrid model that uses both approaches.

Let’s consider an example. Dialogic has traced this type of evolution in its SBC products.  In 2013, the company positioned two products as SBCs. The BorderNet™ 2020 IMG provided both SBC and media gateway capabilities and found an audience that wanted an IP gateway between different networks or an enterprise edge device. The BorderNet™ 4000 was a new product which focused on SBC interconnect functions and ran on an internally-managed COTS platform. Five years later, both products have changed significantly.  The IMG 2020 continues to run its core functions on a purpose-built platform, but its management can be either virtual or web-based.  The BorderNet™ 4000 has morphed into a re-branded BorderNet™ SBC product offering. The product has evolved from its initial hardware focus to being a more portable software offering.  Customers can now run the software on a hardware server, in a choice of virtual machines or by deploying on the Amazon Web Services (AWS) cloud. Whereas the original BorderNet 4000 only supported signaling, the BorderNet SBC can optionally also support transcoding of media, either in hardware (using a COTS platform) or in software. The journey of these products has offered customers more choices. The original concepts of both products are still supported, but the products now have elements of virtualization which have enhanced their portability. So as a result, the full functionality of the BorderNet SBC can run in the Amazon cloud and in the other business models.

Once a product has been virtualized, it can be deployed numerous ways and can be deployed using a variety of business models. As customers want to move solutions to the Cloud, being able to run one or more instances of software in virtual machines is essential. The term Cloud tends to be used generically, but in telecom, there are multiple ways the evolution to the cloud is playing out. One example is the OpenStack movement, where open source has helped drive what is sometimes called the Public Cloud. The various forms of private clouds have also been popular, with variations being offered   by Amazon, Microsoft, Google, Oracle, IBM and others.

In my next post, we’ll consider how the technical changes we’ve been describing here have also been coupled with changes to business models.

If you participated in the evolution described here, please feel free to weigh in with your comments. If you’d like to explore strategies on how to evolve your application solutions or other communications products / services in this rapidly changing technical and business environment, you can reach me on LinkedIn.

Advertisements

Following the Path to Virtualization

A number of years back, my product team engaged with a Tier 1 solution provider. They wanted to use our IMG media gateway as part of their solution, but with a condition.  They had limited rack space, so they wanted to use an existing server to manage our device. Up until then, we required customers to load our element management system (EMS) software onto a dedicated Linux server.  Instead, our customer asked us to take our EMS software and package it to run on a virtual machine. Our team investigated and were able to port both the underlying Linux layer and the EMS application for use on a Xen virtual machine. Voila! Our software was now virtualized and our customer was able to re-use their existing server to manage the IMG gateway.

That was my introduction to virtualization, but this approach quickly became much more important.  Just a few months later, other customers asked us to port our EMS software to work within the VMWare virtual machine environment. There were immediate benefits. The EMS running directly on server hardware required qualification of new servers roughly every two years, an arduous process which became more difficult over time. By contrast, the virtual EMS (which we shortened to call the VEC), would run on a VMWare virtual machine and we were isolated from any server changes the customer might make. The VEC was also a software based product, so we offered it for much less than $1000 retail price vs. the $3000+ price point of a server based version.  Over the next several years, more and more customers moved to the virtualized version of software and the demand for the server version declined.

A couple of years ago, I was asked to take over a new software-based load balancer (LB) product developed by a Dialogic software team in the United Kingdom. The back story here had some similarities to my earlier experience. The team was working with a major customer who really liked their software-based media resource broker (MRB), but had issues with the LB product offered by a major market player. The team built the software load balancer so that it could run either directly on a server or on a virtual machine. When we launched the product for use by all customers, our Sales Engineering team loaded the software onto their laptops using a commonly available virtual software program and were immediately able to set up prototype sessions and adjust configurations via the software’s graphical user interface. So the LB software was virtualized from the beginning.  This was part of an overall trend within Dialogic, as more and more of the software-based components of products were converted for use in virtual environments.

In the early days, virtualization in telecom was mainly for software tools like user interfaces and configuration, but that is now changing in a major way. The LB product from Dialogic runs in a totally virtual mode, so that operations as diverse as configuration and balancing streams of protocols as diverse as HTTP and SIP all are supported, along with very robust security. In the telecom industry, virtualization is being used in several different ways as part of a sea change where the new approach to scalability involves building additional capability and resiliency by adding new instances of software. In turn, this drives the need for new types of orchestration software, which can manage operations in a world where the new paradigm requires creating, managing and deleting instances based on real time needs.

In my next post, I’ll talk about other ways that virtualization is being used as a key principle for building out telecom operations in a variety of Cloud environments. Virtualization is still a relatively young technological movement, but it has already helped spawn some surprising developments.

If you participated in the evolution described here, please feel free to weigh in with your comments. If you’d like to explore strategies on how to evolve your application solutions or other communications products in this rapidly changing business environment, you can reach me on LinkedIn.