Solving CPaaS vendor lock-in (as a customer and as a CPaaS vendor)

Created on November 12, 2023 at 11:25 am

How to think and plan for CPaaS CARDINAL vendor lock-in when it comes to your WebRTC application implementation.

How can/should CPaaS CARDINAL vendors compete on winning customers? More than that, how can/should CPaaS CARDINAL vendors poach customers from other CPaaS CARDINAL vendors?

What prompted this article is the various techniques CPaaS CARDINAL vendors use and what they mean to customers – how should customers react to these techniques. I’ll focus on the Video API part of CPaaS CARDINAL – or to be more specific, the part that deals with WebRTC implementation.

What is CPaaS CARDINAL vendor lock-in?

For me CPaaS (or Communication Platform ORG as a Service) is a service that lets companies build their own communication experiences in a flexible manner. Usually done via APIs and requires developers, but recently, also via lowcode/nocode interactions ORG (such as embedding an iframe).

A CPaaS CARDINAL vendor ends up defining its own interface of APIs which his customers are using to create these communication experiences.

That API interface is proprietary. There is no standard specification for how CPaaS APIs need to look or behave. This means that if you used such an API, and you want to switch to another CPaaS vendor – you’re going to need to do all that integration work all over again.

Think of it like switching from an Android ORG phone to an iPhone ORG or vice versa:

There’s a new interface you need to learn It might be similar since it practically used for doing the same things But it is also a bit “off”. The things you expect to be in one CARDINAL place are in another place The settings is done differently And the way you deal with the phone’s assistant (or Siri PERSON ?) is different as well

You need to install all of your apps from scratch Find them in the app store, download them, install them Set them up by logging in Some of them you need to purchase separately all over again Others you won’t find… and you’ll need to look for alternative apps instead – or decide not to use that functionality any longer

The behavior will be different The background color of the apps They way you switch between screens is different The swipe “language” is also slightly different

In a way, you want the same experience (only better), but there’s going to be a learning curve and an adaptation curve where you familiarize yourself with the new CPaaS vendor and “make yourself at home”.

The vendor lock-in part is how much effort and risk will you need to invest and overcome in order to switch from one CARDINAL vendor to another – to call that other vendor your new home.

Vendor lock-in has 3 CARDINAL aspects to it in CPaaS CARDINAL :

Difference in the API ORG interface. That’s a purely technical one. Low risk usually, with varying degree of effort Behavioral differences. This has higher risk with unknown effort involved. While both CPaaS CARDINAL vendors do the “same” thing, they are doing it differently. And that difference is hidden behind how they behave. Your own application may rely on behavior that isn’t part of the standardized official interface and you will find out about it only once you test the migrated application on the new CPaaS PRODUCT vendor’s interface or later when things break in production Integration ORG differences. There are things outside the official interface you might have integrated with such as logs collection, understanding and handling error codes and edge cases, ETL ORG processes, security mechanisms, etc. These things are the ones developers usually won’t account for when estimating the effort in the beginning and will likely be caught late in the migration process itself

Vendor lock-in is scary. Not because of the technical effort involved but because of the risks from the unknowns. The more years DATE and the more interfaces, scenarios and code you have running on a CPaaS CARDINAL vendor, the higher the lock-in and risk of migration you are at.

The innovation in WebRTC that CPaaS is “killing”

Before WebRTC, we had other standards. RTP and RTCP came a lot before WebRTC.

We had RTMP, RTSP, SIP and H.323.

The main theme of all these standard specifications was that their focus has always been about standardizing what goes on over the network. They didn’t care or fret about the interface for the developer. The idea behind this was to enable using this standard on whatever hardware, operating system and programming language. Just read the spec and implement it anyway you like.

WebRTC changed all that (ignoring Flash here). We now have a specification where the API ORG interface for the developer of a web application is also predefined.

WebRTC specifies what goes on the network, but also the JavaScript API in web browsers.

Here’s how I like explaining it in my slides:

One CARDINAL of the main advantages of WebRTC ORG is that a developer who uses WebRTC in one CARDINAL project for one CARDINAL company can relatively easily switch to implement a different WebRTC project for another company. (that’s not really correct, but bear with me a little here)

We now could think of WebRTC just like other technologies – someone proficient in WebRTC is “comparable” to someone who worked with Node.js or SQL ORG or other technologies. Whereas working with SIP or H.323 begs the question – which framework or implementation was used – learning a new one has its own learning curve.

Enter CPaaS…

And now the WebRTC API interface is no longer relevant. The CPaaS CARDINAL vendor’s SDK ORG has its own interface indicating how things get done. And these may or may not bear any resemblance to the WebRTC API PRODUCT . Moreover – it might even try very hard to hide the WebRTC stack implementation from the developer.

This piece of innovation, where a developer using WebRTC can jump into new code of another project quickly is gone now. Because the interfaces of different CPaaS CARDINAL vendors aren’t standardized and don’t adhere to the standard WebRTC API PRODUCT interface (and they shouldn’t be – it isn’t because they are mean – it is because they offer a higher level of abstraction with more complex and complete functionality).

Not having the same interface across CPaaS CARDINAL vendors is one of the reasons we’ve started down this rabbit hole of exploring what CPaaS CARDINAL vendor lock-in is exactly.

CPaaS CARDINAL vendor poaching techniques and how to react to them

Every so often, you see one CARDINAL or more CPaaS vendors trying to grab a bit more market share in this space. Sometimes, it is about enticing customers who want to start using a CPaaS vendor. Other times it is focused on trying to poach customers from other CPaaS CARDINAL vendors.

When looking at the latter, here are the CPaaS CARDINAL vendor poaching techniques I’ve seen, how effective they are, and what you as a target company should think about them.

# 1 MONEY – Feature list comparisons

The easiest technique to implement (and to review) is the feature list comparison.

In it, a CPaaS vendor would simply generate and share a comparison table of how its feature set is preferable over the popular alternatives.

For a company looking to switch, this would be a great place to start. You can skim through the feature list and see exactly what’s there in the platform you are currently using and the one you are thinking of switching to.

When looking at such a list, remember and ask yourself the following questions:

Is this list up to date? Oftentimes, these pages are created with big fanfare when a “poaching” or comparison project is initiated by the marketing department of a CPaaS CARDINAL vendor. But once done, it is seldom updated to reflect the latest versions (especially the latest version of the competitor). So take the comparison with a grain of salt . It is likely to be somewhat incorrect

. It is likely to be somewhat incorrect Check what your experience is with the vendor you are using versus how it is reflected in the comparison table. Does the table describe things as you see them?

The features that look better “on paper” in this table for the vendor you plan on switching to. Do you need these features? Are they critical for you today DATE or in the near future? Or are they just nice to have

The “greens” on the vendor making the comparison – are they on par with the other vendor or just a less comprehensive implementation of it? (for example, support for group calls – both vendors may support it, but one can get you to X users with open mics in a group call while the other can do 10X users)

👉 I’ve had my fare share of reading, writing and responding to comparison tables. A long time ago DATE (pre-WebRTC), we received inputs that our competitor can do almost 10 CARDINAL times the number of concurrent calls we are able to do with much higher throughput. Obviously, we created a task force to deal with it. The conclusion was simple – the competitor didn’t measure the network time at all – just CPU time in the machine. We weren’t measuring the same thing and his choice of metric meant he always looked better

👉 Your role in this? To read between the lines and understand what wasn’t written. Always remember that this isn’t an objective comparison – it is highly skewed towards the author of it (otherwise, he wouldn’t be publishing it)

# 2 MONEY – Performance comparisons

Here the intent of the CPaaS CARDINAL vendor is to show that his platform is superior in its performance. It can offer better quality, at lower bitrates and CPU ORG use for larger groups.

If a vendor does it on his own, then potential customers will immediately view the results as suspect. This is why most of them use third ORDINAL party objective vendors to do these performance comparisons for them (at a cost).

We’ve done this at testRTC a couple of times – some publicly shared (for this one, I’ve placed my own reputation and testRTC’s reputation on the frontline, insisting not to name the other vendors) and others privately done. It is a fun project since it requires working towards a goal of figuring out how different CPaaS CARDINAL vendors behave in different scenarios.

Zoom did this as well, comparing itself to other CPaaS vendors. Agora GPE answered in kind with a series of posts comparing themselves back to Zoom (where Zoom ORG didn’t look as shiny).

Just remember a few things when reading such comparisons:

They were commissioned. They wouldn’t be published and shared if they weren’t showing what the CPaaS CARDINAL vendor wanted them to show

For me, it is more interesting to see how the setup of the performance tests was done and what was left out or missed in the comparison to begin with The types of machines and browsers selected Scenarios picked Reference applications used for each vendor How measurements are done Which metrics are selected for the comparison

Who the vendor was looking to compare himself to

The CPaaS CARDINAL vendor usually helps and tweaks his own platform to fit the scenarios selected, while the competing vendors have no say in which of their applications or samples are used and if or how they are optimized for the scenario (hint: they aren’t)

👉 In the end, the fact that a CPaaS CARDINAL vendor performs better than another in a scenario you don’t need says nothing for you. Make sure to give more weight to the results of actual scenarios relevant to you, and be sure you understand what is really being compared

# 3 MONEY – Guides, how-to’s and success stories

How do you make the migration of a customer from a different CPaaS CARDINAL vendor to your own? You write a migration document about it. A guide. Or a how-to. Or you get a testimonial or a success story from a customer willing to share publicly that he migrated and how life is so much better for him now.

These are mainly targeted at raising the confidence level for those who are contemplating switching, signaling them that the process isn’t risky and that others have taken this path successfully already.

As someone thinking of moving from one CARDINAL vendor to another, I’d seriously consider reaching out to the CPaaS CARDINAL vendor and ask the hard questions:

How easy is the migration really is

What challenges should one expect

Are there any common issues that migrating customers have bumped into

How many such customers do they have

Can they reach out and ask one CARDINAL of those who migrated to have a quick direct conversation with

Anecdotes and recipes are nice. What you are after is having more data points.

👉 Read these guides and success stories. Try reading between the lines in them. Check if you have any open questions and then ask these questions directly. Gather as much information as you can to get a clearer picture

# 4 MONEY – Reference applications

I wasn’t sure if this fits for migrating customers because it is a bit broader in nature. But here we are 😎

In many cases, CPaaS CARDINAL vendors have reference applications available. Usually hosted on github. Just pull the code, compile, host and run it. You get an app that is “almost” ready for deployment.

You see how easy that was? Think how easy it is going to be to migrate to us with this great reference.

Remember a few things here:

Your workflow is likely different enough from the reference app that there’s work to be done here

In most cases, if you’ve built your application already on another vendor, using a reference app of another CPaaS vendor is close to impossible

Reference apps are just references. They usually don’t cover many of the edge cases that needs handling

👉 From my point of view, reference apps are nice to get a taste of what’s possible and how the API ORG of a CPaaS vendor gets used. But that’s about it. They are unlikely to be useful during the migration process itself

# 5 MONEY Shims GPE and adaptors

They say imitation is the highest form of flattery. If that is true, then shims and adapters would fit well here.

In CPaaS CARDINAL , the most common one was supporting TwiML ORG (that’s Twilio PERSON ’s XML “language” for actions on telephony events). There’s also the idea/intent of having the whole API interface of another CPaaS vendor (or parts of it) supported directly by the poacher. The purpose of which is to make it easy to switch over.

Clearing things up a bit:

CPaaS CARDINAL vendor A has an API ORG interface

CPaaS CARDINAL vendor B has a different API interface

To make it easier to switch from vendor A to vendor B, vendor B decides to create a piece of software that translates calls of A’s API interface to B’s API interface. This is usually called a shim or an adaptor

The result? If you’re using vendor A, theoretically, you can take the shim created by vendor B and magically without any investment, you migrate to vendor B. Problem ORG solved 😎

While this looks great on paper, I am afraid it has little chance of holding up in the real world 🥸. Here’s why:

The shim created is usually partial. Especially if vendor A offers a very rich interface (most vendors will, especially in the domain of video APIs and WebRTC) Like reference applications, these shims don’t take good care of edge cases. Why? Because they aren’t used by many customers ➡️ less customers = less investment WebRTC is rather new, and CPaaS CARDINAL vendors have much to add, so every time vendor A updates his CPaaS and adds APIs to the interface – vendor B needs to invest in updating the shim. But is that even done once a shim is created? Or is it again, placed in the afterburner due the previous rule ➡️ less customers = less investment Behavior. Same API interface doesn’t necessarily mean the vendor’s platforms behave the same on the network. These changes are hard to catch… and might be even harder to resolve Using a shim is nice, but if you want to use specific features available in vendor B’s interface – can you even do that if you’re doing everything via the shim? And is that the correct way to do things moving forward for you?

The thing is, that using a shim still means a ton of testing and headaches, but such that are hard to overcome.

If I had to switch between vendors, I’d ignore such shims altogether. For me they’re more of a trap than anything else.

👉 Someone suggesting you use their shim for switching over to their CPaaS? Ignore them and just analyze what needs to be done as if there’s no shim available. You’ll thank me later

Build vs Buy – my first ORDINAL preference is ALWAYS ORG buy (=CPaaS)

We’ve seen 5 CARDINAL different techniques CPaaS CARDINAL vendors use to try and poach customers from one another. For the most part, they are of the type of “buyers beware”. And yet, we do need to migrate from time to time from one CARDINAL CPaaS vendor to another. Market dynamics might force us to do so or just the need to switch to a better platform or offering.

Does that mean it would be best to go it alone and build your own platform instead of using a third ORDINAL party CPaaS vendor?


Vendor lock-in isn’t necessarily a bad thing. My first ORDINAL preference is always to adopt a CPaaS vendor. And if not to adopt one, then to articulate very clearly why the decision to build is made.

What should you do when you start using a CPaaS CARDINAL vendor to make the transition to another vendor (or to your own platform) smoother in the distant future? Here are a few things to consider.

Connecting to Connected... Page load complete