At its annual SIGNAL conference, Twilio today launched an initiative intended to make it easier to embed a variety of communication services within an application in the context of a DevOps process.
Quinton Wall, senior director of developer marketing at Twilio, said the open source Twilio Command Line Interface (CLI) tool, now available in beta, will make it possible to incorporate Twilio cloud services within a larger DevOps toolchain.
Twilio provides developers will access to a range of SMS, audio and video services that can all be incorporated into applications via application programming interface (API) calls. The pipelines created using those APIs now can be stored and shared via GitHub.
The CLI tool also makes it possible to extend those services via Plugins, said Wall. In addition, DevOps teams can invoke an existing serverless computing capability from Twilio to invoke the company’s services using functions, added Wall.
It’s not clear to what degree cloud services such as Twilio will be invoked using serverless computing frameworks going forward. Many of the capabilities that developers once were required to embed in their applications are set to become external services that applications call when needed by launching a function. While that approach makes the application more efficient, it puts additional pressure on IT teams to manage all the calls to various serverless computing frameworks within the context of already complicated DevOps pipeline.
While serverless computing frameworks are still an emerging IT platform, the rate at which serverless computing frameworks are being adopted suggests the day when they are commonly included with a DevOps toolchain is not very far off.
In the meantime, Twilio is clearly hoping that by making its communications services easier to invoke within the context of a DevOps toolchain will increase consumption. Twilio has long exposed REST APIs, but the CLI tool will make it easier for organizations to standardize on Twilio communication services across a range of applications. By exposing those services via APIs and a CLI tool, Twilio is betting that the days when end users opened a separate application to communicate are numbered. Instead, most users will invoke communications services within the context of, for example, a business intelligence application that is already open. That approach also eliminates the need to invest in dedicated network hardware to run unified communications applications that, from an API perspective, are often more difficult to invoke programmatically.
As DevOps processes become more widespread, it will be interesting to see how many other providers of cloud services start to routinely make available CLI tools. Arguably, any provider of a cloud service that doesn’t make a CLI tool available will find themselves on the outside of a DevOps process looking in. Service providers that provide a CLI tool will be preferred among organizations that embrace best DevOps practices. In fact, the challenge DevOps teams soon may face is not whether there is a CLI tool available, but rather determining which of the many available best fits within the DevOps processes they have adopted.
