Chris Kranky

Recent Posts


Competing with the Twilio API

Chris KoehnckeChris Koehncke

apiAfter Twilio announced they had doubled revenues in 2013 to over $50m and were on a +1,000% growth rate every VC within 250 miles of Twilio’s downtown San Francisco office has rushed to pour money into anything that looks to be in this category of API-based communications. ┬áThe result a whole bunch of new of “O” companies. WebRTC is just adding more fuel to this fire. The opportunity – making communications easier and more accessible.

Twilio touts a top shelf reference list of well known companies. Frankly, this will be a hard train to stop. I’m not aware of a close #2 who might slipstream behind them. The further behind competition will be battered from Twilio’s jet wake turbulence. When pricing is already in the $ dot zero zero something range, you have to spin your hamster wheel really fast to make a sustainable business. Size matters. Twilio obviously has achieved this to some degree.

Twilio will be fine, the others may not,  but I have series of thoughts (this will take more than a single post) on what does a 3rd generation communications company look like, the Amazon of Communication Services. Specifically:

Architecture
Twilio doesn’t like to talk a lot about their architecture. Suffice to say they rely heavily on Amazon Web Services with SIP being a core protocol behind the scenes. To be the Amazon of Communications, you either are Amazon, or you’re pouring concrete to compete with them. I’m not sure I’d use SIP any more than I had to. SIP is aging and has numerous bits of duct tape holding it together, it’s also not good for multi-modal communications and struggles with mid-stream changes. Twilio relies heavily upon Asterisk, a choice I’m sure they wouldn’t make again. This isn’t about scale, but about how to continual reduce costs.

Multi-modal
These new companies are usually focused on doing voice, video or data or some sort of message notifications. Twilio is mostly voice (clearly the biggest segment). However, the winner is likely to be a player in all segments (don’t forget real time data). If you’re going to be the one stop communications provider, you’ve got to be the one stop. It will be tough to scale boutique “I do this one thing really well” if I have to assemble 20 companies to make it all work.

Video is also really hard. How to scale and re-scale on the fly multiple streams simultaneously for multi-point video isn’t something you learn by reading an RFC document. Throwing hardware at it just bumps the cost into crazy pricing. There is magic here and the Amazon of Communications will need this as a core capability.

Speed & reliability
No one is talking about this and this is worthy of any entire post itself. Using client side scripts works great as a trade show demo and for the $10 monthly big spender nerd in their basement, however, for serious production hammering hundreds of transactions per second, a different way of handling is likely needed. How do you overlay Heroku like capabilities into this mix?

Packaging
I need modular code and prepackaged applications that I can drop n’ go without thinking too much. Tutorials are where we are today with ‘hello world’ applications being the norm. This game will have to move up a notch.

Quality Internet
I’m not an engineer, but in my experience, when hell breaks loose, it’s usually due to some screwed up Internet path. I’ve seen it all. BGP table changes mis-routing traffic, ISP’s dumping their own traffic to a 3rd party so they don’t have to carry long haul, some low level Layer 2 switch incorrectly configured dumping packets periodically – fine for a normal data – awful for real time communications. ISP A arguing with ISP B about peering arrangements and secretive agreements that happen in the back room.

No vendor has been able to offer me credible story on why “their Internet” is better, price doesn’t seem to matter either, so I buy cheap, lots of it and multiple connections, praying the entire time. The current Amazon falls way short of good quality Internet, the Amazon of Communications will have this as pillar of their service.

Where to next?
Some more maturity of these offerings needs to happen before we whip our checkbooks. Let the cream rise so to speak. However a large company eyeing this market needs to be in active radar mode assessing the components that will need to bought, built and integrated. The biggest question to what degree do you need to compete and what degree must you compete in order to be viable.

I’ll pimp Tsahi @ BlogGeek.me who has an upcoming detailed report on WebRTC & API Platform that’s worth a look for those with a checkbook.