4 ms·

Personally I think it's pretty great that I can write Dockerfiles, run them locally, and call it the day because this is also what runs in production. So basic

by avip 5y ago

Personally I think it's pretty great that I can write Dockerfiles, run them locally, and call it the day because this is also what runs in production. So basically I have no clue what the dude is talking about - we have a great setup which is x10 better than what we had before. No?

quadrifoliate 5y ago
> Personally I think it's pretty great that I can write Dockerfiles, run them locally, and call it the day because this is also what runs in production. It goes far, far beyond Dockerfiles. Are you on-call for production? Can you debug a problem in production? If not, then that's the root of the problem that the dude is talking about. If these are true for you (not specifically you, any reader of this): - You don't have a good idea of how to ship a change all the way to production after committing it - You would not know how to debug and fix a failure of your code in production - Your "Dev" and "DevOps" teams are in separate departments ...then congratulations, you have just reinvented the old-school sysadmin/developer dichotomy from the 90s. You just happen to be using Dockerfiles instead of Makefiles.
- kazen44 5y ago
  Not to mention the layer that lives behind this. Can you troubleshoot network level issues that seem to occur between your system and someone else's? What about storage? Can you make sure your data is still their if your environment gets royally screwed. I know these are usually done by seperate companies nowadays, but getting an an actual computing environment up and running with redundancy in place (down to the cooling and electrical level) is no easy feat.
- smus 5y ago
  I'm glad there's a dichotomy. I (a dev) never signed up to be on call 24/7 for production and it's ridiculous to just assume that I should be. I have a life outside of my work. If the system needs 24/7 uptime, they better be paying someone other than me to ensure that's the case, because my time is too valuable to waste my already precious freetime on fixing bugs in prod.
  - xxpor 5y ago
    Who wrote those bugs in the first place?
    - smus 5y ago
      Good point, devs should either just not write bugs OR be on call 24/7. That's a totally reasonable way of running things. I understand if people's lives are on the line. Otherwise, recognize that bugs happen, and either be ok with that or come up with a process (QA) that finds these bugs before deployment or that allows you to roll back to a more stable version easily.
      - dijksterhuis 5y ago
        I'm not sure where you got this idea of people being 24/7 on call for production. That's not a thing in the real world. We use rotas. > come up with a process (QA) that finds these bugs before deployment or that allows you to roll back to a more stable version easily. Aha! This magical process that mitigates deployment risks is also known as CI/CD. Which, it turns out, is usually used quite a lot in DevOps teams as it means each team member can see their code move from development all the way to production and fix problems as they appear. (hint: understanding this process is the "being responsible for your code in production" part).
    - IanSanders 5y ago
      What's your point?
      - hcrean 5y ago
        His point is that Ops time is more expensive than Dev time, they get paid more. The Dev teams should really fix their own bugs if they happen in the wee-small-hours.
        xxpor 5y ago
        Not just that (since there's a lot of situations you may not be able to actually fix bugs in the moment, just work around them), but it also aligns incentives and enforces lessons learned. If you know you're gonna be on the other end of that pager, maybe that hack won't see the light of day. For more senior folks, pattern recognition around how things were built and what issues they led to are incredibly valuable. Being able to tell a junior engineer no don't do it like that, we did that last time and it led to x y and z, could save the company a ton of money and pain. If you're separated out from ops, what would ever drill that into you? Saying you're too busy for ops is just wild to me. That's some of the highest effort to reward work someone can do.
erulabs 5y ago
Agreed. Dockerfiles beat ansible scripts which in turn beat that-bash-script-that-PXE-ran. Skaffold and kubernetes are amazing tools, but just tools. So much easier to be cynical about new tools than to investigate and understand the pros and cons.

by avip 5y ago

quadrifoliate 5y ago

> Personally I think it's pretty great that I can write Dockerfiles, run them locally, and call it the day because this is also what runs in production. It goes far, far beyond Dockerfiles. Are you on-call for production? Can you debug a problem in production? If not, then that's the root of the problem that the dude is talking about. If these are true for you (not specifically you, any reader of this): - You don't have a good idea of how to ship a change all the way to production after committing it - You would not know how to debug and fix a failure of your code in production - Your "Dev" and "DevOps" teams are in separate departments ...then congratulations, you have just reinvented the old-school sysadmin/developer dichotomy from the 90s. You just happen to be using Dockerfiles instead of Makefiles.

kazen44 5y ago
Not to mention the layer that lives behind this. Can you troubleshoot network level issues that seem to occur between your system and someone else's? What about storage? Can you make sure your data is still their if your environment gets royally screwed. I know these are usually done by seperate companies nowadays, but getting an an actual computing environment up and running with redundancy in place (down to the cooling and electrical level) is no easy feat.
smus 5y ago
I'm glad there's a dichotomy. I (a dev) never signed up to be on call 24/7 for production and it's ridiculous to just assume that I should be. I have a life outside of my work. If the system needs 24/7 uptime, they better be paying someone other than me to ensure that's the case, because my time is too valuable to waste my already precious freetime on fixing bugs in prod.
- xxpor 5y ago
  Who wrote those bugs in the first place?
  - smus 5y ago
    Good point, devs should either just not write bugs OR be on call 24/7. That's a totally reasonable way of running things. I understand if people's lives are on the line. Otherwise, recognize that bugs happen, and either be ok with that or come up with a process (QA) that finds these bugs before deployment or that allows you to roll back to a more stable version easily.
    - dijksterhuis 5y ago
      I'm not sure where you got this idea of people being 24/7 on call for production. That's not a thing in the real world. We use rotas. > come up with a process (QA) that finds these bugs before deployment or that allows you to roll back to a more stable version easily. Aha! This magical process that mitigates deployment risks is also known as CI/CD. Which, it turns out, is usually used quite a lot in DevOps teams as it means each team member can see their code move from development all the way to production and fix problems as they appear. (hint: understanding this process is the "being responsible for your code in production" part).
  - IanSanders 5y ago
    What's your point?
    - hcrean 5y ago
      His point is that Ops time is more expensive than Dev time, they get paid more. The Dev teams should really fix their own bugs if they happen in the wee-small-hours.
      - xxpor 5y ago
        Not just that (since there's a lot of situations you may not be able to actually fix bugs in the moment, just work around them), but it also aligns incentives and enforces lessons learned. If you know you're gonna be on the other end of that pager, maybe that hack won't see the light of day. For more senior folks, pattern recognition around how things were built and what issues they led to are incredibly valuable. Being able to tell a junior engineer no don't do it like that, we did that last time and it led to x y and z, could save the company a ton of money and pain. If you're separated out from ops, what would ever drill that into you? Saying you're too busy for ops is just wild to me. That's some of the highest effort to reward work someone can do.

erulabs 5y ago

Agreed. Dockerfiles beat ansible scripts which in turn beat that-bash-script-that-PXE-ran. Skaffold and kubernetes are amazing tools, but just tools. So much easier to be cynical about new tools than to investigate and understand the pros and cons.