This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
You want to embed real-time communications features into your website or mobile application for direct peer-to-peer communication and you’ve landed on WebRTC. That’s a great start.
Now you realize that backend services are critical for building a robust solution. You are thinking about hosting your solution in the cloud, using an Infrastructure-as-a-Service (IaaS) environment built on top of Amazon Web Services (AWS). Again, good choice. AWS is an obvious first place to look as they’re a leader in the cloud services space.
However before you start firing up AWS Elastic Compute (EC2) instances, S3 buckets, and more, it’s important to understand what’s involved.
Here are ten things you need to know before deploying WebRTC on AWS:
1. Don’t expect absolute perfection: AWS offers premium infrastructure services. More often than not it exceeds expectations, but it’s not perfect. Expect periodic EC2 failure and varied latency of services. Have a plan in place to work around the occasional issues that you will encounter (see below), and you won’t be caught off-guard.
2. Availability is critical: In an ideal world one server would have enough capacity and speed to reach everyone without any issues. Unfortunately that is pure fantasy, not reality. To ensure your services are always available, design with failure in mind and leverage availability zones for redundancy. Plan for seamless failover both horizontally and vertically. Redundancy will prevent widespread downtime during failure scenarios or when the unexpected happens. You never know when an undersea fiber line might get damaged or when there will be a regional blackout.
Remember: Monolithic services fail as one. Redundant micro-services fail in isolation. When properly designed, they can recover quickly for minimal service interruption. Consider using rolling deployments, to prevent service delays and unexpected outages. And make sure you thoroughly map your hardware! Consider the ramifications for each component if it should stop working, and plan for queuing or re-routing.
3. Security and availability are opposing concepts: Don’t count on Amazon to keep your architecture secure. Amazon will provide the hardware, but it’s your job to secure your infrastructure against unauthorized access, data exposure, and the ever-present threat of DDoS attacks. Bear in mind that AWS is a top target for hackers, so securing your instances is vital, as is scanning for advanced threat campaigns. The default security safeguards do NOT offer enough protection. Creating secure services that are also highly-available requires careful planning not just at the service level, but at the per-connection level; security is the antithesis of availability.
4. Network monitoring is also your responsibility: Traditional monitoring tools are not effective for monitoring WebRTC, including those provided by AWS and other off-the-shelf solutions. Set up a real-time network analysis and capacity monitoring system that offers custom metrics, so you can fix problems quickly when they arise. Otherwise, small problems can go unnoticed and could lead to extended periods of service disruption. The trick is to identify trending deviations from expected performance before customers do. With WebRTC it’s not always about full service outages.
5. You can lean on AWS for help but they won’t hold your hand: AWS expects customers to manage their own environments. Even so, the AWS team is incredibly supportive and will go to great lengths to improve overall performance, scalability and efficiency. Don’t hesitate to ask for help when you need it. It could prevent costly errors. A Business Support Subscription is a worthwhile investment, just in case. Also, understand that while AWS architects will offer guidance to the best of their ability on WebRTC-related infrastructure challenges, they won’t be able to provide the same level of guidance that they would be able to offer for high-volume transactional services.
6. Set up billing alerts: Consider using Amazon CloudWatch to set up billing alerts so you don’t lose track of your service charges and usage. Otherwise, you could receive a hefty bill at the end of the month. Bandwidth utilization and EC2 instance operational costs can add up quickly if you are not paying attention.
7. Failing devices should be de-commissioned immediately: Not all instances are created equal, even if they are of the same class. Network issues can arise unexpectedly due to hardware failure, so make sure to benchmark and replace those that fall out of spec. Remove impacted nodes and launch new ones even if the issue is resolved. Otherwise, the device could unexpectedly fail again. Track and choose only the best instances.
8. Right-size the instances you use: Amazon offers many types of computing instances, and each one is optimized for different types of resource requirements. There are different configurations for processors, network capabilities, memory, and so on. There is no single best option for backend WebRTC services. Again, it all depends on your needs. Expect to benchmark, test, tweak, and repeat to find the best balance. Be aware that some instances come with limitations. For example, watch out for the CPU credit scheme on some of the lower-end instances.
9. Right tech, right tools: Make sure that WebRTC is the right solution for your needs. WebRTC is ideal for many, but not all applications. Scenarios where you need near-time and not real-time (like a viewer streaming live media or a broadcast) are not a fit for WebRTC. Amazon offers great solutions for streaming a la YouTube or Netflix, and is an ideal solution provider for that task, as well.
10. A PaaS provider may be your best bet: As a product owner or developer, your main goal is to create a great product that will delight users and (in many cases) reduce time to revenue. Hosting your platform on AWS will help provide a firm backbone for your WebRTC backend services if you keep these points in mind, but a DIY build-out can be costly and time-consuming. To accelerate your time to market, and retain product focus, consider utilizing a third-party PaaS provider. A PaaS provider will remove the daunting challenge of building and maintaining a real-time communications component. It’s less risky, and it will shorten your time to market.
Temasys is an embedded real-time communications platform as a service (PaaS) provider that enables customers to build real-time communications features into any app, on any device, at any scale. Temasys is a working member of both the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). The W3C and IETF provide an implementation of the WebRTC standard used by Google Chrome, Mozilla Firefox, and Opera. Temasys also helps bring WebRTC to the to the Microsoft Internet Explorer and Apple Safari desktop browsers.