Visit our Migrating From Twilio Video Resource page.
The big news this week is that Twilio Programmable Video is being sunsetted. Many companies are considering what their next step will be and how to transition away from Twilio for their video services. In this blog post, we’ll talk about a few things you need to consider when switching CPaaS providers or moving from one open source media server to another for your WebRTC communications application.
This advice applies whether you are currently using Twilio Programmable Video or not. Video providers will come and go occasionally, but your need for a reliable live video infrastructure will not!
First, an update in the wake of Twilio’s big announcement.
The deadline to switch from Twilio Programmable Video, and why not to switch to Zoom’s APIs
Twilio has announced that the official End-of-Life date for Twilio Programmable Video is December 5, 2024. A year or less is enough time, but not a lot of time, to make a major infrastructure change in applications that are already in the market and operating at scale. The time to get started on switching is now and we can definitely help!
Twilio’s EOL announcement recommends that customers consider using Zoom’s APIs. This is likely to keep businesses from switching to options like Vonage and the Amazon Chime SDK, who compete with Twilio on messaging and voice products. (For more on why Twilio Programmable Video has made this change, see the analysis by our CEO Arin Sime, and also an excellent post from industry analyst Tsahi Levent-Levi. There are also a lot of good conversations happening all over LinkedIn.)
The Zoom APIs are fine for certain use cases. But there’s a reason we don’t work with them here at WebRTC.ventures.
The Zoom APIs won’t give you the control or granularity that you need for sophisticated web applications that integrate with other services like generative AI and in unique workflows. If your use case happens to fit well in Zoom’s model of “video conference with a different logo on it”, then it may work just fine. Our clients are generally looking for differentiated workflows which provide additional value to users and to them as a business. For that, you need to look elsewhere than Zoom.
Starting with the CPaaS vs Open Source Architecture choice
There are three main approaches for embedding real-time communication features into your web or mobile application. You can rely directly on the base WebRTC APIs (often called a native application or “building to the standard”), build on an open source media server (like the Janus WebRTC gateway, MediaSoup, or LiveKit) or use a CPaaS (such as our partners Vonage, the Amazon Chime SDK, Daily, or previously, Twilio Programmable Video). My favorite post on making this important architectural decision is an oldie, but a goodie: Native, Open Source, or CPaaS?.
When time-to-market is important or you don’t have the technical expertise to run your own infrastructure, leveraging the pre-built communication infrastructure and functionalities of a cloud-based CPaaS is often the way to go. Need to confirm your choice? Check out: Is a CPaaS the Right Choice for My WebRTC Application?
As our CEO and Founder, Arin Sime, wrote earlier this week:
Over the years, we’ve helped many customers move from one vendor to another, as well as between commercial APIs and open source media servers (in both directions). We don’t consider these changes as necessarily a bad thing or as a bad reflection on whichever company is being left behind by that customer. There are a lot of WebRTC use cases and implementations, and sometimes, a particular CPaaS just works better or has better pricing for a specific customer’s use case and implementation.
This begs the question: what do you need to consider when switching CPaaS providers?
5 Technical Things to Consider When Switching CPaaS Providers
1. Feature compatibility
Most CPaaS offerings have a public listing of similar features that they support. The first thing to consider is whether the advertised CPaaS features line up with each other. The devil lies in the implementation details. Building a proof of concept for your switch could be crucial.
Many vendors offer recording features, for instance, but how that recording works may make a big difference in how it performs at scale. A good example of this is that open source projects use a headless browser as a meeting participant to make the recording – a resource intensive approach that doesn’t scale well.
How recording is implemented may also be different across vendors. For instance, you can sometimes choose if you want the recordings to be of each participant’s stream separately (gives you more flexibility, but may make it hard to recombine if people are coming/going from the recording), or composed (a single recording where the CPaaS vendor determines the layout of the recording and you may have less ability to customize it).
Be sure to research or prototype each feature your application relies on in order to understand if the user experience will be the same (or maybe even better!) as you move to a new CPaaS. Some user interface changes should be expected, a surprise you don’t want discovered by your users on launch day!
2. Media server architecture
Is your CPaaS or open source media server based on an SFU or MCU architecture? If you don’t know what that means, check out one of our most popular videos that explains the difference.
Some applications require an MCU implementation to interface with external applications such as a traditional telephony network. This is particularly true in use cases where audio and/or video streams need to be mixed together before being provided to that external application.
Other applications rely on having individual video and audio streams from each participant available, as an SFU architecture would provide. Those streams can be individually manipulated, stored, or fed to external AI and ML applications for further processing.
3. Programming language of SDKs available
Most CPaaS vendors offer Javascript, iOS, and Android SDK’s for you to code against when using their service. The quality and depth of those APIs might vary across providers, so it’s not just a matter of changing code to match the new interface.
If you’re looking for particular mobile library support like Flutter, that is not available across all CPaaS vendors. Realizing this too late could cause significant architectural problems.
Looking at the details of the SDKs is also important. This may affect the way you present features to users, or even change your workflows. For instance, maybe you have an EdTech application where instructors need to mute individual students or everyone at once. The way that muting others’ audio streams works could vary across different CPaaS implementations. Not paying attention to details like this could force unwanted interface changes on you and your users.
4. Compliance/data protection
If you work in the public sector or in a regulated industry such as healthcare or education, compliance and data protection are particularly important. Are you users based in the EU and so you need to comply with GDPR regulations? Not all CPaaS providers offer that. If you build with an open source solution, you’ll have to implement it yourself regardless.
CPaaS vendors also offer different types of support, documentation, and pricing for things like HIPAA compliance. This is a critical consideration, especially since the pricing may vary. And speaking of pricing …
5. Cost/pricing structure
Pricing models vary quite a bit across the various CPaas providers. Are you charged per connected user, or by data transferred? Are you charged extra for recording? Are there different types of recording (such as composed or individual streams) which incur different fees? What about broadcasting costs? This may not be a technical consideration per se, but the CPaaS costs can definitely affect how you choose to implement your solution with a particular provider, or even more so as you change providers.
Open source media servers don’t have a direct cost to use them, but you still have to consider the cloud infrastructure they run on as well as the time and expertise of the DevOps and cloud experts on your team who manage and scale them for you.
Another option: adding an abstraction layer
Adding a CPaaS abstraction layer frees you from making your application dependent on any specific provider. Our post, How to Incorporate a CPaaS Abstraction Layer in WebRTC Applications, goes through that process.
Change takes time. Start now!
Twilio is giving one year for users to switch to a new CPaaS. Those with the simplest implementations may be able to quickly make a decision on a new CPaaS and switch in a couple of weeks. Companies with more complex technical considerations should not rush to deploy the change. There is much to consider. You want the change to be made with the most information and in the most high quality and scalable way possible – so that your users never even know it happened.
A year is enough time, but not all the time in the world. Our team at WebRTC.ventures would be happy to help you assess your current application, compare different CPaaS and open source alternatives, and help you decide on the best way to migrate between providers. Contact us today to get started!
