3 ms·

I love services like this, but I am super weary to adopt them, particularly after Now v1's deprecation. It's kind of difficult to run a stable production applic

I love services like this, but I am super weary to adopt them, particularly after Now v1's deprecation. It's kind of difficult to run a stable production application when your Platform-as-a-Service provider announced major breaking changes-- aka killing docker, and forcing me to rewrite my application in serverless lambdas (which doesn't work for all use cases, like web sockets). It killed the category in my mind, it isn't even your fault. I now feel far more comfortable running on bread-and-butter tools, like AWS/GCP/Azure with Kubernetes. The overhead sucks, but at least I can plan for things better than I can when hosting with fast-moving PaaS providers. Hosting is too important of a problem to wholly outsource entirely to a PaaS platform if it's subject to shuffling at a rate I can't control (exception: personal projects with no real availability expectations). That's the double edged sword with platforms like these. They let you get your application online rapidly, but you could be subject to unforeseen technical debt at the hosting provider's will. I learned (the hard way) that I'm not a fan on managing risk under those terms.

vincelt 8y ago
In this case I particularly don't want to go the serverless road. My motivation behind Backery is that all the new shiny cool platforms aka Now and Netlify are focused and going all-in on serverless when my apps are not. At first the slogan was "monolithic web app deployment". If anything Docker support is coming :) Still your point is very valid and I guess only time can tell!
revskill 8y ago
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.
pier25 8y ago
There is always some risk when you depend on others. Zeit's deprecation of Docker was not great, but not all PaaS are like this. Heroku, Google App Engine, and others have remained "stable" for years.

vincelt 8y ago

In this case I particularly don't want to go the serverless road. My motivation behind Backery is that all the new shiny cool platforms aka Now and Netlify are focused and going all-in on serverless when my apps are not. At first the slogan was "monolithic web app deployment". If anything Docker support is coming :) Still your point is very valid and I guess only time can tell!

revskill 8y ago

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.

pier25 8y ago

There is always some risk when you depend on others. Zeit's deprecation of Docker was not great, but not all PaaS are like this. Heroku, Google App Engine, and others have remained "stable" for years.