3 ms·

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 t

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.

mlhpdx 20d ago
> so basically your service is to be treated as an Internet overlay I don’t understand how that could be the takeaway. The service is just what it says on the homepage: a way to make datagram transports compatible with event driven architecture and serverless. I don’t think the word “overlay” appears anywhere. I get your point, but thats not at all the positioning. The SDLC and operations are what it’s about. > End-Encryption with DTLS is possible by using SNI inspection on the Client Hello Sure. In simple cases even that’s not necessary if a listener is tied to a single endpoint, right? But again, this service probably isn’t ideal for such cases — it would work, but I, for one, don’t see why it would be useful.