3 ms·

I work in a different domain (full stack development), but I think the principle here applies broadly. I tend to favor tools that have been around for a long t

I work in a different domain (full stack development), but I think the principle here applies broadly. I tend to favor tools that have been around for a long time. A lot of the sites I have built have deployment scripts written in bash with dependencies on apt packages and repos, git to pull application code, and rsync to copy over files. It would probably be okay to update to zsh at this point. ;) I'm constantly shocked by the complexity of deployment infrastructures when I get into new projects: I've spent plenty of time working with Docker and Kubernetes and I have yet to see a case where these simplified things. As a rule, I don't throw out existing infrastructure, but if I'm doing greenfield development I never introduce containers--they simply don't do anything that can't be done more explicitly in a few lines of Bash. One of the sites I still maintain has been running for 15 years. I ported it from Fedora (not my choice) to Debian about 8 years ago, and the only thing that changed in the deployment scripts was the package manager. I switched to DigitalOcean 5 years ago and the deployment script didn't change, period. The deployment script is 81 lines of bash. git blame shows 64 of those lines are from the original commit of the file. The changes are primarily to add new packages and to change the firewall to UFW. And critically: I didn't write this script. This was written by a guy before me who just happened to have a similar deploy philosophy to me. That's a much better maintainability story than having to hire someone with your specific deploy tools on their resume.

tazu 2y ago
For infrastructure, I try to keep the Lindy effect [1] in mind. [1]: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
- deleted 2y ago
  [deleted]
- kerkeslager 2y ago
  Exactly! Thanks, I didn't know there was a name for that.
banku_brougham 2y ago
This is a compelling testimonial. Someone recently posted a 'git ops' package here that was equally simple and bash based. Im interested to try, but im wondering what the rationale will be for avoiding github actions. If you could share script or snippets I would be grateful. One difficulty for me is my datastore and reporo g package is a python application using Prefect, and I manage dependency with Poetry. The 'poetry install' phase isnt always ha ds off and my script fails.
- ambicapter 2y ago
  > but im wondering what the rationale will be for avoiding github actions. Having used them, I would say lack of test-ability and slightly unhelpful flow-control rules would be my guess. The former you'll find in any managed CI solution.
- kerkeslager 2y ago
  > Im interested to try, but im wondering what the rationale will be for avoiding github actions. I don't. Github actions are simple enough, and easily run the scripts I'm talking about. > If you could share script or snippets I would be grateful. Maybe I'll pull something together and post it if I get the chance this week. > One difficulty for me is my datastore and reporo g package is a python application using Prefect, and I manage dependency with Poetry. > The 'poetry install' phase isnt always ha ds off and my script fails. I don't use poetry, I use pypi directly with pip, so not sure I can help you there. That sounds like a problem to debug. But notably, it's probably easier to debug than similar problems with a containerized system (which happen).
itsoktocry 2y ago
>I tend to favor tools that have been around for a long time If there are no early adopters, then no tools will ever make it to the "been around for a long time" stage. Someone has to use it.
- kerkeslager 2y ago
  My clients don't pay me to do community service. And frankly, in the vast majority of cases, someone doesn't have to use it, because we simply don't need new solutions to already-solved problems. The proliferation of new solutions made by people who don't understand the existing solutions is a barrier to progress, not a driver of progress. There is a shortage of people willing to do the boring work of iterative improvement to existing tools, not a shortage of people willing to try out the latest exciting new tool. If a tool solves a problem that hasn't already been solved, then there isn't any "tool that has been around for a long time" to prefer. You use the new tool in that case because you don't have a choice. And yes, sometimes there do emerge new solutions that solve the same problems better, but that's actually extremely rare, because if there were an easy, obvious way to do it better, the original tool's developers would have done that. And then it has to be better enough to justify changing everything else that has been built around the existing solutions. This is why, incidentally, I generally support making rare breaking changes to existing tools: the cost of switching to a completely new tool is greater than the cost of making breaking changes to an existing tool.

tazu 2y ago

For infrastructure, I try to keep the Lindy effect [1] in mind. [1]: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect

deleted 2y ago
[deleted]
kerkeslager 2y ago
Exactly! Thanks, I didn't know there was a name for that.

banku_brougham 2y ago

This is a compelling testimonial. Someone recently posted a 'git ops' package here that was equally simple and bash based. Im interested to try, but im wondering what the rationale will be for avoiding github actions. If you could share script or snippets I would be grateful. One difficulty for me is my datastore and reporo g package is a python application using Prefect, and I manage dependency with Poetry. The 'poetry install' phase isnt always ha ds off and my script fails.

ambicapter 2y ago
> but im wondering what the rationale will be for avoiding github actions. Having used them, I would say lack of test-ability and slightly unhelpful flow-control rules would be my guess. The former you'll find in any managed CI solution.
kerkeslager 2y ago
> Im interested to try, but im wondering what the rationale will be for avoiding github actions. I don't. Github actions are simple enough, and easily run the scripts I'm talking about. > If you could share script or snippets I would be grateful. Maybe I'll pull something together and post it if I get the chance this week. > One difficulty for me is my datastore and reporo g package is a python application using Prefect, and I manage dependency with Poetry. > The 'poetry install' phase isnt always ha ds off and my script fails. I don't use poetry, I use pypi directly with pip, so not sure I can help you there. That sounds like a problem to debug. But notably, it's probably easier to debug than similar problems with a containerized system (which happen).

itsoktocry 2y ago

>I tend to favor tools that have been around for a long time If there are no early adopters, then no tools will ever make it to the "been around for a long time" stage. Someone has to use it.

kerkeslager 2y ago
My clients don't pay me to do community service. And frankly, in the vast majority of cases, someone doesn't have to use it, because we simply don't need new solutions to already-solved problems. The proliferation of new solutions made by people who don't understand the existing solutions is a barrier to progress, not a driver of progress. There is a shortage of people willing to do the boring work of iterative improvement to existing tools, not a shortage of people willing to try out the latest exciting new tool. If a tool solves a problem that hasn't already been solved, then there isn't any "tool that has been around for a long time" to prefer. You use the new tool in that case because you don't have a choice. And yes, sometimes there do emerge new solutions that solve the same problems better, but that's actually extremely rare, because if there were an easy, obvious way to do it better, the original tool's developers would have done that. And then it has to be better enough to justify changing everything else that has been built around the existing solutions. This is why, incidentally, I generally support making rare breaking changes to existing tools: the cost of switching to a completely new tool is greater than the cost of making breaking changes to an existing tool.