I think just the typical evaluation of someone with expertise in doing something, it's easy if you're a real devops kind, then just put together a bunch of things, do some config files, write a make or two, take two or three hours to do something that the rest of use take a week to do. in the same way that I might set up a service to scrape XML files and fill up my ElasticSearch search instance, and take a couple hours to set up a working service that I can keep expanding and other people might be like - easy, is that a joke?
"Easy" is probably because it boils down to, install X, Y, Z, edit config for X, Y, Z, start daemons X, Y, Z. There's no complex math or thinking involved, just plugging stuff in.
It takes practice. I just started making smoothies in a blender, and there are a bunch of little things to know to make it a little easier on yourself. It’s not just “throw all your shit in a blender and push button”, at least not with the cheap blender I have access to.
which is exactly my point? He calls it easy because he can do that in a couple hours, and if problems arise later he can always just fix them with a quick 10-20 minutes. It's easy.
On a side note this is actually a problem, in my experience, if I find something easy I might not cover every edge case - I can cover those if and when they come up - but given enough potential inputs and users the edge cases always come up. And then what happens if I am unavailable at that moment, the edge cases need to be handled by people who will find the easy solution I built up incredibly hard and daunting.
As someone running something similar, I thought it was quite easy when I first set it up: I used the similar setup of a friend as a baseline to get through the configuration. It took about 1 hour to setup the base things to have the infrastructure running.
I have been running my own personal servers in a similar setup for the last 10 years.
Have turned on automatic updates, including automatic reboot, and everything runs in docker (using docker-compose).
I can not remember a single time something bad or unexpected happened. Only the planned things - upgrading the distro every couple of years, and updating major versions of the things running in containers probably once a year or two. And maybe sometimes some unplanned updates if particularly bad vulnerability gets disclosed in a popular software/library. I am pretty sure I don't spend more than a few days per year to manage it.
If I had opted for a cloud vendor managed alternative, it would have been so much more expensive. I have definitely saved thousands or tens of thousands over the last 10 years.
But then again, I know how to manage it and I planned it out so it would not cause too much trouble for me. Prior to this setup I endured many painful moments and that "wasted time" allowed me to think of a better way to manage it and avoid certain problems along the way. Also available tooling has improved a lot.
Then again - this is for my personal projects and I would do it somewhat differently for large projects.
> I always hear about the easy setups, but never about total (man-hours included) cost of ownership through a couple release cycles on each component.
I run about half a dozen web apps on a single node on Hetzner with Docker swarm mode + traefik ingress + whatever the web apps need.
Any app I have is deployed in seconds as a docker stack. I treat my Docker swarm node as cattle, and I have an Ansible script to be used in case of emergencies that deploys everything from scratch. The Ansible script takes, from start to finish, only a couple of minutes to get everything up and running. I can do this with zero downtime as I have an elastic IP I can point at any node at will.
If I wanted, I could optimize everything even further, but it's already quite fast. In fact, I can get a new deployment on my Hetzner setup up and running faster than I can get an EC2 instance available in AWS.
Proponents of big cloud providers as the only viable option typically have absolutely no idea what they are talking about regarding availability, redundancy, and disaster recovery. It's mostly resume-driven development seasoned with a dash of "you don't get fired for picking IBM".
Easy in comparison to make everything yourself and configure every little service. This needs understanding of service and how they work and it needs much time.
After 20 years doing this, my postet example is stupid simple, that works for 80% auf all equirements.
For the rest 20% you need a good admin, or book a service with a good admin.
It’s super easy. Like literally would take someone who’s worked in infra an evening to set this all up and then a Sunday morning to have it automated in Ansible.
It’s a single server running a few containers with config files. The complexity comes when you outgrow a single machine or need stronger availability guarantees but none of that matters for a single-ish user setup.