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.
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.
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):
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:
- 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.
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.