Comment by LVB

Comment by LVB 12 hours ago

14 replies

This looks good, and I’m a target user in this space.

One thing I’ve noticed is the prevalence of Docker for this type of tool, or the larger self-managed PaaS tools. I totally get it, and it makes sense. I’m just slow to adapt. I’ve been so used to Go binary deployments for so long. But I also don’t really like tweaking Caddyfiles and futzing with systemd unit files, even though the pattern is familiar to me now. Been waffling on this for quite a while…

kokanee 11 hours ago

I'm a waffler on this as well, increasingly leaning away from containers lately. I can recall one time in my pre-Docker career when I was affected by a bug related to the fact that software developed on Mac OS ran differently than software running on CentOS in production. But I have spent untold countless hours trying to figure out various Docker-related quirks.

If you legitimately need to run your software on multiple OSes in production, by all means, containerize it. But in 15 years I have never had a need to do that. I have a rock solid bash script that deploys and daemonizes an executable on a linux box, takes like 2 seconds to run, and saves me hours and hours of Dockery.

  • bantunes 11 hours ago

    I don't understand how running a single command to start either a single container or a stack of them with compose, that then gets all the requirements in a tarball similar and just runs is seen as more complicated than running random binaries, setting values on php.ini, setting up mysql or postgres, demonizing said binaries and making sure libraries and the like are in order.

    • hiAndrewQuinn 9 hours ago

      You're going to be setting all that stuff up either way, though. It'll either be in a Dockerfile, or in a Vagrantfile (or an Ansible playbook, or a shell script, ...). But past a certain point you can't really get away from all that.

      So I think it comes down to personal preference. This is going to sound a bit silly, but to me, running things in VMs feels like living in an apartment. Containers feel more like living out of a hotel room.

      I know how to maintain an apartment, more or less. I've been living in them my whole life. I know what kinds of things I generally should and should not mess with. I'm not averse to hotels by any means, but if I'm going to spend a lot of time in a place, I will pick the apartment, where I can put all of my cumulative apartment-dwelling hours to good use.

      • kokanee 8 hours ago

        Yes, thank you for answering on my behalf. To underscore this, the decision is whether to set up all of your dependencies and configurations with a tool like bash, or to set it all up within Docker, which involves setting up Docker itself, which sometimes involves setting up (and paying for) things like registries and orchestration tools.

        I might tweak the apartment metaphor because I think it's generous to imply that, like a hotel, Docker does everything for you. Maybe Dockerless development is like living in an apartment and working on a boat, while using Docker is like living and working on a houseboat.

        There is one thing I definitely prefer Docker for, and that's running images that were created by someone else, when little to no configuration is required. For example, running Postgres locally can be nicer with Docker than without, especially if you need multiple Postgres versions. I use this workflow for proofs of concepts, trials, and the like.

    • bluehatbrit 11 hours ago

      I suppose like anything, it's a preference based on where the majority of your experience is, and what you're using it for. If you're running things you've written and it's all done the same way, docker probably is just an extra step.

      I personally run a bunch of software I've written, as well as open source things. So for me docker makes everything significantly easier, and saves me installing a lot of rubbish I don't understand well.

      • oarsinsync 10 hours ago

        After 20 years of various things breaking on my (admittedly franken) debian installs after each dist-upgrade, and spending days troubleshooting each time, I recently took the plunge and switched all services to docker-compose.

        I then booted into a new fresh clean debian environment, mounted my disks, and:

          cd /opt/docker/configs; for i in *; do cd $i; docker-compose up -d; cd ..; done
        
        voila, everything was up and working, and no longer tied to my underlying OS. Now at least I can keep my distro and kernel etc all up to date without worrying about anything else breaking.

        Sure, I have a new set of problems, but they feel smaller.

      • stackskipton 10 hours ago

        Yea, in same boat and I'm wondering if there is big contingent of devs out there that bristle at Docker. Biggest issue I run into writing my lab software is finding decent enough container registry but now I just endorse free tier of Vultr CR.

faangguyindia 9 hours ago

Here's the thing, we've code running on VPS in cloud for a decade with any problem

When we ran it on kubernets, without touching it, it broke itself in 3 years.

Docker is fantastic developement tool, I do see real value in it.

But kubernets and whole ecosystem? You must apply updates or your stuff will break one day.

Currently I am using docker with docker compose and GCR, it does make things very simply and easy to develop and it's also self documenting.

mikkelam 10 hours ago

There are tools like firecracker that significantly reduces docker overhead https://firecracker-microvm.github.io/

I believe fly.io uses that. Not sure if OP’s tool does that

  • mightymoud 8 hours ago

    No Sidekick doesn't use firecracker. I know fly.io is built around it yes. They do that so they can put your app to sleep - basically shutting it down - then spin it up real quick when it gets a request. No place for this in Sidekick vision

  • indigodaddy 10 hours ago

    Was wondering the same— didn’t see any mention of it in the GH page though, nor even in roadmap