5 ms·

I deployed by ssh-ing into a server and running git pull. That sounds wonderful. Let's do that again.

gjulianm 4y ago
There's a reason most deployments moved away from that: - Sometimes you need more complex actions to update a service than just "update the code". Migration scripts, dependent services restarts... - It's fine on one server, but the more you have the more difficult it gets - Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. - Too easy to say "let me just modify this thing here in production" and end up with bug fixes that are only applied on certain machines and certain versions... I get the "let's do things in a simple way again" sentiment, but it's not like the complexity is there because people like complexity.
- feoren 4y ago
  > Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help, if not a good old-fashioned kick out the door. That is not a technology problem, it's a human problem -- and a major one.
  - gjulianm 4y ago
    The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.
    - LAC-Tech 4y ago
- marcosdumay 4y ago
  > Sometimes you need more complex actions to update a service than just "update the code". Yes, software that was updated with a `git pull` always had an script or executable that gets the environment up to date with the new version. > It's fine on one server, but the more you have the more difficult it gets Nope, it's easy on as many servers as you want. It's just a matter of running `ssh $x (cd dir && git pull && dir/update_environment)` on a for loop. There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. > Too easy to say "let me just modify this thing here in production" Well, that's a "don't". > Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. And that is the one reason why this was abandoned almost everywhere, as soon as it became possible.
  - gjulianm 4y ago
    > always had an script or executable that gets the environment up to date with the new version. Which means you’re writing deployment tools already. Going from there to an abstraction that provides the primitives you use in those scripts is a natural step. > There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. Indeed. But again, this shows how deployment tools evolve naturally from “git pull” to something more complex. It’s not complexity for the sake of it. > Well, that's a "don't". If only managing computers was as easy as telling people what not to do.
Jtsummers 4y ago
That's how my present office does things (more or less, not git but same idea), making every box a pet that only a small number of experts can keep running. Good for the experts, bad for the customers, and turning bad for us as a project because it's pissing off the people paying to keep the lights on.
ge96 4y ago
I am curious at what scale do you justify using containers. I was just messing around in AWS making a cluster left it over night (few days), I had a $10 bill. Which is fine but yeah, in contrast my person apps/sites have been running on a $5/mo VPS. Anyway it's still cool to know/eventually use this somewhere but I'm concerned how you keep it fresh if you don't personally use it. edit: I left it on longer than that (90+hrs) but yeah, other one was EC2 NAT gateway hours
- maccard 4y ago
  I start with containers, even if we're deploying single binaries. Local repo of the prod environment is incredibly useful when you inevitably need it. GitHub actions/Gitlab CI build containers out of the box, and deploy to ecs/kubernetes/digitalocean/whatever straight out of the box. I can set up a CD pipeline on a fresh project to AWS with github actions in about 15 minutes that I will never need to touch again until the app grows to a scale that I can't develop and run it as one person. For anything other than a literal toy project the payback period is roughly the length of time it takes me to make a coffee while I wait for an ec2 instance or fargate cluster.
  - ge96 4y ago
    What's your bill like? Or I guess it depends on each person's interest in the cost but yeah. Maybe it doesn't have to be expensive if you do it from a "raw" way.
    - maccard 4y ago
      "it depends", but mostly I don't care, it's a rounding error compared to developer time. Digitalocean lets you deploy containers onto app service so you could do it for $5/month there. On AWS you can do it for about $15. > Maybe it doesn't have to be expensive if you do it from a "raw" way. If you look at straight $$$ cost sure, but the moment you take any development time into consideration you want to build on abstractions. Sure I could run docker on ec2 on a t2 micro behind the free tier, but if it takes me half a day to set up and I make $50k/year, it will take almost a year of it being free to pay off the cost of running it in fargate. _This_ is where AWS saves you money, not on buying compute from ec2.

There's a reason most deployments moved away from that: - Sometimes you need more complex actions to update a service than just "update the code". Migration scripts, dependent services restarts... - It's fine on one server, but the more you have the more difficult it gets - Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. - Too easy to say "let me just modify this thing here in production" and end up with bug fixes that are only applied on certain machines and certain versions... I get the "let's do things in a simple way again" sentiment, but it's not like the complexity is there because people like complexity.

feoren 4y ago
> Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help, if not a good old-fashioned kick out the door. That is not a technology problem, it's a human problem -- and a major one.
- gjulianm 4y ago
  The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.
  - LAC-Tech 4y ago
marcosdumay 4y ago
> Sometimes you need more complex actions to update a service than just "update the code". Yes, software that was updated with a `git pull` always had an script or executable that gets the environment up to date with the new version. > It's fine on one server, but the more you have the more difficult it gets Nope, it's easy on as many servers as you want. It's just a matter of running `ssh $x (cd dir && git pull && dir/update_environment)` on a for loop. There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. > Too easy to say "let me just modify this thing here in production" Well, that's a "don't". > Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. And that is the one reason why this was abandoned almost everywhere, as soon as it became possible.
- gjulianm 4y ago
  > always had an script or executable that gets the environment up to date with the new version. Which means you’re writing deployment tools already. Going from there to an abstraction that provides the primitives you use in those scripts is a natural step. > There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. Indeed. But again, this shows how deployment tools evolve naturally from “git pull” to something more complex. It’s not complexity for the sake of it. > Well, that's a "don't". If only managing computers was as easy as telling people what not to do.

Jtsummers 4y ago

That's how my present office does things (more or less, not git but same idea), making every box a pet that only a small number of experts can keep running. Good for the experts, bad for the customers, and turning bad for us as a project because it's pissing off the people paying to keep the lights on.

ge96 4y ago

I am curious at what scale do you justify using containers. I was just messing around in AWS making a cluster left it over night (few days), I had a $10 bill. Which is fine but yeah, in contrast my person apps/sites have been running on a $5/mo VPS. Anyway it's still cool to know/eventually use this somewhere but I'm concerned how you keep it fresh if you don't personally use it. edit: I left it on longer than that (90+hrs) but yeah, other one was EC2 NAT gateway hours

maccard 4y ago
I start with containers, even if we're deploying single binaries. Local repo of the prod environment is incredibly useful when you inevitably need it. GitHub actions/Gitlab CI build containers out of the box, and deploy to ecs/kubernetes/digitalocean/whatever straight out of the box. I can set up a CD pipeline on a fresh project to AWS with github actions in about 15 minutes that I will never need to touch again until the app grows to a scale that I can't develop and run it as one person. For anything other than a literal toy project the payback period is roughly the length of time it takes me to make a coffee while I wait for an ec2 instance or fargate cluster.
- ge96 4y ago
  What's your bill like? Or I guess it depends on each person's interest in the cost but yeah. Maybe it doesn't have to be expensive if you do it from a "raw" way.
  - maccard 4y ago
    "it depends", but mostly I don't care, it's a rounding error compared to developer time. Digitalocean lets you deploy containers onto app service so you could do it for $5/month there. On AWS you can do it for about $15. > Maybe it doesn't have to be expensive if you do it from a "raw" way. If you look at straight $$$ cost sure, but the moment you take any development time into consideration you want to build on abstractions. Sure I could run docker on ec2 on a t2 micro behind the free tier, but if it takes me half a day to set up and I make $50k/year, it will take almost a year of it being free to pay off the cost of running it in fargate. _This_ is where AWS saves you money, not on buying compute from ec2.