I have a personal project and I used a tiny Azure 'dev/test' postgres database like OP mentioned and it went down for a day with no explanation. Restoring from back ups did not work. Now Auzre have a new DB service in preview called Horizon which I'd hope is more reliable.
Before that I used stackgres on kubernetes which was awful. I hear the cloud native pg operator is okay though?
Another problem I had was Bitnami yanking some helm charts and images I had used for a Redis cluster.
I'm now thinking something like Supabase or Convex may be the way to go for personal projects. Any experiences?
One thing that strikes me about the author's experience is how unusable Azure appears to be in all this. Like, this hits somewhat close to me as I also run a couple web projects, also written in Rust, on a serverless architecture, and frankly couldn't imagine wanting to spend the time to run them any other way. AWS Lambda for compute, and Dynamo for DB, have a perpetual free tier and it's been running practically without me touching it for years.
The AWS Rust SDK also seemed very mature to me when I was using it ... compare to:
>the only option for a database instance with a free plan was [...] serverless Microsoft SQL Server (MSSQL)
>the MSSQL connection required TLS and this hadn’t been implemented in the sqlx connector I chose to use for my Rust-based functions. I wasted two weeks implementing TLS support in sqlx
That is insane. Not to mention the later bit with sudden, unexplained availability and the only hint that it might to be related to a _future_ deprecation? Like, imagine if this were a critical service for you. Professional malpractice on Microsoft's part.
This isn't really the main point of the article, and I did find the stuff on self-hosting interesting, but it does seem like this could have been avoided if Azure had lived up to its peers.
There's not enough information to come to a conclusion as to what the 503s originated from. There is enough information for manufactured outrage, of course.
I don't see why one would want to run in-the-clear over the Azure network for SQL connections.
The author was doing hobby projects. Granted, hobby projects should run on any platform, but Azure seems to have less of that free tier you can get elsewhere.
Nice move and nice write-up! There has been so much propaganda around serverless, so we need to hear more of these voices.
I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky. You seem to have figured out a good solution, but I wanted something simpler like PM2 for automatic process management/restarting/logs. Unfortunately PM2 has an issue [1] that makes it unworkable with FreeBSD. It would be so nice if FreeBSD had a smooth, more declarative way of managing processes.
> I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky.
It indeed is tricky. To be honest, I wasn't "put off" by it because I've been using BSDs and old-style Linux startup systems for almost 30 years now... but the lack of abstraction shows, and I don't think it's great.
The daemon(8) wrapper is neat to integrate pre-existing servers into rc.d, but I do not fancy having to deal with that "by hand" nor to create a shell script to manage my own service (related from a few years ago: https://jmmv.dev/2020/08/rcd-libexec-etc.html) nor to have something entirely separate to manage log rotation.
As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model. BUT, as I mentioned in this article, I also like the "no churn" of the BSDs because what I learned and refined over ~30 years is still similar to this day and that I won't be bitten by surprises.
> As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model.
I've been playing with dinit for a bit now; it combines a lot of the nice advantages of systemd with a finite scope and being portable across OSs.
Even with daemon(8), PID files and the lack of process supervision might be my least favorite aspect of FreeBSD, an OS I like overall. Not long ago, I wanted to avoid running a custom service that way on a fresh FreeBSD server. After researching my options, I found an adequate solution in the daemontools family. I'd heard of daemontools but hadn't paid much attention to it.
My service has been managed by runit and, most recently, nitro (https://github.com/leahneukirchen/nitro). Both have run as the service's user. They supervise the process and handle logging. I have found the design of daemontools and its derivatives runit and nitro elegant; it lives up to the reputation.
Not GP, but I do prefer the very direct control you get with rcctl (OpenBSD), openrc (Alpine),... Systemd often feels like autoconf. It's needed when you really want the capabilities, otherwise the opaqueness and complexity feels very much cumbersome when you're dealing with a simple service.
I do like the Unix way of having different components handling different tasks instead of having different things which are entangled with each other. It encourages transparency.
I have a personal project and I used a tiny Azure 'dev/test' postgres database like OP mentioned and it went down for a day with no explanation. Restoring from back ups did not work. Now Auzre have a new DB service in preview called Horizon which I'd hope is more reliable. Before that I used stackgres on kubernetes which was awful. I hear the cloud native pg operator is okay though? Another problem I had was Bitnami yanking some helm charts and images I had used for a Redis cluster.
I'm now thinking something like Supabase or Convex may be the way to go for personal projects. Any experiences?
One thing that strikes me about the author's experience is how unusable Azure appears to be in all this. Like, this hits somewhat close to me as I also run a couple web projects, also written in Rust, on a serverless architecture, and frankly couldn't imagine wanting to spend the time to run them any other way. AWS Lambda for compute, and Dynamo for DB, have a perpetual free tier and it's been running practically without me touching it for years.
The AWS Rust SDK also seemed very mature to me when I was using it ... compare to:
>the only option for a database instance with a free plan was [...] serverless Microsoft SQL Server (MSSQL)
>the MSSQL connection required TLS and this hadn’t been implemented in the sqlx connector I chose to use for my Rust-based functions. I wasted two weeks implementing TLS support in sqlx
That is insane. Not to mention the later bit with sudden, unexplained availability and the only hint that it might to be related to a _future_ deprecation? Like, imagine if this were a critical service for you. Professional malpractice on Microsoft's part.
This isn't really the main point of the article, and I did find the stuff on self-hosting interesting, but it does seem like this could have been avoided if Azure had lived up to its peers.
There's not enough information to come to a conclusion as to what the 503s originated from. There is enough information for manufactured outrage, of course.
I don't see why one would want to run in-the-clear over the Azure network for SQL connections.
The author was doing hobby projects. Granted, hobby projects should run on any platform, but Azure seems to have less of that free tier you can get elsewhere.
Oh for sure you want to use TLS, what's insane is the developer experience of needing to implement it yourself.
Nice move and nice write-up! There has been so much propaganda around serverless, so we need to hear more of these voices.
I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky. You seem to have figured out a good solution, but I wanted something simpler like PM2 for automatic process management/restarting/logs. Unfortunately PM2 has an issue [1] that makes it unworkable with FreeBSD. It would be so nice if FreeBSD had a smooth, more declarative way of managing processes.
1. https://github.com/Unitech/pm2/issues/5718
Thanks!
> I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky.
It indeed is tricky. To be honest, I wasn't "put off" by it because I've been using BSDs and old-style Linux startup systems for almost 30 years now... but the lack of abstraction shows, and I don't think it's great.
The daemon(8) wrapper is neat to integrate pre-existing servers into rc.d, but I do not fancy having to deal with that "by hand" nor to create a shell script to manage my own service (related from a few years ago: https://jmmv.dev/2020/08/rcd-libexec-etc.html) nor to have something entirely separate to manage log rotation.
As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model. BUT, as I mentioned in this article, I also like the "no churn" of the BSDs because what I learned and refined over ~30 years is still similar to this day and that I won't be bitten by surprises.
> As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model.
I've been playing with dinit for a bit now; it combines a lot of the nice advantages of systemd with a finite scope and being portable across OSs.
Even with daemon(8), PID files and the lack of process supervision might be my least favorite aspect of FreeBSD, an OS I like overall. Not long ago, I wanted to avoid running a custom service that way on a fresh FreeBSD server. After researching my options, I found an adequate solution in the daemontools family. I'd heard of daemontools but hadn't paid much attention to it.
My service has been managed by runit and, most recently, nitro (https://github.com/leahneukirchen/nitro). Both have run as the service's user. They supervise the process and handle logging. I have found the design of daemontools and its derivatives runit and nitro elegant; it lives up to the reputation.
Not GP, but I do prefer the very direct control you get with rcctl (OpenBSD), openrc (Alpine),... Systemd often feels like autoconf. It's needed when you really want the capabilities, otherwise the opaqueness and complexity feels very much cumbersome when you're dealing with a simple service.
I do like the Unix way of having different components handling different tasks instead of having different things which are entangled with each other. It encourages transparency.