Serverless computing takes another step forward

Last week at its Signal event in San Francisco, Twilio unveiled its new 'Functions' service.

Like AWS Lambda or Azure Functions, it's a serverless host for JavaScript code that works with Twilio's APIs. There's no need to spin up servers for a small number of calls, or to manage scaling on a busy service: all you need to do is write the code you need and Functions does the rest.

Functions isn't Twilio's first cloud-hosted environment for running code that uses its APIs. In 2011 it acquired TwiMLbin, a service that hosted static Twilio markup for testing and prototyping.

Twilio extended the service so you could use a TwiML bin as an endpoint for a call action, as well as for working with webhooks from other applications. When combined with the ability to host assets on Twilio's service, it gave you the ability to quickly experiment with adding voice and SMS to your applications, or to handle relatively simple, low-traffic applications.

TwiMLbins was one way to get started with Twilio, but it had one big flaw: it was limited to hosting and running static markup. More complex applications still needed you to spin up a web server or host code in a cloud PaaS service like Heroku or Azure. That approach works for when Twilio functionality is an adjunct to another application, but as the platform adds more tooling and services, it's less practical, especially when you're chaining Twilio APIs to build, for example, a cloud hosted contact center.

The launch of Functions is an interesting move for Twilio, but one that makes sense in the overall industry move from IaaS to PaaS. Why should you have to configure and manage a web server when all you want to do is connect a webhook to a little logic before firing off a Twilio API (or vice versa!)?

Building on existing cloud services, Twilio Functions is a tool for building cloud-hosted node.js code that handles Twilio API calls. I sat down with Twilio's GM Messaging Patrick Malatack after the Functions announcement to talk about the rationale behind the new service, and how it fitted in with the overall developer experience.

"We've been observing the common patterns," he told me. "What customers want are APIs for the services they use." With Functions, the APIs remain at the heart of the service, what's being added is a stateless programming environment for them to run in. A function triggers, it calls an API, or even a sequence of them.

Malatack suggests that Functions will improve the speed of development, as there's no need to think about scaling.

Like most other serverless environments Functions uses webhooks as triggers. You're able to define the type of webhook used, and Functions' code editor will help you extract payloads that can then be delivered to the Twilio APIs. It's a relatively simple environment at present, offering node.js functionality for your code. That makes sense, as node.js works best when treated as a switch in a message-driven environment. Messages for Functions come in on webhooks and once processed, the output is delivered through Twilio's messaging APIs.

Malatack sees the serverless model as a style of programming, where you need to think as little as possible about anything other than your code. "It's a progression for developers as things are abstracted. That's important as abstractions are better, they make it easier to focus on the outcome." It should result in developers getting more leverage, as there's no need to think about complex issues like scaling.

Of course, a cloud-only development environment is only the start, and Malatack notes that Twilio is looking at how to deliver tooling for developer productivity. Whatever it does, it's likely to integrate with existing developer environments and will need to work inside most developers existing toolchains.

There's enough built-in tooling to get started. Templates help get code written quickly, alongside live documentation. A built-in debugger simplifies the process of getting code working; so you don't have to pepper your code with console writes as you experiment.

Like most serverless platforms, Functions is stateless. That's fine for most operations, where you're taking an input and delivering an output, where there's no need for more than the process workflow in your Function. If you do need to keep state between actions, you can take advantage of Twilio's Sync service to store small amounts of information as JSON objects - for example, a URI pointing to content stored on Amazon S3 or similar. It's an approach that lets you do a lot more with Functions than at first meets the eye.

Twilio is doing something quite sensible here. They're taking advantage of existing serverless computing models to reduce their own operations costs, while giving you tools that do the same for you. It's a model that lowers the bar for everyone, making it easier to build and deploy telecoms code at scale.