September 8, 2014
I’ve been working with WebRTC clients for over half a year now, and the initial questions they ask me have evolved a great deal since the beginning. Nowadays, the number one question is: “Why should I choose cloud WebRTC hosting over doing it myself?” The answer is fairly simple to me — time, money, and expertise. Allow me to elaborate.
First, let’s take a step back and think about DIY in general. Why do DIY methods exist? DIY is cheap. The biggest investment is time, which is arguably outweighed by the pro of learning a new trade or specific craft that you would have otherwise never had the chance to dip your feet in. DIY is also largely accessible. You typically don’t need to go to the store for most DIY household fixes. Everything you need is within your locale, disguised as something you walk past every day. These days, you can build a website — no, an entire company from the seemingly endless sea of open source solutions at our very fingertips. But why don’t we always choose this approach?
Trades have become more and more specific over the years. Within computer science alone, I’m sure this increase has been exponential. Therefore, the time it takes to learn how to develop, maintain, and deploy a specific open source solution with the best efficiency and security practices has also increased exponentially. For example, let’s talk about WebSocket, what could be considered one of the biggest catalysts for real-time communication via the web browser. If I wanted to add a text chat system to my web browser app, I essentially have two choices. I could run my own Socket.IO server, or I could find some experts, such as PubNub or Firebase, and have chat up and running in less than 30 minutes, without having to worry about all the highly specific security flaws and things that could go wrong had I ran my own stack.
I didn’t choose the technology in the above example haphazardly. As it turns out, WebSocket (and other technologies like WebSocket) is at the heart of WebRTC’s signaling protocol. WebRTC is a big, scary dragon that the average programmer would have trouble taming. Its innards consist of many open source protocols communicating with each other simultaneously. That said, it could take a small team to roll their own WebRTC solution.
I’ve come to this conclusion through the conversations I’ve had with many of our clients. The story is always the same. “We’ve invested a lot of time into spinning up and maintaining our own STUN and TURN servers, but we keep running into issues, and our TURN connectivity rate still isn’t as high as it should be. What are we doing wrong?” If you’re part of a small company looking to build a WebRTC app, I would strongly encourage you to at least look into cloud hosting. The many people in this demographic I’ve tried to convince a few months ago have been coming back to tell me that I was right.
Even large companies that have been struggling to increase their rate of successful TURN connections have resorted to using our platform. These companies even had a few of their employees permanently dedicated to maintaining their TURN servers. Slowly but surely, many companies are coming to the conclusion that choosing WebRTC cloud hosting over DIY is a no-brainer.
To take it all home, WebRTC is a very young technology that has only a handful of experts — compared to the rest of the web industry. Not only is the expertise limited, the technology itself goes through some major changes every few months, hinting at a degree of instability for your product. A small company shouldn’t be expending its already limited resources into watching the development updates of a new technology. They should leave it to the cloud company to do this for them and filter for only the important news. And this isn’t a technology you can become an expert in over a couple weeks. Even after a couple months, those super specific connectivity issues — those last few, crucial percentage points — are still pretty tricky to solve. But they are likely to be solved by experts who have been in the RTC business for over a decade.