Why Twilio points to the future of app development

Our definitions of the cloud keep changing. First we had application service providers, then software as a service, infrastructure as a service, and platform as a service. So what to make of a service such as Twilio?

It's a software as a service as a platform service, a set of APIs hosted in the cloud that let you build telephony into your applications — the cloud equivalent of those Visual Basic components you used to use in enterprise applications.

Call it component as a service, but whatever it is, it's part of the future of application development, where cloud and on-premises mix with mobile, and where users work alongside developers and administrators to build the next generation of business tools.

At its TwilioCon 2012 event in San Francisco, the company released a set of improvements to its platform, with new APIs and features that can help developers test and manage applications.

There's always been one issue facing anyone building a telephony app with Twilio: making calls or sending texts isn't free. That's meant it can be expensive to test an application, especially if bugs mean an out-of-control app eating dollars as it spews test messages in the ether — or at least to a test phone.

Registered developers can now get test credentials from Twilio that allow applications to be tested without affecting production code, and without breaking the bank. No actual calls are made, or messages sent, but the APIs used will send back the appropriate responses — so you can see what would have happened if those calls had been made, while making sure your code works.

That's not the only way to control call costs, as two new APIs are designed to help manage costs in a different way, offering usage reports and triggers.

The Usage API is simple enough, with a REST query that returns usage statistics for any Twilio operation, with an option to choose date ranges and time intervals, ready to feed into your analytic tool of choice — or into the your own billing applications.

Charging for actual usage

With an increasing number of telephony apps using Twilio, such as Burner's temporary telephone numbers, the ability to charge for actual usage is increasingly important — as is the ability to generate reports for specific phone numbers and for specific types of activities. Internal line-of-business apps can use the same metrics as part of dashboards, perhaps recording the calls made into and out of a helpdesk, or by a sales team from their CRM tools.

Triggers are more complex, as they need you to set up a webhook, which Twilio can use to inform your code that it's passed a set limit. If you've not used webhooks in an application, they're a useful tool that means a server can deliver a response to a specific URL at any time. It's perhaps useful to think of a webhook as an extremely asynchronous callback.

If you're using technologies such as node.js, implementing a webhook is easy enough, though there are now webhook libraries for most web servers and programming environments.

Once a Twilio trigger has been registered you can use it to trigger on any of a wide range of events. Perhaps you're tracking specific call-types, or capping users at a set usage limit, or even managing the costs of an entire application.

With Twilio's triggers you don't need to write complex monitoring code for your application. The cloud will do it for you, and all you need do is respond to events as they come in. Triggers can also be set to reset after specific times, so you can use them to set daily usage limits, or to manage subscriptions.

That's a lot of extra functionality, and it's all tooling that's essential to the enterprise developer. If you're adopting cloud services to minimise your costs, then you certainly don't want a bug in your code costing you the earth, or for that matter to lose track of how your users are using a service — or how much they're costing you.

With software components such as Twilio, it's important to control how they're being used, even if they're cloud services in their own right.

Twilio and Microsoft

At the same event Twilio and Microsoft also announced an extension of their existing relationship. With Twilio APIs already available to Azure developers building cloud applications, they're now part of the Azure Mobile Services platform. .

Consequently you'll be able to use them from Windows Store and iOS applications — Windows Phone and Android support will be added in a future release — that work with Azure. And you'll get the same 1,000 free text messages available to cloud applications.

Other TwlioCon announcements included the addition of WebRTC support in its client library, allowing real-time connections in the browser rather than through plug-ins, making it easier to build VOIP applications in the browser..

However, WebRTC is still only a draft standard, and support is limited to Opera and Chrome, with Firefox and Internet Explorer working on their own implementations.