Is the Future of CPaaS Serverless?

November 27, 2017

Twilio isn’t the first CPaaS vendor to offer serverless. And it definitely won’t be the last. Expect serverless CPaaS offerings in the future.

When I started researching for my first WebRTC API platforms report, one of the vendors I looked at was Voximplant. One of the things they referred me to was something they call VoxEngine. As its web page describes it, it is “an application engine that runs your apps inside the VoxImplant cloud” = Serverless.

I liked the idea, but didn’t think much of it at the time. It was rather new anyway.

What is Serverless Computing?

If you haven’t been following the API scene, then you might have missed the notion of serverless computing. It is a concept where the code you write gets executed by the cloud. Directly. No need to run your own OS, VM or whatever container. Write the code. And it runs. Magically.

If you look at the compute models of XaaS, here’s the picture you’ll probably find:

  • If you use On Premise, then you’re in charge of EVERYTHING
  • With IaaS, everything up to the operating system is something “someone else” is taking care of. Amazon, Google, Microsoft or someone else entirely
  • Then there’s PaaS. With it, everything up to the runtime is something “done for you”. Your data and application are yours to worry about. You connect with the runtime via APIs (not always, more quite common)
  • SaaS is just getting the whole thing out of the box. Not our worry here

Where would Serverless fit in?

With Serverless, you write the “Application” but it and its data get handled and maintained by someone else.

What do you gain out of it?

  • Scalability – you no longer need to care about it. Someone else now does that for you. You wrote the core logic of what you want to achieve, and the platform hosting your code is the one that needs to sweat it when it comes to scaling the thing as needed
  • Maintenance – less code means you have less to maintain. And you’re shedding here all the boring work of getting the thing to work. In a way, you’re writing the initial prototype, and have it run in production
  • Security – assuming the PaaS vendor handles the headache of security well, then you have less to deal with here
  • Time to market – less to write also means faster time to market. It will take you less time to get that application in the hands of customers
  • Latency – since the code runs directly on top of the PaaS APIs, on the servers of the same vendor, there a lot less latency involved in the API calls. Might be important, or might not be – just a fact

What do we have here then? Economies of scale at play. The vendor doing PaaS is already handling scalability, maintenance and security for you and a lot of other customers, so theoretically, he is doing and can do a better job of it than you can in the long run. This free you up to focus more on the user experience, ending with a better application and faster time to market. And there’s the added benefit of where the code is running (closer to the rest of the code).

Serverless = Functions

While Serverless is the popular name, there’s another one that has been coined – FaaS – Functions as a Service; which then made it into the names of many of these products: Google Cloud Functions, PubNub Functions and Twilio Function to name a few.

The most widely known example is probably AWS Lambda; and then there’s the open source project Apache OpenWhisk.

Many API vendors now are starting to offer these serverless capabilities – so now you no longer need to have a server of your own connected to their service – you can just run your code in their XXX Functions product instead.

In some cases, using these Functions product is free, while in most cases, there’s a usage based payment model on running these Functions.

Serverless CPaaS

Back to CPaaS and where serverless fits.

I think there are only two vendors in the CPaaS market today who are offering serverless (If I missed anyone – please share in the comments below):

  1. Voximplant, via their VoxEngine
  2. Twilio Functions

In the last Twilio Signal event in London, Jeff Lawson mentioned that Functions was Twilio’s fastest growing product since its launch, so there must be a market for that.

CPaaS is slightly more complex these days, so it is important to see what serverless fits first. Let’s split CPaaS into a couple of API layers and products:

API Layers

  • Scripting language such as TwiML and NCCO
  • REST API
  • Client SDKs

Products

  • SMS and voice (via phone numbers)
  • IP messaging, chat and omnichannel messaging
  • VoIP (voice and video via WebRTC)

In some ways, the proprietary scripting language API layer can be viewed as a crude form of serverless. You state your needs inside a piece of script that indicates the flow of actions to take on events, offering it as response to webhooks from the CPaaS vendor.

The REST APIs are those that are easily usable within a serverless environment. Instead of making remote calls via APIs from one server to another, handling things like security, authentication and scale, you just run the call as close as possible to its destination.

And then there’s the client SDKs. These run on the target devices themselves, and it is hard to see how you can translate them into serverless – they are already built to communicate with the CPaaS vendor’s backend, so they’re out of scope here.

Since CPaaS products are roughly aligned by the types of API layers that are used for them, we can reach the following conclusions:

A few things to note here:

  • IP Messaging makes more sense to run in serverless computing when traffic is high and latency is important
  • Latency is usually less of an issue when it comes to SMS and voice
  • VoIP has its own set of solutions other than serverless. These usually come in the form of pre-built widgets and iframes (but that’s for another article)

From a vendor’s perspective, serverless is now becoming important.

Why?

Simply because it is part of Twilio’s runtime offering. And one that Twilio states is growing rapidly. I wouldn’t want to be left behind as a competitor.

Why not use an IaaS vendor’s FaaS offering?

Just had to put these two in the same sentence.

Since the dominant IaaS vendors (Azure, AWS and Google Cloud) all have a serverless offering, why do you need one in CPaaS? Can’t you just connect the IaaS one to the CPaaS one?

You most certainly can. But you will be using two different vendors now. And to some extent, using something like AWS Lambda only makes sense if you are already making use of multiple AWS services.

Assuming what you do gravitates around communications, then using a Serverless CPaaS product makes more sense. It will bring with it reduced latency and improved security over using an external serverless product.

Serverless is coming to CPaaS

Like it or not, serverless is coming to CPaaS.

If you are  a CPaaS vendor and you are asking yourself what’s next – make sure you’ve got serverless in your offering or your immediate roadmap.

If you are a developer using CPaaS – see if serverless can help you develop your application faster.

Selecting a CPaaS vendor for your WebRTC application? Check out my WebRTC APIs report

You may also like

Comment

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

  1. When I read the title, I though that you were going to introduce CPaaS on P2P basis.

    For me, servers in the cloud are still servers, and they scale… Well, they scale better than ‘On Premise’, but too often they price is too high. Many cloud solutions let you start cheap, but become very expensive as your demands grow (I believe GCP takes this to extreme). But even if the pricing model is fare, the communication requirements aren’t. In a crowd, connections grow faster than O(N).

    That’s why distributed service that relies on the power and connectivity of end users’ devices, could deliver a great boost. There are lots and lots of technical problems with this, and we know that Skype abandoned this model when the mobile clients became more prominent.

    But now the mobile networks and devices are much more powerful than before, and it may be time to give P2P communication a second chance.

    1. Alex,

      The name is indeed stupid, but I didn’t pick that one up…

      As for P2P, that won’t fly. At least not today. There are cases where it doesn’t work without relaying via TURN servers. And in most cases, any group sized meeting cannot be handled without a server to route the media around. A fact of life.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}