Today, Twilio announced Twilio Functions and while there are other very large API providers — most notably Amazon and Google — who offer serverless function capabilities as a part of their larger IaaS and PaaS portfolios, Twilio appears to be the first major API provider that, in addition to providing APIs, is also offering a serverless execution environment that’s specific to consuming them.
As API provider strategies go, the offering is revolutionary which is why other API providers should pay attention to what Twilio told ProgrammableWeb (below).
For those of you who are unfamiliar with the idea of serverless architectures, the phrase is a bit of an oxymoron but the concept is simple. Usually, when a software developer writes code to power some application, that code has to run on some system somewhere. Typically, that system might be a physical server in a data center or a virtual server in a cloud like Amazon's, Google's, or Microsoft’s. Containers (ie: Docker) often play a role too. In pretty much every case, a server along with all of the appropriate configurations and software (security, language support, etc.) — sometimes referred to as the “full stack” — must be provisioned to support the code (or maybe there’s an existing server that has already been provisioned). As a side note, devops (“developer operations”) APIs is one of the hottest API categories because of how such stack provisioning (and deprovisioning) can be both automated and event driven.
Once developers get down to writing their code, that code is typically broken down into smaller re-usable parts called functions. For example, a date validation function. While a serverless environment does in-fact involve a server, it’s not a server that the developer has to worry about. Instead, serverless environment providers like Amazon (Lambda), Google (Google Cloud Functions), Microsoft (Azure Functions), IBM (using OpenWhisk) and now Twilio offer a means by which the function, as a discreet unit of computing, is hosted in a public or private cloud with almost no concern for the rest of the stack that’s needed to support it. It’s as though the function is disembodied from anything that, to the developer, resembles a server. The steps to develop and host a function are greatly simplified and like with most other cloud services, the cost is typically a pay-only-for-what-you-use model.
But with behemoths like Amazon, Google, and Microsoft offering serverless execution environments in their clouds, what could possibly motivate an API provider like Twilio to offer similar services to consuming developers of its API?
“We asked ourselves what’s in the way of hello world?” Twilio vice president of product Patrick Malatack told ProgrammableWeb. Malatack noted that it’s a chore to get a full stack ready for development with Twilio’s API, or any API for that matter. The server has to be provisioned, the environment has to be properly configured, various libraries have to be installed, and a baseline of security has to be established. For example, since Twilio APIs involve webhook-styled APIs, firewalls might have to be configured to whitelist webhook traffic from Twilio’s servers.
“How do we eliminate all those things for developers?” Malatack rhetorically asked. “That’s what Twilio functions are about. You spend your time writing your app code and you don’t need to configure anything. That’s the idea.”
Then, according to Malatack, there’s a second class of problems once you’re up and running when you are provisioning your own server infrastructure. For example, how to run at scale. When you run your own stack, “You have to be thinking about things like spinning up more servers and load balancing” he said. This, of course, is not so with serverless approach.
With Twilio Functions, developers can log into the Twilio console and add as many functions as they like. The environment, as said earlier, includes all of Twilio’s helper libraries and developers are presented with a text editor (one that can autocomplete Twilio API calls, validate syntax, and offer hints) so that developers can just start coding. Developers can also upload assets such as MP3 files that serve as the on-hold audio for calls. “It allows you to configure your environment without having to configure machines” said Malatack. “This way, developers can focus on the creative and value parts.”
Another benefit has to do with performance. Let’s say a developer is calling a Twilio API from his or her own stack. That API call and any resulting traffic has to make its round trips on the Internet. In contrast, when using Twilio Functions, Malatack said that “functions execute in low latency. It’s inside our cloud so you don’t have to reach out [across the Internet]. We keep it in the same environment which means that your code can run faster.”
One obvious benefit to Twilio and any other API provider that might choose to tear this page out of Twilio’s playbook is additional revenue. While the service is in beta, developers will receive 10,000 free function invocations each month with invocations thereafter costing $0.0001 a piece. Depending on the degree to which Twilio customers embrace the functions offering, Twilio could be sitting on top of another significant channel of revenue.
However, the service is not without its downsides. As noted earlier, the only platform that’s currently supported is Node.js and Malatack would not speculate on the support of other server-side environments for which it already offers helper libraries; C#, Java, PHP, Python and Ruby. According to Malatack, Twilio went with Node first because "Node seemed ideal for what we were trying to do. Node, unlike Java, is really built for asynch apps out of the gate."
Another downside is that, for developers planning on mashing-up APIs from different providers within one function, there is currently no way to configure the environment for non-Twilio SDKs with Node Package Manager. In that case, developers must survive by interacting directly with the other services’ APIs or by restricting all service interactions within a Twilio Functions-hosted function to Twilio. Or, of course, go back to provisioning and running the code on a full-stack over which they have more control.