Serverless CPaaS - how Voximplant anticipated this hype
This year we translated a good article about the Serverless concept: the author showed “on fingers” what it is and why. We also know and remember that our European partners long ago dubbed our platform as Serverless CPaaS - to explicitly confirm this, our CEO Alexey Aylarov spoke on October 16 at the API Days conference in Amsterdam. Alexey told why Serverless CPaaS will soon be ubiquitous and how it happened that Voximplant - suddenly - from the very beginning personified this approach. Under the cut you will find a text adaptation of the speech, excerpts from the presentation are attached. Welcome!
Before CPaaS, the business was forced to do a great deal of preparatory work: for a start it was necessary to choose a telecom operator. Then it was necessary to choose a backend and create an infrastructure for all of this (for example, take a software PBX Asterisk / FreeSWITCH and a file). To help this PBX also raise the backend on the conditional node.js ... And only after that decide where and how business logic will be implemented, and then fix it, set up monitoring and make sure that all this does not collapse in the process. The launch of a ready-made solution could take six months or more.
CPaaS made it possible to skip the low-level steps and immediately proceed to the business logic: for this, the client had to study the communication platform, and then ... infrastructure, deployment, monitoring. On the one hand, you no longer need to think about what the backend will be and look for a telecom operator. Due to this, the start time is reduced without loss of quality. On the other hand, much remains to be done on its side.
And then Serverless happened. And here it is necessary to focus on the key point - why less? Calculations must be done somewhere.
For devops, a serverless framework is most often taken (for example, Fn Project or serverless- oh, irony), which simplifies the development and assembly of applications. Also, the framework can provide pens for events; this is convenient because serverless is just an event-based concept (examples from telephony: a call came - this is an event, a call is answered - this is an event, etc.).
Add Serverless features to CPaaS and get the conditional Voximplant. As a result, the “infrastructure” step disappears - a business studies a specific Serverless CPaaS, implements business logic on it and quietly monitors how it all works without worrying about buying racks, servers, searching for room for the server, etc. Of course, this is an ideal case and each solution is unique: it is possible that the client may need some kind of hardware on its side, but Serverless in every possible way ensures that clients do not have such needs.
Sometimes serverless platforms do so-called. Functions are intermediaries between the client and other services ( FaaS concept ). For example, Functions can be assigned to accept HTTP requests and respond, or communicate via HTTP with third-party services. Here we can process web-hooch and telecom-specific interactions.
However, this layer has limitations:
From the very beginning, the Voximplant architecture made runtime available to clients, so call management is done using JS scripts, and not dry over HTTP. The integrated runtime provides several advantages:
Event-based is especially important because a) this is a unified approach b) adds flexibility. Any action can be interpreted as an event and processed in the cloud JS-scripts: answer an incoming call with voice synthesis, recognize voice mail and hang up, call a SIP call, send a push notification, etc.
As a result, our Serverless platform reduces latency, improves user experience and, ultimately, minimizes the launch time of the finished product: if it could be half a year before the CPAaS stage, then Voximplant can be kept within 1 month ( including all approvals and meetings, the immediate development time is even less).
Communication platforms based on the Serverless principle will be increasingly in demand, because the demand for these services is growing, as well as the functionality of the platforms themselves. Soon Serverless CPaaS will be able to offer data storage, deep integration with external systems (a good example is our Dialogflow Connector ), web server functionality, finally :) The prospects are bright, it remains only to monitor the implementation and rejoice at the progress of the Serverless concept.
It used to be better (s)
Before CPaaS, the business was forced to do a great deal of preparatory work: for a start it was necessary to choose a telecom operator. Then it was necessary to choose a backend and create an infrastructure for all of this (for example, take a software PBX Asterisk / FreeSWITCH and a file). To help this PBX also raise the backend on the conditional node.js ... And only after that decide where and how business logic will be implemented, and then fix it, set up monitoring and make sure that all this does not collapse in the process. The launch of a ready-made solution could take six months or more.
CPaaS made it possible to skip the low-level steps and immediately proceed to the business logic: for this, the client had to study the communication platform, and then ... infrastructure, deployment, monitoring. On the one hand, you no longer need to think about what the backend will be and look for a telecom operator. Due to this, the start time is reduced without loss of quality. On the other hand, much remains to be done on its side.
Welcome Serverless
And then Serverless happened. And here it is necessary to focus on the key point - why less? Calculations must be done somewhere.
Serverless does not mean the absence of servers at all, but their absence on the client side.The concept implies a bunch of compute provider + devops on the client side. The client does not need to maintain its own infrastructure, it is enough to pay the compute provider for ... calculations :) That is, there are expenses only when there is a need for calculations - this is much more profitable than, for example, paying for the rental of servers 24/7 when there is no real need use these servers 24/7. The lack of infrastructure leads to the second important advantage of the approach: you can not think about scalability, because The provider provides autoscaling.
For devops, a serverless framework is most often taken (for example, Fn Project or serverless- oh, irony), which simplifies the development and assembly of applications. Also, the framework can provide pens for events; this is convenient because serverless is just an event-based concept (examples from telephony: a call came - this is an event, a call is answered - this is an event, etc.).
Add Serverless features to CPaaS and get the conditional Voximplant. As a result, the “infrastructure” step disappears - a business studies a specific Serverless CPaaS, implements business logic on it and quietly monitors how it all works without worrying about buying racks, servers, searching for room for the server, etc. Of course, this is an ideal case and each solution is unique: it is possible that the client may need some kind of hardware on its side, but Serverless in every possible way ensures that clients do not have such needs.
Improving user experience
Sometimes serverless platforms do so-called. Functions are intermediaries between the client and other services ( FaaS concept ). For example, Functions can be assigned to accept HTTP requests and respond, or communicate via HTTP with third-party services. Here we can process web-hooch and telecom-specific interactions.
However, this layer has limitations:
- limited lead time;
- immutable context (stateless);
- Call processing is detached from the platform runtime, because the communication is over HTTP.
From the very beginning, the Voximplant architecture made runtime available to clients, so call management is done using JS scripts, and not dry over HTTP. The integrated runtime provides several advantages:
- cloud JS scripts support the latest language standard - ECMA2018;
- scripts use native platform API ;
- real-time control: event handling and function execution occur instantly;
- you can use the debugger with a stop and state'ami;
- You can attach anything to error handling, including voice alerts for a person. Example event-based error handling:
functiononHttpRequestFailed() { call.say(“Unfortunately, we couldn’t process your request, please try again later”, Language.US_ENGLISH_FEMALE) call.addEventListener(CallEvents.PlaybackFinished,(e) => { if (destroy) VoxEngine.terminate() else tryAgain() }) }
Event-based is especially important because a) this is a unified approach b) adds flexibility. Any action can be interpreted as an event and processed in the cloud JS-scripts: answer an incoming call with voice synthesis, recognize voice mail and hang up, call a SIP call, send a push notification, etc.
As a result, our Serverless platform reduces latency, improves user experience and, ultimately, minimizes the launch time of the finished product: if it could be half a year before the CPAaS stage, then Voximplant can be kept within 1 month ( including all approvals and meetings, the immediate development time is even less).
Future
Communication platforms based on the Serverless principle will be increasingly in demand, because the demand for these services is growing, as well as the functionality of the platforms themselves. Soon Serverless CPaaS will be able to offer data storage, deep integration with external systems (a good example is our Dialogflow Connector ), web server functionality, finally :) The prospects are bright, it remains only to monitor the implementation and rejoice at the progress of the Serverless concept.