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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
I'm definitely not your target audience, so take what I'm about to write with a grain of salt.
I didn't register, and only checked out your Landing Page and your linked Documentation...
The first issue i had was how you didn't mention healthchecks or log aggregation anywhere... how would a developer troubleshoot issues if they'd chose to go with your service? and do they need to use external monitoring to be notified about issues?
my next issue was with the database... how would developers do their database migrations? do they need to connect to their database directly and execute them from their workstation? If so, does that mean that the database is open to dog and world?
How would a developer set secrets and other runtime variables that cant be part of the repository? I couldn't find anything about that in the docs either.
Honestly, nothing about the product made me think PaaS. Its more like an offer to host a single threaded web application of some select languages... But i wish you luck!
The competition is fierce though, especially with Amazon pushing for serverless, Heroku and self hosted alternatives like Dokku around.
Congrats on shipping. Your pricing, very roughly, looks like about 1/2 that of Heroku.
One question: for the two lower cost plans with weekly backup: if there is a hardware failure and you need to restart all apps on a new server, how much time would this take? I am not asking for an estimate if the data center you use goes down, just asking about an estimate for spinning up apps on a new server.
I ask because I like to host small experiments. If apps are down occasionally for a half hour or an hour that is OK, but a few hours isn’t.
The time to spin a new server and set up the apps back on it is no more than a few minutes (depending if you had a DB and how large it is). You can see it in action when you scale an app up, it will spin a new server, import back the DB on it, build your app and switch DNS to the new location. Rarely takes more than 5 minutes.
I think tho if something happens at the hardware level and we lose our servers we would seriously consider switching providers.
Very cool, congrats on getting to this point. I have a few questions as a long time heroku user:
- Can you scale up to more app server instances?
- Where are your servers running? Based on location and the pricing progression, I'm guessing Scaleway?
- How are logs handled?
Thank you :)
- Not yet, but process scaling is coming very soon!
- Good catch! It's running in the Scaleway Amsterdam datacenter. Might expand to more regions/providers in the future
- Logs are pretty basic. In your dashboard, you can see the logs for the last build and the last ~ 50 lines of your application logs
I've used Scaleway for one thing where I needed lots of cores and latency didn't matter, but I'm not sure I'd use them for much more. Heard a bunch of questionable things about their networking too, how has your experience been so far?
I've had all my apps and projects on there for a few years without issues. I believe their Amsterdam datacenter has more bandwidth than the one in Paris so I switched everything there. I should do some proper tests and write a post comparing networking across datacenters.
Also, for the few times I needed support, it was quite responsive and helpful.
Maybe they don't have the most performant cores but it's suitable enough for majority of my usecases and very worth the price.
If you're interested: for now I've only monetized two projects beside Backery (Nucleus and Harmony). Nucleus is doing right now around $200 / month (growing) and Harmony around $150 monthly, slowing decreasing with time. I like building too much but should focus more on selling, even tho it feels a bit counterintuitive to me. An open dashboard is a good idea, I love these. Can definitely put one in place once I have some more steady revenues :)
I think I’m a target audience for something like this. I created a web app that uses Postgres and hosted it with elastic beanstalk. It was about $50/month so I took it down. $3/month is much more reasonable for my needs
Ah yeah! I used Caprover when it was still CaptainDuckDuck, it was awesome :)
- No, for now it's only application hosting. You should use an external service like S3 to store immutable files.
- Although filesystem is available it might reset on server upgrade / scaling / migration. That happens very rarely (safe for temp files) but general files should be stored somewhere like S3.
- For PostgreSQL backups, they are actually done with dumps (pg_dump) so it's not a base backup.
The lowest price is quite attractive to people who run an app on a $5 VPS (although there are some < $5 / vps out there). $5 VPS vs $3 PaaS, Kinda good market positioning!
Would be nice if you support Elixir (you don't have to, maybe it's not worth it since demand would not be high)
They are listed on the dashboard, you point and click, select the version you want and the database is ready and running. There is no requirement on your part to handle the installation.
Nope not managed. Only the Shared MongoDB database is managed. Does not provide continuous backups although planned only snapshot backups at the moment. We intend to offer a managed shared offering for the other databases as well but not a priority as MongoDB was and still is the most requested database.
No, the Heroku PG is a VPS instance running a DB except that it's totally managed for you.
A serverless DB is like Firebase or Fauna, where you pay by number of queries, storage, etc, and it scales up and down automatically much like cloud functions.
For me that would mean no limit on number of tables and rows assuming "low" usage, probably in terms of number of reads+writes over a certain period of time.
Same here, after Back& shut down their service with little warning which subsequently killed a mobile app of mine.
I wish the OP success in their efforts though. I think it looks like a great service, and believe there are potential customers out there who can accept the risk and deploy on this platform.
Yeah, one of my clients ran on OSS Parse for a while too but at the time of Parse.com shutting down OSS parse was not stable at all.
In the end we decided to rewrite the whole thing as a Java/Spring/Postgres monolith on Kubernetes. The rewrite took 3 months from decision to production and has been running fine for two years now. Initially on AWS and more recently the staging/dev environments have been moved to DigitalOcean in a couple of hours.
After the pending acquisition we’ll probably move the whole thing to Azure and I expect that to take a couple of days.
We switched our staging/dev environments to DO because of cost. A small Kubernetes cluster and hosted Postgres does not cost much there and is very easy to setup. But their hosted Kubernetes and Postgres services are still in “early access” so I’m holding off running production services on there for now.
The switch to Azure will likely happen post-acquisition to move everything into the infrastructure of the buyer.
It is single host. It requires still managing the host node you run it on. Dokku is nice and they did a good job mimicking the Heroku tool chain, but it is not even close to actually providing the value Heroku gives.
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.