It’s easy to forget the telephone. We’re in love with the latest shiny piece of touch screen technology, and we ignore the fact it can be used to talk to other people – or to other computers. The dial pad is a simple user interface that’s worked well for almost fifty years, and familiar to people all over the world.
Twilio is a tool that lets developers use that user interface in your apps, working with the switches and services that make up the global telephone network.
To understand Twilio, you have to understand the component model of software programming. Back in the dim and distant days of Visual Basic, companies made a decent living selling software components, which made it easier to add features to programs, adding new views on your data and new ways of getting information in and out of a PC. You didn’t need to re-invent the wheel – just buy a CD-ROM and install the code you needed, link it into your app, and away you went.
Software development has evolved, but the component model is still there. Now it’s migrating to the cloud, giving developers a mix-and-match smorgasbord of APIs and services that you can plug into your apps. Some of them are deconstructions of existing cloud services, like Salesforce’s Data.com, while others let you bring features of a familiar services into your app, like both Google’s and Bing’s mapping tools. Others are more ambitious, built from scratch to offer APIs and tools that let you quickly add new features and services to your apps.
Twilio’s telephony-as-a-service platform is a prime example of this trend. There’s no Twilio app, no Twilio consumer-facing web site; just an API in the cloud. With just a few REST-based commands you can quickly add telephony features to your app or your service. Need to send a text? There’s an API for that. Need to route a call from one number to another? There’s an API for that. Need to build a phone app that works with your call center? There’s an API for that too. It’s a service built by developers, for developers, that’s completely transparent to the end user.
Recently Twilio announced that it was making its service available to developers using Microsoft’s Azure. Today it’s added Google to its list of partnerships, joining the Google Cloud Platform Partner Program. You’ll be able to add Twilio’s voice and messaging features to apps built on Google’s Cloud Platform – including sites and services that use Google App Engine.
If you’re already using App Engine, adding Twilio support is as easy as importing a new Python library or by using Twilio’s Java helper library in your Java apps. Once the tools are in place you can quickly add Twilio commands to an app, using REST calls and TwiML commands. The TwiML grammar is simple and easy to use, with commands to drive Twilio’s text-to-speech functions, as well as handling voice recording, and collecting and interpreting keypad tones. All you need to do is construct the appropriate message, and send it to the Twilio API you want to use.
There’s a lot you can do with simple telephony features in an app, but one of the most important gives you a new, easy-to-use, channel for input and output. The web, and the mobile web, aren’t as ubiquitous or as reliable as basic telephony. With Twilio and App Engine you can quickly hook the apps you use to your own custom cloud-hosted interactive telephony service. It’s easy to imagine a simple app that takes input from a field service engineer’s old Nokia and updates workflow and routing apps, perhaps sending additional prompts and responses via the Twilio text-to-speech services. Apps can also use SMS as a push service, sending URLs to smartphones, or text messages to users with older devices.
One problem facing anyone developing their own enterprise apps is security. How can you protect your apps, and their data, while still keeping them simple? You can use Twilio to implement an additional out-of-band security system to any app you make, giving you your own two-factor authentication.
Putting together a Twilio-based security system doesn’t require much additional work. Users logging into a site for the first time can be asked to register a mobile number. You can then generate a unique passcode each time they attempt to log in, and use Twilio to send that passcode to the user’s phone. Once they’ve typed in the code, they’ll be given access to the application. It may not be a RSA token, but it’s a lot better than storing passwords – no matter how well hashed – in a database.
Developers who want to get started with Twilio’s Google App Engine integration will also get 2,000 minutes of inbound calls to a Twilio number or an equivalent number of outbound text messages. With low cost inbound numbers available in 40 countries you can use Twilio and App Engine to extend your applications reach; if you use SMS you can send text messages to 196 countries, and voice takes that up to 208. Developing Twilio apps needn’t cost anything, as the service offers a set of developer APIs for application testing. These send the correct response back to your app, they just don’t make calls or send SMS messages.
This is the future of application development: treating the cloud as a Lego set of application components. You don’t need to write your own code to send SMS messages or make calls -- that's Twilio’s area of expertise, and they’re betting their business on doing it well. Instead, you can take the work they’ve done and hook it into your code in an afternoon with just a handful of lines of Python or Java. You get other benefits too, because as Twilio improves the code behind its APIs, the APIs themselves won’t change – you just get faster SMS delivery, or access to phones in a new country.