> Hetzner servers
It is truly amazing to me the value that is provided by renting hardware instead of VPSes. As long as you're willing to roll your own infrastructure instead of buy into a cloud provider's infrastructure.
It is truly amazing to me the value that is provided by renting hardware instead of VPSes. As long as you're willing to roll your own infrastructure instead of buy into a cloud provider's infrastructure.
However, most people do not - some will learn, but most will fall for the cloud marketing depts and become infra renters for life. Teach a man to fish, and so on.
It was actually painful to see start ups spending thousands a month on hosting, that could be easily achieved as you say under 100 pcm plus. They would have to get a contractor to set it up and for support, but it would have worked out much cheaper and they could have bumped the salaries of their workers.
Why is that?
You see the same thing in the corporate world for in-house stuff. Your manager (and your manager's manager) don't want to hear about in-house or self-hosted things that AWS can provide.
This is totally understandable. It's a repeat of the whole "nobody ever got fired for buying IBM" mantra of computing's early decades.
It also totally sucks.
Do you have any learning recommendations for someone looking to start down this path? I've only ever worked in an infra-renter context, and I've begun exploring the 'rent from Hetzner, manage your own infra' for personal projects, but I would love to learn from the paths of experts where possible.
Ideally, you also have some exposure to this at $job as simply building DIY infra horrors without seeing the real-world context, tradeoffs, etc. in which they typically operate will be misleading.
1. a DNS monitoring with failover (DNSMadeeasy has a decent solution)
2. a Haproxy setup with health checks for switching to a working upstream service
3. a distributed filesystem
4. a master-slave replication with monitoring (something like Mariadb + orchestrator service)
and nightly backups for all this. Database and FS are latency sensitive so they shouldn't be too far apart.
So, yeah, it's good that you asked, because it's not as widely known as the people that use it think it is.
I use a $6/mo box for my primary business hosting, but I have a $3/mo one that I'm using to build v2, really just to prove what's possible. If you set up your DB and caching right you can do so much with so little...
Yeah - I remember a StackOverflow talk[1] where they basically said that they just vertically scale their database.
The fact that they were able to make it work tells me that most businesses should probably just go that route and avoid the headache of distributed systems[2].
---
1. https://www.infoq.com/presentations/stack-exchange/
2. Obviously a business should probably invest in redundancy when it comes to data (as did StackOverflow), but a pure "Raid 1" setup is the easiest of distributed systems to understand.
You get a lot of bang for your buck out of them.
In the end, was an interesting learing experience, that I hope to not have to repeat. Only went for a single server as I had several smaller VPSes on DigitalOcean and wanted to add a mail server in the mix, and couldn't reliably send via DO or Linode, so was easier to consolidate and run on a single/larger host for hobby projects.
In the end self hosting and self managing is a money / time trade off, especially for a side gig I’d us SAS and managed solutions. The one thing one has to make sure off is to not get locked in with a particular provider, so knowing how to do everything yourself is a very valuable skill.
I was there when someone at AWS accidentally unplugged an entire region.
Shit happens, it doesn't matter where it's hosted. People act like the cloud is infallible or something. You're literally sending lightning bolts worth of electricity through bricks of metal. Anything can happen.
Uh huh. This is why DevOps/SRE roles pay more than development roles.
“Step 2: draw the rest of the owl”
There's no reason someone should have to run a service like Chatwoot themselves, the software is so good that it's mostly set & forget for most small use cases.
That's where I come in. Unfortunately I don't have ChatWoot yet, but I have (and use) Umami for page view tracking extensively on my own projects now, with Nimbus[1]. The dogfood tastes decent so far.
The first thing I want to do is add a backup mechanism that isn't just take a snapshot -- There are a bunch of similar tools to Umami and I don't think that any of them have a really good cross-project way of taking backups.
Feels like there should be a page view/analytics backup standard, so you can easy move from a tool like Plausible or Umami and try out a new one, like Fugu.
But outside of advanced functionality I think my platform is just a lot closer on cost. The instance costs don't go up per traffic served (especially since 99% of people won't need that) -- it's more like parts + maintenance (and since Umami is good software it doesn't need a TON of maintenance either, just regular patches and some monitoring/extremely light resilience engineering).