When I started Proxylity, it was with an ambitious goal: to bring the benefits of the serverless model to teams working with non-HTTP systems. Not some, not a niche, not a curiosity, but a comprehensive solution.
Starting with plain User Datagram Protocol (UDP) has allowed us to build a solid foundation. We added WireGuard which provided security and privacy, and allowed more customers to adopt UDP Gateway with confidence. Then we did something different and invented Open WireGuard Endpoints.
Along the way we integrated with 14 AWS services, and enhanced them with innovations like Binary Range EXpressions (BREX) for extracting service parameters from binary payloads, and later doing data-driven routing to destinations.
We have been able to demonstrate that:
- Serverless architecture accelerates the software development lifecycle (SDLC) and makes distributed systems easier to manage.
- Datagram transport benefits applications by providing low-latency, non-blocking, efficient communication.
At the technology level we've made significant strides, but there is still much to be done. The reality is, our goal is challenging and requires careful consideration of both technical and organizational factors.
While we have deep support for many use cases, a category of important ones remains around the browser.
UDP in the Browser
Browsers don't support plain UDP, and they don't support WireGuard. The efficiency and performance benefits of datagrams are only available in browser environments via WebRTC.
The WebRTC DataChannel API provides a mechanism to send and receive unordered, unreliable datagrams and gives browsers a low overhead, low complexity and low latency transport. For browser based games, real-time trading applications, and other interactive web applications, this can be a significant advantage.
But there are limitations. Primary among them is that WebRTC is not a direct UDP socket. Communications are carried inside an encrypted Datagram Transport Layer Security (DTLS) channel, and wrapped in Stream Control Transmission Protocol (SCTP). These extra layers make it a deeply stateful protocol, and with the need for signalling and STUN/TURN in peer-to-peer use, challenging to implement.
To host a server authoritative WebRTC application (as opposed to peer-to-peer) using off-the-shelf components, developers need:
- a signaling server to coordinate the initial connection between peers
- a WebRTC library to terminate connections
- a server to host the WebRTC application
That small but real barrier can prevent a project from getting off the ground, and the ongoing cost can contribute to its shutdown. Compared to using serverless REST APIs, those risks are real, but REST comes with higher latency, more bandwidth, and the potential for blocking that damages user experience.
We believe the potential for high-performance browser applications using WebRTC is significant. And, we are committed to enabling WebRTC listeners in UDP Gateway with the advantages of the serverless model, making building such applications as simple and low-risk as possible.
The Path to WebRTC Listeners
This is a multi-step journey that starts with DTLS.
DTLS listeners are in select availability now (see below, or contact us), and will be generally available in UDP Gateway soon. Customers working with us in our limited availability program have been testing and providing valuable feedback. Our timing seems right as RFC 9147, which defines a DTLS 1.3 profile for use with WebRTC, is starting to gain traction. With its support for shorter handshakes, efficient encryption, early data and session resumption, this new profile will improve the performance of WebRTC connections. So, we'll ship with both DTLS 1.2 and DTLS 1.3 in the initial release.
Once DTLS is in place, we will focus on the SCTP layer, unlocking WebRTC data channels. The SCTP layer provides important safety aspects, preventing the abuse of network resources, and is required for browsers to establish WebRTC data channels.
And, of course, these new capabilities will adhere to our core philosophy: pay only for what you use, no cost at idle, enabling low-risk innovation.
For developers, this means highly responsive front-end applications that delight users with their speed and interactivity. It means building real-time features with confidence, knowing that the underlying platform is robust and capable. It means avoiding the headaches and cost of always on, high maintenance, costly server based backends.
For businesses, this means lower infrastructure costs, faster time to market, and the ability to innovate without constraints. It means not having to close down "long tail" systems because of the cost of operating and maintaining infrastructure.
We're very excited to be on the path to bringing these benefits to developers and businesses who've been burdened with legacy server architectures for far too long.
How to Engage
We welcome early adopters to engage with us through our design partner and limited availability programs, to provide feedback, and stay updated on our progress. If you are interested in participating, please reach out to us.