How to think and plan for CPaaS vendor lock-in when it comes to your WebRTC application implementation.
How can/should CPaaS vendors compete on winning customers? More than that, how can/should CPaaS vendors poach customers from other CPaaS vendors?
What prompted this article is the various techniques CPaaS 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 – or to be more specific, the part that deals with WebRTC implementation.
Table of contents
What is CPaaS vendor lock-in?
For me CPaaS (or Communication Platform 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 (such as embedding an iframe).
A CPaaS 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 phone to an iPhone 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 place are in another place
- The settings is done differently
- And the way you deal with the phone’s assistant (or Siri?) 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 vendor to another – to call that other vendor your new home.
Vendor lock-in has 3 aspects to it in CPaaS:
- Difference in the API 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 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 vendor’s interface or later when things break in production
- Integration 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 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 and the more interfaces, scenarios and code you have running on a CPaaS 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 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 of the main advantages of WebRTC is that a developer who uses WebRTC in one project for one 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 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 vendor’s SDK has its own interface indicating how things get done. And these may or may not bear any resemblance to the WebRTC API. 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 vendors aren’t standardized and don’t adhere to the standard WebRTC API 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 vendors is one of the reasons we’ve started down this rabbit hole of exploring what CPaaS vendor lock-in is exactly.
CPaaS vendor poaching techniques and how to react to them
Every so often, you see one 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 vendors.
When looking at the latter, here are the CPaaS vendor poaching techniques I’ve seen, how effective they are, and what you as a target company should think about them.
#1 – 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 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
- 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 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 (pre-WebRTC), we received inputs that our competitor can do almost 10 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 – Performance comparisons
Here the intent of the CPaaS vendor is to show that his platform is superior in its performance. It can offer better quality, at lower bitrates and CPU 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 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 vendors behave in different scenarios.
Zoom did this as well, comparing itself to other CPaaS vendors. Agora answered in kind with a series of posts comparing themselves back to Zoom (where Zoom 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 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 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 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 – Guides, how-to’s and success stories
How do you make the migration of a customer from a different CPaaS 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 vendor to another, I’d seriously consider reaching out to the CPaaS 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 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 – 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 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 of a CPaaS vendor gets used. But that’s about it. They are unlikely to be useful during the migration process itself
#5 – Shims 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, the most common one was supporting TwiML (that’s Twilio’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 vendor A has an API interface
- CPaaS 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 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 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 preference is ALWAYS buy (=CPaaS)
We’ve seen 5 different techniques CPaaS 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 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 party CPaaS vendor?
No.
Vendor lock-in isn’t necessarily a bad thing. My first 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 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.
- Limit the calls to the vendor’s API interface
- If you can make all of them from a single source file then great
- Even if not it is fine, but try not to call the vendor’s APIs and use their objects directly all over the place
- Having it all nicely compartmentalized will reduce the amount of changes needed during a migration
- Consider building an abstraction layer
- While I hate this one, it appeals to some
- Create your own abstraction of the communications capabilities you need
- Have that abstraction a “standardized” internal interface you follow
- Implement the integration with the vendor as a class/object of that interface
- This enables you to implement the next vendor or your own platform as yet another class/object for the same interface in the future at some point.
- Risky. As this probably will require architectural and design changes once that time comes, but it might still be the decision that can get your company to move forward
- Don’t use undocumented APIs and behaviors
- These will be harder to figure out in the future
- Making them harder to modify during a migration
- Assume there’s no simple solution
- No silver bullet or magic solution here
- Which means that time invested in catering for future multiple vendors or seamless migration paths is time wasted
- Try to make the decisions here ones that don’t take more resources or time today due to some unknown future need – you are more likely to make a mistake in these decisions than you are to succeed in it