[jameshart]

Great, now you have an nginx reverse proxy as a load balancer in front of a few servers. Now sort out log storage, certificate expiry, access controls, patch management, health monitoring, and remote administration, update it whenever you add or remove backend servers for maintenance, and make sure to synch it up to DNS, and you’ve almost got the same capability as an AWS ELB. Except yours doesn’t have high availability or horizontal autoscaling.

Getting all of that stuff right actually kind of gets close to rocket science. Which can be worth doing… but just be aware that Amazon will happily sell you a rocket kit.

[cntainer]

I'm not an "on-premise bare-metal server absolutist". Of course there are trade offs in terms of convenience but there are also trade offs in terms of cost and performance and vendor lock-in. It all depends on what you need and what are your specific constraints.

Is time to market critical? Will you have daily traffic fluctuation between 10 to 10k users? Will you lose a ton of money/customers for any service interruption? By all means use the latest version of managed kubernetes combined with whatever other cloud service tickles those itches. But don't forget to always keep an eye on your bills and think how can you reduce them by simplifying your architecture.

But if you're just building a corporate intranet for a few dozen users who log in once a week I'm pretty sure a simple VM (even if managed in AWS) would make much more sense.

And if you really want to roll your own there are plenty of options to make your life much easier compared to sending a rocket into outer-space. Yes it's more work upfront but after you do the setup the first time there's little to do.

infra automation & templates: - ansible, docker, etc

log storage: - mount shared storage - ELK - use a paid LaaS or monitoring SaaS

certificate management (on LB machine only): - certbot

access controls: - linux user and groups management

patch management: - enable unattanded upgrades for security patches

health monitoring: - in terms of lb nginx has that built in. - for more advanced use cases use a paid service (new relic) or a free one (nagios)

remote administration: - ansible, etc.

Don't get me wrong I use cloud on a daily basis for work, I'm just sad because most teams don't know how to use it effectively without jumping the gun.

[mike_hearn]

> log storage, certificate expiry, access controls, patch management, health monitoring, and remote administration, etc

This is how you can satisfy those needs with stock Linux. Install Ubuntu then:

    apt-get install certbot unattended-upgrades systemd-journal-remote
    wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh && sh /tmp/netdata-kickstart.sh

Remote admin and access controls are already handled via SSH and ordinary UNIX permissions. DNS editing is easy, just use your registrars UI for it.

Oddly, the most painful part is uploading servers and making them properly start up, be backed up etc. You can use Docker but I've written a tool that does it without that, just using systemd and Debian packages. You can run it on Mac/Windows too and it'll build a package for your server, upload it, install it, start it up etc to a list of servers defined in the config. You can sandbox the server with an additional line of code, define cron jobs with a few others etc. It's a bit more direct than Docker, and gives you the traditional stuff like OS managed security updates (for the libraries the OS provides).

> Except yours doesn’t have high availability or horizontal autoscaling

HA: Some people have extremely distorted ideas of how reliable server-class hardware and datacenters can be. There was someone on Reddit commenting on the 37signals cloud exit who believed that normal datacenters have 99% availability! Actual figure for most well run commercial DCs: closer to five nines. Some datacenter providers like Delft (as used by 37signals) promise 100% availability and give SLA credits for literally any downtime at all, which they can do because they have so little.

Auto-scaling: this is often a requirement that comes from the high cost of cloud services. If you only need 9 servers you don't need to auto-scale, you can just buy the servers and leave them running 24/7. Yeah, there are definitely places for that like companies that need to occasionally run huge batch jobs where the cloud model of multi-tenant sharing makes total sense, but for a website like Stack Overflow it's just not needed. Remember that their hardware runs at low utilization despite not having any caching layer; they can absorb huge spikes in traffic without issue assuming they're provisioned with sufficient bandwidth.

> Getting all of that stuff right actually kind of gets close to rocket science ... Amazon will happily sell you a rocket kit

This makes me feel kinda old, but I can't grow a beard let alone a gray one :( It's a type of sysadmin skill that was once considered entry level and which could be readily found in any university IT department. Probably still can be. Yes, if you grew up with AWS writing nodejs apps on a MacBook, if you never installed Linux into a VM and played with it, then it may seem scary. But it's not really so bad. You should try it some time, it's a generic skill that can come in handy.

[OkayPhysicist]

To add on to the HA comment: A lot of people have distorted ideas of how much availability they actually need. A lot, if not most, applications could probably get away with the absolutely abysmal 99% uptime, depending on how that downtime was distributed. 99% uptime could mean anything from ~3 days of downtime a year, 7 hours a month, 14 minutes a day, to half a second of unavailability a minute.

Like sure, it's not ideal, but real businesses almost never are. And, as you pointed out, most datacenters get dramatically better uptime than that.