Building your new WebRTC app, PaaS or not?

The Nimble Ape Team have been working heavily with the WebRTC technology for the past year and a half with the Respoke team in the US. I end up talking to a lot of people at events and conferences about what they're doing with WebRTC; it's a hugely exciting time to be doing anything with WebRTC - APIs in browsers are becoming more stable all the time, the Chrome team are doing awesome work with echo cancellation (even cancelling out typing noise) as well as dealing with those pesky 100% CPU Hangouts calls we all have - where our laptops sound like they're about to take off. It's an awesome time for WebRTC.

Something I ask everyone at these events is what they're using for their client library/infrastructure. Are they using their own incarnation? Are they using Asterisk with SIP over Websocket? Are they using a Platform as a Service such as Respoke or Tokbox (or the many others)? Are they using something open source like simple-peer or peerjs?

The answer stunned me for quite a while. 99% of the answers were "We're using our own signalling and client libraries". Wow.

It's an awesome time for WebRTC.

So yes, Nimble Ape work with the Respoke team on their PaaS; but again, this post isn't sponsored by Respoke and isn't the view of Respoke. It's views are mine and mine alone.

So why am I surprised so many people roll their own solution when there are great solutions already out there? Well; let's imagine my opinion means nothing... I went and asked on twitter for people's opinions.

Sam Machin told me he needed solutions that didn't require symmetric calling and the PaaS providers didn't seem to do that. I pointed out that I knew Respoke did; so what was the issue... it came back to documentation.

I completely get this. All of the WebRTC PaaS providers are clamouring to get features out as well as making things as easy as they can be for the end developer. Sometimes the documentation takes a hit. This is something all of the PaaS providers can be better at.

Saúl Ibarra Corretgé said that maybe it was down to privacy. Another great point. WebRTC itself is secure by design; that's a fact. What is also a fact is that these PaaS providers will have access to data such as who is making a call to who for example; how long those calls take; what medium they're using etc - because they all have access to the signalling information to setup those calls. Most of the PaaS providers also allow you to send messages through their infrastructure. So yes, I completely get the privacy aspect; and if you need to know that this kind of data is 100% held by you; I get why you wouldn't want to use a PaaS.

@dan_jenkins Privacy. Maybe latency to the PaaS. Also, what if they go out of business?
— Saúl Ibarra Corretgé (@saghul) April 20, 2015

maybe it was down to privacy

Sebastian Schumann agreed with @saghul about privacy but also said some other things about acquisitions and growing costs. I wasn't surprised to hear him talk about acquisitions to be honest with you.

@dan_jenkins Indepedence. It's early days, acquisitions will come. Plus unpredictability wrt costs when growing vs 1x effort. Also privacy.
— Sebastian Schumann (@s_schumann) April 20, 2015

Only yesterday it was announced that Cisco are trying to buy Tropo and other providers have come and gone through acquisition; leaving users of their services dead in the water. Coming onto growing costs; it's a fair point - depending on what PaaS you decide to use, your costs can soar very quickly and I expect you'll see some PaaS changing their pricing plans to better engage users - Respoke already did this for example.

Cisco are trying to buy Tropo and other providers have come and gone through acquisition

So, some great points why people don't use PaaS. But why am I surprised all these points make people decide not to use them? It's quite simple really. The goal posts keep moving - the WebRTC spec isn't set in stone and things do break. It's happening less and less but it does still happen. Another reason I'm surprised people don't use PaaS is for interoperability. We all know that the PSTN isn't dying any time soon. We also know that people love a good video conference - all of this requires some form of infrastructure and interoperability between PSTN gateways / MCUs / SFUs etc. This can be increasingly difficult to keep up with when running things yourselves.

My personal opinion is that I'd much rather pay someone else to take care of those headaches for me and let me and my team of web developers concentrate on the product, whatever that product is. A team of front-end web developers don't want to have to deal with running their own media relay servers and everything that comes with having to understand core level things within WebRTC.

I'd much rather pay someone else to take care of those headaches for me

Sebastian agrees with me here

@dan_jenkins Benefit I see: it's the early days so continuous adaption and improvement could be expected (eg adding ORTC at some point).
— Sebastian Schumann (@s_schumann) April 20, 2015

The benefit to being able to move quickly within my product far outweighs all of the complexity and probable extra hires I'd need to do within my Web company to be able to properly handle what clients will come to expect from your product - for it to have features that 'just work'.

I wrote the other week about Twilio joining the WebRTC front (well they were already there, kinda); this is sure to fire up the other PaaS providers in re-addressing their priorities and making the reason to choose a PaaS easier for everyone.

Why have you chosen to use a PaaS or to go it alone in some form or another? Let us know in the comments below or via twitter.