Comment by faangguyindia
16 hours ago
I've moved most companies away from using others stuff
Today we use Hertzner and OVH and roll out our own solution whenever possible.
Running lean and mean.
Depending on such third party services is a trap.
16 hours ago
I've moved most companies away from using others stuff
Today we use Hertzner and OVH and roll out our own solution whenever possible.
Running lean and mean.
Depending on such third party services is a trap.
Been there, done that, and I still find value in 3rd party services despite the occasional need to migrate.
Self hosting is the way to go if you need to keep monthly services spend as low as possible but you have extra time to spend, such as with a hobby project.
Whenever I’ve worked on real startup projects, self-hosting became a constant source of little tasks for the engineering team to mix into our weekly workload. There were always little tasks to upgrade this service, investigate why that one server was slow, or to migrate something to a bigger server because we were bottlenecked on some resource. Then we had to manage backups and do our recovery drills, along with changing the backup strategy every 6 months because someone had a better idea.
When we started to add up all of the time spent managing everything it starts to look like spending dollars (of engineer time) to save pennies on SaaS bills.
Probably not a popular thing to say on HN, but I now try to stay away from teams that go to extremes to self-host everything because I just want to get my work done, not also be constantly involved in running the underlying services. I do it for my own hobby projects at home but I don’t want to be doing it at work where we have money to spend to lighten the load. If the cost is the occasional migration to a different 3rd party service that’s not a big workload relative to everything involved in self-hosting.
>if you need to keep monthly services spend as low as possible but you have extra time to spend, such as with a hobby project.
We did not have any budget constraints at all.
Depending on 3rd party meant:
1. Begging for issues where project owner has marked them "won't fix"
2. Navigating hundreds of features we don't use, don't need and not having features we absolutely need but they don't have.
3. Weird gotchas and cost saving implemented by them, where we do not want to save any money.
>When we started to add up all of the time spent managing everything it starts to look like spending dollars (of engineer time) to save pennies on SaaS bills.
We actually factored all costs, our self hosted solution are "very lean" and still come out ahead when you factor in time/cost.
>spending dollars (of engineer time) to save pennies on SaaS bills.
I ran by this for long time fasely believing "engineers are way more expensive than cloud bills, so these thousands of dollars we are spending on these services don't matter"
but when we actually got down to fixing all , we realised now it costs us 1/10th of what it used to with more flexibility and reliability.
>Probably not a popular thing to say on HN, but I now try to stay away from teams that go to extremes to self-host everything because I just want to get my work done, not also be constantly involved in running the underlying services
we found exact opposite tbh, integrating into others hurt our performance, wasted our time, made us frustrated and desperate.
Only external service we use now are Anycast for serving our sub millisecond api and "billing", yes billing because it has lots of edge cases, taxes and all wicked things we can't manage on our own.
Still looking to rollout inhouse biller soon though.
... please keep doing backups and DR tests.
That is something of a broken promise in the SaaS world; it was supposed to be convenience but instead it became a hundred broken integration points as you struggle to keep up with deprecated APIs and acqui-hires killing off shims you wouldn't have needed if everything had been on-prem to begin with.
What software do you use to run your CI?
Not OP, but to me the answer is:
I then define the docker stack in the git repository, and CI builds the images and pushes to build the new image to the docker repository. The portainer API allows to deploy a stack, with the image tag as a parameter.
not op either, github actions, self hosted runner on bare metal with lxc containers for each runner.
Cost savings are insane and the speed of latest amd epycs are miles ahead of the default ci instances on github and other places.
Are your self-hosted runner on premise or are you using a cloud service for it?
This is the way.