4 ms·

What's happening here that an Layer 7 Load Balancer, Multiple Serverless Functions, and a Websocket can't handle? AWS released exactly that during the last re:

• chii 8y ago
  You're basically locking yourself in with a particular vendor if you choose to use that tech (rather than a standard stack deployable anywhere with compute power).
  • bartread 8y ago
    Going beyond the vendor lock-in, one of the biggest initial draws of serverless - from speaking with friends - has been simplicity in situations where state isn't a concern. On the other hand, here we're discussing a bunch of hoop jumping to get stateful functionality that might more easily achieved by adding a library such as SignalR, or socket.io into your app. Whilst this is probably a few screens to set up via the AWS, and can obviously be automated, you add complexity to development and delivery. Critically you also make it harder to diagnose and fix problems. Like anything it's a trade-off: for some apps these issues won't matter so much, for others they will. For us, it would definitely be a problem.
    • redisman 8y ago
      Serverless is a tool with good use cases where your tradeoff-win will be great scalability. It's not that great for general use (yet) IMHO. You can create a "session" in redis pretty easily if you're willing to add another database as a requirement. That way you can share state. It's also very new so the ecosystem will keep maturing and enabling more use-cases.