VoIP in the Cloud

4 min read

Reasons why people want to move to the Cloud

With today’s ever-increasing choices of technology, Cloud technologies have exploded in popularity and have moved beyond data storage.  Cloud computing is found almost everywhere, in every business sector; it is the fashionable new technology.

CxOs are testing the feasibility of VoIP hosting in the cloud, primarily due to fear of missing out (FOMO) in a hot market.  They are in constant debate with administrators over cost since they already view admins as cost centers which cost too much. Conversely, admins think themselves better than changing HDDs at 3am, with the Cloud actually solving this problem, and with the cost included in the Cloud’s price.

Many issues must be examined before deciding whether a Cloud-based architecture is the right business model for VoIP hosting.  This article examines some of the critical topics that businesses must consider before transitioning to Cloud technologies.

 

Old myths about the VoIP in the Cloud

In the early days of Cloud computing, the Cloud and virtualization were hostile to anything involving media and real-time communications. This resulted in jitter and poor call quality, causing a general absence of interest from service providers due to the likelihood of highly dissatisfied customers.  For example, Amazon AWS, a widely adopted system, was not built for real-time communications.

Today, however, we have Cloud-based real-time communication in technologies such as Alexa and Google Home.  They are not perfect, but in time and with proper integration, Cloud-based VoIP could make its way into both the home and business sectors.

 

Current status of VoIP in the Cloud

ITSPs are now starting to use the Cloud (AWS, Azure, etc) in the developed world because POPs (Points Of Presence) are limited elsewhere (in third world countries). But this is changing fast, as improvements to infrastructure are more easily made to support such architecture.  While the Cloud is not perfect for media and RTC handling and introduces anomalies, it is considered to be “just good enough,” so it is being adopted for VoIP implementation.

Over time, virtualization has evolved from software emulation to being “close to the metal”; this assists VoIP.  The more the Cloud can move away from simple software emulation protocols, the better its potential for use as a viable VoIP platform.  However, the technology is still imperfect, and for most consumers, “just good enough” is not the level of service they expect.

 

Can we move our current system to the Cloud as is?

The short answer to this question is: no. The cost is prohibitive, and a complete restructuring of the current architecture is required.  The typical stats of a company’s own server box are generally: 4+ cores, 32+ GB RAM, SSDs, Gigabit LAN, and highly centralized applications.

It is therefore not easy to translate that “usual model” from hardware to the Cloud. It just does not work, for a variety of reasons, such as the following.

  • The Cloud is too expensive for comparable powered hardware and services online.
    • Big instances are very expensive. Cloud providers (such as AWS) want you to buy a lot of smaller ones, increasing the overall cost.
  • Requires re-architecture. Breaking into containers is not enough, as the result will not be elastic, or dynamic, or scalable. In short, technology is not Cloud-native.
    • The current architecture is wrong for the Cloud (it should be built the Cloud way). Rather, it’s distributed: components can dynamically discover other components and it can assemble itself. It’s elastic, it scales up and down in response to shifts and workload dimensioning, and is fitted into the unit economics of the platform.

 

What specialists do we need?

Current system administrators are made obsolete by Cloud technologies.  It requires a new set of DevOps, with different skills from those of our current system admins, such as the following.

  • Linux sysadmin
  • Modern “Cloud” DevOps:
    • Orchestration (Ansible, Salt, Puppet, Chef, etc)
    • Discovery and synchronization (Consul, Serf, Kubernetes, etcd, Redis, Route53, etc)
    • Cloud platform APIs and automation, native load-balancers, complementary services
      • APIs are a big part of building something on the Cloud
    • Peculiarities of the Cloud platform (networking, limitations, the economics of instances, etc).

 

Will you save money?

When determining the benefits of converting to Cloud technologies, it is uncertain whether you will save money.  Depending on your current level of architecture and the size of the system, it is possible to save money, but you could equally possibly lose a substantial amount.  More market testing and studies must be performed across sectors, to determine the point at which a CxO will lose money instead of saving it.

 

Will it reduce risk and improve availability?

In the particular areas of failover, storage availability, and straightforward server failure, the answer is a resounding yes.  More generally, it will probably not reduce risk and improve availability, but the scope of the problem will differ.  Right now, Cloud technologies are good at meeting specific organizational needs.  But it does not replace a full developed system with an architecture that can perform at similar overall levels of reliability and security.  The Cloud has many vulnerabilities that are constantly being targeted.  However, as with any other architecture, as time passes these vulnerabilities will lessen.

 

What kind of problems will you have?

When you own the infrastructure, you are responsible for failover and high availability (such as how a heartbeat is regulated by a pacemaker).  Furthermore, providers are responsible for their own operational problems, with administration being responsible for redundancy and upkeep.

 

On the Cloud

When on the Cloud, the unexpected can occur.

  • You will have to battle with the Cloud platform itself at a broader, more macroscopic level
    • Cloud-based systems can and do have outages, as well as performance quirks of their own.
  • The company culture will have to adapt to new kinds of problems
    • Example: DB procedures and triggers; AWS DB version (Aurora) is not viable for this.

Resource constraints are often invisible or not obvious, and include:

  • PPS and bandwidth limits;
  • backbone and transit transfer limits;
  • network and reachability problems, as consequences of Cloud product rather than technological limitations;
  • not necessarily published;
  • occasional scheduling and contention and hypervisor problems.

All these difficulties have their à la carte solutions (VPN plan, etc) but they become yet another line item on your bill!

 

Is it worth it?

In the end, it is probably not worth it. However, in order to make a sound decision, a company must weigh all the factors.  For example, for new systems built from the ground up, with a strong backing team, this could be a very viable business model.  For an established company with good system admins already in place, restructuring the business architecture to support the needs of the Cloud will probably be too costly in its current state.

That does not mean you should dismiss the Cloud from all future considerations. As technology advances, further studies can be performed to determine the cost-effectiveness of switching platforms.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *