2 ms·

Yes. Our contract is that a unit of deployment is a .tar.gz file, and inside that there is an executable file bin/run which starts the app. We build apps in a

by twic 5y ago

Yes. Our contract is that a unit of deployment is a .tar.gz file, and inside that there is an executable file bin/run which starts the app. We build apps in a few languages, but they all have a start script like that. You can use static or dynamic linking, compiled or interpreted languages, anything you like, as long as the start script sets it up correctly. For Go apps the script can be trivial. Tarballs must be self-contained - binaries, libraries, config files, static assets. We make an exception for interpreters, because those are huge and change slowly. Those are manually installed in /opt/something. I'd like it if we did something more disciplined and reproducible, but it's good enough for now. We don't have many machines. Maybe 20? You can get a lot done with 20 full-size physical machines. I don't see how something like Docker would help us here. It would just be the same, but less hackable.

fimbulvetr 5y ago
This sounds like neophobia or NIH syndrome. What you're doing is almost exactly the same as a docker deployment, except you're missing the ability to have some declarative leverage and tagging (unless your place invented that for themselves as well). There very few unhackable things about a Docker/container image, and typically that's for the better. The other advantage is that once you start using docker images, you now have more or less portable infrastructure. EKS, ECS, Google Cloud Run, Heroku, and on and on and on... But then again, it takes some time to realize that serverless is an advantage because if you're still young or your company isn't strapped for cash, they're fine hiring people to stay on call through the night and manage servers and upgrades and so on. Me? My fargate tasks run on servers that never need reboots or upgrades.

2 ms·

Yes. Our contract is that a unit of deployment is a .tar.gz file, and inside that there is an executable file bin/run which starts the app. We build apps in a

by twic 5y ago

fimbulvetr 5y ago
This sounds like neophobia or NIH syndrome. What you're doing is almost exactly the same as a docker deployment, except you're missing the ability to have some declarative leverage and tagging (unless your place invented that for themselves as well). There very few unhackable things about a Docker/container image, and typically that's for the better. The other advantage is that once you start using docker images, you now have more or less portable infrastructure. EKS, ECS, Google Cloud Run, Heroku, and on and on and on... But then again, it takes some time to realize that serverless is an advantage because if you're still young or your company isn't strapped for cash, they're fine hiring people to stay on call through the night and manage servers and upgrades and so on. Me? My fargate tasks run on servers that never need reboots or upgrades.