What is vendor lock-in in WebRTC?

WebRTC lock-in explained: learn about its impact on flexibility and your ability to optimize communication technologies.

Vendor lock-in is a phenomenon where a company has a high switching cost from one vendor to another which is related to the costs involved in switching. These costs might be associated with time, resources or risks. The WebRTC ecosystem has its own vendor lock-in dynamics.

In this article, I want to touch the specifics involved in WebRTC vendor lock-in. I see it almost daily with my own clients when they need to figure out changes in their vendor selection and technology stacks.

The anatomy of a WebRTC application

We start by mapping a WebRTC application into its various pieces. It all stems from the main actors that exist in WebRTC:

To put things plainly, there are 4 main server types we usually deploy in WebRTC applications:

1. Application servers, holding the application logic. I am keeping these outside the scope of this article – they deal less with WebRTC and more with the specifics of your app
2. Signaling servers, which deal with the orchestration of sessions. These are “out of scope” in WebRTC by design, but are highly chatty (and bidirectional) compared to the application servers. They deal with signaling protocols and scaling that are important and relevant to the operation of WebRTC itself
3. STUN and TURN servers deal with NAT traversal. We need them at scale and as close as possible to the users
4. Media servers which aren’t really mentioned in the WebRTC specification, but most commercial WebRTC applications have them. These are used to handle things like group calling, live broadcasting and recording

Why do we even care about this? Because we can opt for different vendors in different server types or we can “bundle” it all together under a single vendor. From here on, let’s review the various alternatives and how they relate to vendor lock-in.

👉 You can read more about WebRTC servers

CPaaS and Video API vendors and vendor lock-in

Lets dig in, starting with CPaaS and VIdeo API vendors. These alternatives are the “all included” ones, where signaling, STUN, TURN and media servers are all provided by the vendor. These vendors offer other features and aspects outside the scope of these media servers, making switching even more challenging.

Using a Video API vendor is the ultimate vendor lock-in. Switching from one vendor to another is usually quite expensive and risky.

There are multiple reasons for this:

• No standard API, so the integration code needs to be rewritten from scratch
• Behavior differences. While platforms may support the same feature set on paper, in practice, how they behave may vary widely – especially in group calls and edge cases. This brings with it switching risks that can only be mitigated with rigorous testing
• Learning curve. There’s a need to learn the new APIs, behaviors and mechanisms that the new vendor has. This needs to be done while understanding the differences with the currently used vendor

At the point of switching, many companies decide to put up an abstraction layer in order to reduce the vendor lock-in risk. It can also be used to be able to use more than a single vendor – for the purpose of having multiple alternatives, have solutions for different markets or just increase their price bargaining power:

Managed messaging and signaling

When the time comes to decide on signaling, there are 2 things we need to choose from:

1. Which signaling protocol to use?
2. Do we self host or opt for a managed alternative?

That 2nd alternative is available mostly with proprietary signaling protocols. There are a few alternatives listed in this article.

In many ways, having a 3rd party handle signaling is an easy choice to make. There’s some vendor lock-in for sure, but there usually isn’t a compelling reason to switch away. The prices are usually reasonable, and the feature set is a lot broader than pure signaling – messaging today may include features such as push notifications support, chat logic, images and file management, content moderation, etc.

I don’t have a strong opinion here either way. In some cases, it makes a lot of sense to go with a managed messaging platform whereas in other cases, it makes more sense to manage and maintain signaling on your own. I give less focus on the potential vendor lock-in on signaling. To me, the more important of the two is going to be the decision of which signaling protocol to use.

The magic of managed TURN services

My fascination with managed TURN service should be known for those who follow me.

If there’s one piece of logic in WebRTC that you should always ask yourself if it makes sense to operate on your own or outsource it is your TURN servers.

And the reason is quite simple – they have no real vendor lock-in on the technical side: switching from one vendor to another is a breeze – the APIs are really simple to adopt – should take less than a day to make that switch.

Then again, the place where this becomes challenging is if you have many enterprise clients and you’ve instructed them on configuring their firewalls based on a certain TURN service. Now switching to another TURN service will mean going to all these clients and asking them to reconfigure their firewalls again.

Is one vendor better than another here? Hard to say. You’ll need to monitor your production for route trip time values to see if it regresses when migrating from one vendor to another.

The only apparent vendor lock-in managed TURN services have is in such cases. For the rest? The switch should be simple enough.

The allure (and challenges) of open source

Open source. Everyone wants free stuff. And WebRTC is no different here – especially open source WebRTC media servers. And then there’s libWebRTC itself which is… open source.

When opting to use open source in WebRTC, you need to remember that you still own all the problems and headaches. You haven’t “outsourced” them to the open source package. If something won’t work – you’re the one who needs to figure out how to solve it. There’s no SLA associated with what you’re using so you might or might not get the help you rely on or hope for from the people maintaining that open source package.

Using open source can be a big lock-in to a non-vendor which might end up being worse…

Remember:

• Some of the open source projects don’t have a home with a company that maintains them officially. This means the individual maintainer(s) may lose interest at some point, causing the project to die out slowly
• Other open source projects have companies or official teams behind them, but their focus is elsewhere. This means they likely won’t offer paid support and customization services or even be open to talking about roadmap and requirements you may have
• Switching from one open source package to another is just as hard as switching from one managed service to another

Here’s the thing – I am not against using open source – I am actually for it. But you need to understand the lay of the land – how the open source ecosystem for WebRTC is like and how the specific packages you are opting to use are governed and maintained.

Testing and monitoring

You can use managed services for your WebRTC testing and monitoring. I know… I’ve been the CEO and a Co-founder of one of these services until we got acquired.

Using SaaS for your WebRTC testing is rather straight forward. Since it doesn’t deal with the actual production service, there’s little risk in it. Only a matter of the cost associated with it.

For monitoring, there’s a different story. The main issue here is the history. If you have a hosted service collecting your monitoring data, then switching to another means starting from scratch, without any historical data points and insights that are available to you.

With testing and monitoring, it is less about integration, APIs and risks. It is more about learning curves and getting used to different applications.

Hybrids

There are two interesting Video API vendors out there that offer both a managed service and an open source route: 8×8 JaaS (Jitsi as a Service) and LiveKit.

In both cases, the story is simple: You can use our open source offering and switch to the SaaS offering or vice versa, keeping the code you’ve written in-tact.

Seemingly, there is no vendor lock-in here.

Then again, the devil is in the details.

There are a lot of operational pieces to this story that are proprietary and closed. Things from scaling, to regional deployment, load balancing, etc. Whatever requires more than a single machine usually ends up buried in the open source, potentially with a document explaining what you need to do about it, or just not there. This isn’t because of anything mean – just the fact that these parts are not usually found in open source projects. And let’s be frank – these vendors are there to make a living – not only give free stuff for nothing.

Anyways, this hybrid approach can be quite enticing for those wanting to take the middleground, not sure or just want the flexibility that comes with it.

Build vs buy decisions

Whenever we look at vendor lock-in and managed services for WebRTC, the question of build vs buy comes to the fore.

Here are a few aspects of it to consider.

Well defined KPIs

Know what you are going to look at when you select a vendor… have your KPIs (Key Performance Indicators) aligned properly and agreed upon inside your company. Then have the means to measure them.

If needed, think about doing short POCs on the relevant vendor platforms.

It might feel a bit drawn out, but it is important.

TCO, ROI and other acronyms

These are the financial terms that people throw around assuming everyone knows them (this isn’t the case most of the time – I always need a few seconds or more to get a grip around them myself).

The important ones here, at least for me, are TCO (Total Cost of Ownership) and ROI (Return on Investment). Oh – and there’s also TTM (Time To Market).

Estimate these. For both routes you are taking. And then estimate them for the vendor lock-in risk involved. Or more accurately – how would they look when you want to switch from one vendor to another.

Data sovereignty and governance

Who owns the operational data? How is it managed? Where is it stored and processed?

If you are going to be bound by such rules yourself, you need to make sure the vendors you rely on can work with these restrictions/requirements as well.

I’ve seen this lead to indecision or picking other routes (different vendors or going open source instead).

Privacy and security

Similar to data sovereignty, there’s a question of how privacy and security are maintained by the vendors you use. They need to be aligned with the requirements you have. In many companies, there’s also a need to go through security audits for vendors prior to adopting them, so better know about this sooner rather than later.

Core competencies and focus areas

This gets ignored most of the time.

What are the core competencies and focus areas of your business? What is it that you do best as you on the market?

If you want to make yourself shine and differentiate based on video quality, then you should have that as a core competency and build it on your own (likely using open source) and rely less on third parties.

Assuming you view communications as a commodity that is necessary – a utility similar to electricity or IaaS – then by all means, pick a vendor for a managed service and rely on them for it.

The approach you decide here should also guide you through staffing and skill levels needed in your engineering team. Oftentimes, the use of managed services doesn’t mean you can forgo engineers who are WebRTC savvy – it just means they don’t need to be able to recite the structure of an RTCP header or be able to implement packet pacing for the optimization of your bandwidth estimation mechanism.

Make sure not to forget your support team. They should be able to answer questions coming from users… and not just parrotting something like “out vendor says it is your fault” – that’s not working anymore. (Did I mention there’s a WebRTC support course here somewhere?)

Pick your poison but know your lock-ins

Which should it be? Build or buy? Open source or managed service? Mixed approach or all-in with CPaaS?

Do you prefer outsourcing the complexity but getting to vendor lock-in headaches? Or are you the one who loves the exciting route of self development?

Oh – and have I mentioned I’ve got just the thing for you? 🔮