← Back to context

Comment by jwr

13 hours ago

This is all correct. I've been running my own servers for many years now, keeping things simple and saving a lot of money and time (setting anything up in AWS or Azure is horribly complicated and the UIs are terrible).

One thing to remember is that you do need to treat your servers as "cloud servers" in the sense that you should be able to re-generate your entire setup from your configuration at any time, given a bunch of IPs with freshly-installed base OSs. That means ansible or something similar.

If you insist on using cloud (virtual) servers, do yourself a favor and use DigitalOcean, it is simple and direct and will let you keep your sanity. I use DO as a third-tier disaster recovery scenario, with terraform for bringing up the cluster and the same ansible setup for setting everything up.

I am amused by the section about not making friends saying this :-) — most developer communities tend to develop a herd mentality, where something is either all the rage, or is "dead", and people are afraid to use their brains to experiment and make rational decisions.

Me, I'm rather happy that my competitors fight with AWS/Azure access rights management systems, pay a lot of money for hosting and network bandwith, and then waste time on Kubernetes because it's all the rage. I'll stick to my boring JVM-hosted Clojure monolith, deployed via ansible to a cluster of physical servers and live well off the revenue from my business.

I was a guy that built server clusters during the early 00's, for my own and others' web and other projects. When AWS really took off, it was like a spend all your money mania, and devs and companies treated my skills like dirt. I got a job writing facial recognition edge servers, with high performance many claim are impossible numbers (25M face compares per second per core) and my employer found itself a leader in the industry. But customers could not wrap their heads around just a single box capable of our numbers (800M face compares per second, plus ingestion of 32 video streams) and to get sales the company ended up moving everything into AWS because customers did not trust anything else.

  • > to get sales the company ended up moving everything into AWS because customers did not trust anything else

    This is a hidden cost of self-hosting for many in b2b. It's not just convincing management, it's convincing your clients.

    • That's interesting. Except for $GIGANTIC_CO (like, BofA, or the government), i'd expect a SLA that describes service resiliency and not "well, our service will be up because we're on AWS".

      Why would you need to disclose your hosting provider? is that really a concern for hosted services (and if it is, why isn't the customer hosting it in their cloud?)

      1 reply →

Pre-cloud pets vs cattle approach. We ran a few pets, but had DC's worth of cattle thanks to PXE, TFPT and Ansible. No Terraform required, as there was no need to control the state of multiples of cloud cruft. Good times. Except when something would pack up in the middle of winter in the wee hours and it was a bollock-cracking motorbike ride to the DC to spit on the offending black box.

Have you written about your app and revenue anywhere we can read about it? Looks interesting.

This is all true. But... But if you manage your own server, as the author advice, you need to figure out a lot of stuff and remember about a lot of stuff.

Are ulimits set correctly?

Shall I turn on syn cookies or turn them off because of performance?

What are the things I should know but I don't and Chat GPT has not told me them, as this is more than some intro tutorial on how to run VPS on DO, so it was never indexed by Chat GPT and alikes.

Is all of my software on the server up to date? Is there any library I use exploited, zero day attacks are on me too, blocking bots, etc. What if I do some update but it will turn out that my Postgres version is not working correctly anymore? This is all my problem.

What if I need to send emails? These days doing this ourselves is a dark art by itself (IP/domain address warming up, checking if my domain has not ended on some spam list, etc.).

What if I need to follow some regulations, like European Union GDPR compliance? Have I done everything what is needed to store personal data as GDPR requires? Is my DB password stored in a compliant way or I will face a fine up to 10% of my incomes.

This is not black/white situation as the author tries to present and those who use cloud services are not dumbards who are buying some IT version of snake oil.

  • Setting up the email server is the only thing I couldn't do with my own home hosted setup because you're at the mercy of your internet provider to give you the PTR record in their network, and lately many providers outright refuse to do it for "your own and their own safety" reasons. This thing alone could be the difference between deciding to host yourself or use a cloud service.

  • >What if I need to send emails? These days doing this ourselves is a dark art by itself (IP/domain address warming up, checking if my domain has not ended on some spam list, etc.).

    AFAIK, everyone sending automated emails just uses one of the paid services, like sendmail.

    >What if I need to follow some regulations, like European Union GDPR compliance? Have I done everything what is needed to store personal data as GDPR requires? Is my DB password stored in a compliant way or I will face a fine up to 10% of my incomes.

    What does this have to do with cloud vs non-cloud? You'll need to manage your data correctly either way.

  • All of this is true both for dedicated servers and cloud-hosted VMs.

    This list looks like FUD, to be honest, trying to scare people. Yes, you should be scared of these things, but none of them are magically solved by hosting your stuff in AWS/Azure/Google or any other could provider du jour.

    • Some of them are solved by using managed-services that abstract away the messy config / security ops stuff.

      The blog entry was wordy and repetitive for what it expressed (AI?), but the cloud argument should boil down to a few simple questions:

         - Does it get you regulatory certifications you need?
         - Do you need to rapidly scale-up / scale-down?
         - Can you afford to hire the (minimal) necessary skills to self-administer servers?
         - Can you stay on top of security updates?
      

      Add all that together and you get a few customers who should be using the cloud:

         - Regulated companies who want to punt on certs/attestations
         - Small/medium growth-oriented startups (unknown needs, low headcount, focus on building product)
         - Companies with hardware demand volatility that exceeds their ability to provision it
      

      That's not "all companies" or "no companies" either way, but it is a very large number of companies who are paying cloud premiums without actually needing or benefiting from the cloud value add...

  • Yes, you will need to employ someone with basic system administration competence. That's a given.

    Cloud infra is touted as obviating the need to hire system administrators, but that's a marketing fabrication. Trying to manage infrastructure without the necessary in-house skills is a recipe for disaster, whether it's in the cloud or on-prem.