4 ms·

Not quite. If your application architecture is flexible enough, in this case, if you could split endpoints into serverless endpoints, i believe you could combin

Not quite. If your application architecture is flexible enough, in this case, if you could split endpoints into serverless endpoints, i believe you could combine them later to adapt other providers. For websocket, you can move it to another "not-serverless" hosting as well. Splitting then combine is far more easier than combine then splitting.

JMTQp8lwXL 8y ago
Yeah, but then you have to ditch Now for your websockets, and you significantly increase the complexity of your deployment by having your serverless code on Now and your containers on Kubernetes. At that point, I'd rather just go fully in on Kubernetes and keep the benefits of containers, rather than using two cloud providers.
- jkarneges 8y ago
  You could host your WebSockets with something like Fanout (disclosure: founder), using Now as the backend. Still two providers, but only one to deploy code to, which may be more palatable.
  - JMTQp8lwXL 8y ago
    I'd be curious to see if there's a simple integration of something like Fanout with FeathersJS.
    - jkarneges 8y ago
      I'm not sure if FeathersJS integrates with any services, but its on our roadmap to explore how to provide Fanout integrations for web frameworks like this. Feathers supports plain WebSocket (and SockJS) via the Primus transport, so that'd probably be the way in. Currently we're starting out by looking at feasibility with Apollo. If we can manage to get that to work, then hopefully we can move on to other frameworks.
- yjftsjthsd-h 8y ago
  Honestly, there's a time to ask, "could I run this on a single server LAMP stack?" If it matches what you're doing, it'll work for years-decades with a little care and feeding. Can be self-hosted, or if you host elsewhere is a common denominator of service.
  - JMTQp8lwXL 8y ago
    That might require a little bit more security knowledge than I practically have, with respect to securing servers in cloud environments. That was one of the appeals of PaaS platforms, to me. At least with Kubernetes, you're based on things like Container OS, which to my knowledge are secure out of the box (zero config). Me, setting that up from scratch on a single VPS, that might get hacked if I mess it up, and then my customer's availably is compromised? I wouldn't want to be in that situation.
leesalminen 8y ago
I’ve been using Pusher as a websocket provider for several years now and have never experienced any breaking changes. I’m sure it’s cheaper to host my own, but meh, yet another stack to maintain.
- JMTQp8lwXL 8y ago
  Pusher is a bit more focused than what Now offered with its Serverless docker. You could containerize anything. So if you were putting MySQL or Redis in a container, and your main application depended upon that -- you were up a creek without a paddle. Pusher does Websockets. It can only be so opinionated, since it's a fairly focused, well-defined problem: Websockets. I'ts less likely to be subject to breaking changes versus Now. I'd say they have both roughly the same chance of randomly shutting down, with only a few months notice.

JMTQp8lwXL 8y ago

Yeah, but then you have to ditch Now for your websockets, and you significantly increase the complexity of your deployment by having your serverless code on Now and your containers on Kubernetes. At that point, I'd rather just go fully in on Kubernetes and keep the benefits of containers, rather than using two cloud providers.

jkarneges 8y ago
You could host your WebSockets with something like Fanout (disclosure: founder), using Now as the backend. Still two providers, but only one to deploy code to, which may be more palatable.
- JMTQp8lwXL 8y ago
  I'd be curious to see if there's a simple integration of something like Fanout with FeathersJS.
  - jkarneges 8y ago
    I'm not sure if FeathersJS integrates with any services, but its on our roadmap to explore how to provide Fanout integrations for web frameworks like this. Feathers supports plain WebSocket (and SockJS) via the Primus transport, so that'd probably be the way in. Currently we're starting out by looking at feasibility with Apollo. If we can manage to get that to work, then hopefully we can move on to other frameworks.
yjftsjthsd-h 8y ago
Honestly, there's a time to ask, "could I run this on a single server LAMP stack?" If it matches what you're doing, it'll work for years-decades with a little care and feeding. Can be self-hosted, or if you host elsewhere is a common denominator of service.
- JMTQp8lwXL 8y ago
  That might require a little bit more security knowledge than I practically have, with respect to securing servers in cloud environments. That was one of the appeals of PaaS platforms, to me. At least with Kubernetes, you're based on things like Container OS, which to my knowledge are secure out of the box (zero config). Me, setting that up from scratch on a single VPS, that might get hacked if I mess it up, and then my customer's availably is compromised? I wouldn't want to be in that situation.

leesalminen 8y ago

I’ve been using Pusher as a websocket provider for several years now and have never experienced any breaking changes. I’m sure it’s cheaper to host my own, but meh, yet another stack to maintain.

JMTQp8lwXL 8y ago
Pusher is a bit more focused than what Now offered with its Serverless docker. You could containerize anything. So if you were putting MySQL or Redis in a container, and your main application depended upon that -- you were up a creek without a paddle. Pusher does Websockets. It can only be so opinionated, since it's a fairly focused, well-defined problem: Websockets. I'ts less likely to be subject to breaking changes versus Now. I'd say they have both roughly the same chance of randomly shutting down, with only a few months notice.