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 remember having same problem with Linux, tried to compensate with Monit but it never just worked quite right.
Systemd might add a bunch of unnecessary complexity in places, but for a sysadmin it's a fucking blessing. Just write one simple file, set binary, user, done, add some limitations and dependencies if you want to be fancy, set auto restart to true and It Just Works.
Can even set some memory limits if you want to be fancy so any memory leak won't get you into too much trouble but just gets the service restarted
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.
At $DAYJOB, we used to have a few internal use Azure Functions (which we’ve migrated to AWS Lambda). My favourite Azure weirdness was a warning message that said some Blob Storage-related thing was about to expire. We hadn’t set up any Blob Storage, the Azure Functions .NET deployment thing we used did. And apparently, there was an encryption key or something with an expiry of 1 year. It seems that Microsoft did not expect code to just work and not need to be redeployed for that long.
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?
I'm using CNPG on my rinky-dinky 3-node k8s homelab, and it's been pretty good. I had a situation where my object storage ran out of space (again: homelab) which caused backpressure on db log backups; which stopped the pg databases. It correctly recovered automatically once I cleared up the root cause without much intervention on the CNPG side.
We're constantly striving to improve the user experience and the quality of StackGres. Would you mind sharing some feedback as to what made your experience not good with it?
Did you join the Slack Community (https://slack.stackgres.io/) to ask if you were facing some trouble? It always helps, even if it is just by sharing your troubles.
(If you'd like to share feedback and do so privately, please DM on the Slack Community)
in my experience, Azure functions are best used by .NET executables and powershell scripts. GCP functions are what I recommend for anyone entering serverless (from limited experience of course).
I would not upload software directly to servers and change the configuration files to make it work. I rather use containers so I can be sure it will run on different servers with ease.
This coincides with my experience. At first, Azure (AWS, ...) were simple enough to get started in no time. Later, the service creation "wizards" started becoming progressively bloated, getting full of vendor-specific details I could not care less, but was required to pay attention to in order to get a minimally running service.
Needless to say that those details weren't rewarding at all. Knowing them just served the ego of specific vendors, who were more than happy to pull a rug under your feet with deprecations, migrations, and "required actions" I had to manually follow in order to keep the services just running.
Enough is enough. One sunny day in 2021, I started to migrate the infrastructure using a garage inspired approach. Dockerfile became a breath of fresh air, a relieve after the years of convoluted dictatorships. No more dependencies on ever-changing whims of individual cloud vendors, no rug pulls. Just you, your services, and freedom.
I had no prerogative of keeping my servers near me, instead I found a good home at fly.io. I still use Azure, this time not as a swiss-knife almighty cloud, but as an interchangeable commodity supplier (storage).
11 comments
[ 2.1 ms ] story [ 39.1 ms ] threadI 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
Systemd might add a bunch of unnecessary complexity in places, but for a sysadmin it's a fucking blessing. Just write one simple file, set binary, user, done, add some limitations and dependencies if you want to be fancy, set auto restart to true and It Just Works.
Can even set some memory limits if you want to be fancy so any memory leak won't get you into too much trouble but just gets the service restarted
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.
I'm now thinking something like Supabase or Convex may be the way to go for personal projects. Any experiences?
We're constantly striving to improve the user experience and the quality of StackGres. Would you mind sharing some feedback as to what made your experience not good with it?
Did you join the Slack Community (https://slack.stackgres.io/) to ask if you were facing some trouble? It always helps, even if it is just by sharing your troubles.
(If you'd like to share feedback and do so privately, please DM on the Slack Community)
Your feedback will be much appreciated.
[edit]: typo
I never worked at Amazon but understand they give you generally open ended access for learning/testing?
Surely there plenty of business value in getting someone like the author to ensure Rust applications run smoothly with all their products.
Needless to say that those details weren't rewarding at all. Knowing them just served the ego of specific vendors, who were more than happy to pull a rug under your feet with deprecations, migrations, and "required actions" I had to manually follow in order to keep the services just running.
Enough is enough. One sunny day in 2021, I started to migrate the infrastructure using a garage inspired approach. Dockerfile became a breath of fresh air, a relieve after the years of convoluted dictatorships. No more dependencies on ever-changing whims of individual cloud vendors, no rug pulls. Just you, your services, and freedom.
I had no prerogative of keeping my servers near me, instead I found a good home at fly.io. I still use Azure, this time not as a swiss-knife almighty cloud, but as an interchangeable commodity supplier (storage).