I understand the concern. It can be a great convenience to not run the servers yourself, as people have been doing for decades with respect to websites, apps and APIs. That's essentially the same model, with the host terminating HTTPS for you.
...lossy UDP
All networks are lossy, and all transports. The difference between UDP and TCP based transports is who decides how to handle it. With UDP the application developer decides; with TCP (and QUIC) the protocol decides. More and more projects are taking-on the reliability decision, for a lot of reasons that trace back to this difference.
..some random guys on the Internet
Essentially; and that's how everything starts. We've been in production since early last year and have maintained >99.99% availability. We're a certified partner with AWS, and have "qualified software" (it passed their security review), and our security posture report is available from AWS Marketplace. We aren't SOC-2 audited yet because we want to do it right rather than pay for a rubber-stamp report, and that takes time and a lot of money.
I know it is a marketing thing, but I simply dislike someone offering a server calling it serverless.
That being said: OK, so basically your service is to be treated as an Internet overlay. That can be fine. But then you should point the advantages of that. Using anycast and your internal peerings, are you better at routing packets than BGP on the open Internet? Are you able to hole-punch NAT to connect two NATted endpoints?
If so, this would be a service I might want to use.
As others have pointed out: End-To-End-Encryption with DTLS is possible by using SNI inspection on the Client Hello packet. You either do that and advertise this as a secure service OR you say "this is unreliable unencrypted transport, do your own thing over it".
I just don't think you are explaining your value proposition properly.
Comments
I understand the concern. It can be a great convenience to not run the servers yourself, as people have been doing for decades with respect to websites, apps and APIs. That's essentially the same model, with the host terminating HTTPS for you.
All networks are lossy, and all transports. The difference between UDP and TCP based transports is who decides how to handle it. With UDP the application developer decides; with TCP (and QUIC) the protocol decides. More and more projects are taking-on the reliability decision, for a lot of reasons that trace back to this difference.
Essentially; and that's how everything starts. We've been in production since early last year and have maintained >99.99% availability. We're a certified partner with AWS, and have "qualified software" (it passed their security review), and our security posture report is available from AWS Marketplace. We aren't SOC-2 audited yet because we want to do it right rather than pay for a rubber-stamp report, and that takes time and a lot of money.
I know it is a marketing thing, but I simply dislike someone offering a server calling it serverless.
That being said: OK, so basically your service is to be treated as an Internet overlay. That can be fine. But then you should point the advantages of that. Using anycast and your internal peerings, are you better at routing packets than BGP on the open Internet? Are you able to hole-punch NAT to connect two NATted endpoints?
If so, this would be a service I might want to use.
As others have pointed out: End-To-End-Encryption with DTLS is possible by using SNI inspection on the Client Hello packet. You either do that and advertise this as a secure service OR you say "this is unreliable unencrypted transport, do your own thing over it".
I just don't think you are explaining your value proposition properly.