8 ms·

It's not about using what the cool kids use these days. I can't stress enough that unmaintained software should not run in production. This way you have a good

It's not about using what the cool kids use these days. I can't stress enough that unmaintained software should not run in production. This way you have a good argument towards management and if you do it regularly or even plan it in ahead of time it's usually not much work. During a product planning meeting: "Dear manager, for the next weeks/sprint the team needs X days to upgrade the software to version x.x.x otherwise it will stop working"

jasonkester 8y ago
I guess we have different philosophies then. My take is that software in production should not require maintenance to remain in production. Imagine a world where you didn't need to spend a whole week every year, per project, just keeping your existing software alive. Imagine not having to put off development of the stuff you want to build to accommodate technical debt introduced by 3rd parties. That's the reality in Windows-land, at least. And I seem to remember it being like that in the past on the Unix side too.
- isostatic 8y ago
  Security wise you should of course be taking patches, however those patches should not be breaking functionality.
- patrec 8y ago
  Your vision is only workable for software for which there are no security concerns. This might improve to the extent industry slowly moves away from utterly irresponsible technologies like memory-unsafe languages and brain damaged parsing and templating approaches and more or less the whole web stack. I wouldn't hold my breath though. And even software that's not cavalierly insecure will have security flaws, albeit at a lower rate.
  - dalf 8y ago
    What if the new node version fix an bug / issue / CVE that doesn't concern the software ? Is it resonable to postpone the upgrade for later ? Example : the software uses python requests. A new version fixes CVE-2018-18074 about Authorization header, but you don't use this header, for sure. Is it resonable to upgrade a little bit later ?
    - viraptor 8y ago
      Depends on how mature is your security team/process. Can you spend time tracking separate announced bugs and make case by case decision for each cve? How much would you trust that review? Do you review dependencies which may trigger the same issue? Or is it going to take less time/effort to upgrade each time? Or is the code so trivial you can immediately make the decision to skip that patch? There's no perfect answer - you have to decide what's reasonable for your teams.
    - nerdbeere 8y ago
      The cool thing about serverless infrastructure is that it does not really concern you. As long as you are on a maintained version of the underlying platform your provider will take care of the updates. If your software runs on a unmaintained platform there won't be any security fixes and that's why amazon forces you to upgrade at some point.
      - ldoughty 8y ago
        AWS, at least, didn't make any promises for updates for serverless Lambda that I can see in their docs.
        nerdbeere 8y ago
        Right, because it's not relevant to you. You don't care about the underlying infrastructure in terms of security, amazon does that for you.
  - jasonkester 8y ago
    Keep in mind that you're arguing against an existence disproof. The Microsoft stack, for example, is a pretty big target for attack, and has seen its share of security issues over the years. But developers don't need to make any code changes or redeploy anything to mitigate those security issues. It all happens through patches on the server, 99% of which happen automatically via windows update.
    - nostrebored 8y ago
      ... because it is maintained?
      - TomMarius 8y ago
        There are no changes needed on application code side.
        nostrebored 8y ago
        What definition of maintained are you using? If they're doing security patches and bug fixes it's a maintained codebase.
        jasonkester 8y ago
        We're using the definition a few notches upthread: "Dear manager, for the next weeks/sprint the team needs X days to upgrade the software to version x.x.x otherwise it will stop working" As opposed to: 2011: deploy website, turn on windows update 2011-2019: lead life as normal 2019: website is up and running, serving webpages, and not part of a botnet. That's reality today, and if it helps to refer to it as "maintained", that's fine. The point is that it's preferable to the alternative.
        nostrebored 8y ago
        I think that the parent commenter is referencing node 4.3 being past EOL and being unmaintained software and therefore unfit for prod, unlike the ms stack which is receiving patches
- geggam 8y ago
  BSD still loves you long time
- pnutjam 8y ago
  Your describing traditional sysadmin vs devops. Devops means repeating the stress points so that they are no longer stressful and automated as much as possible. I like it way better then the classic, "don't touch this, it's working and the last guy that knew how to fix it is gone.
- PavlovsCat 8y ago
  That also describes my (very small in scope) PHP and Javascript things. They all still work, and I love that to bits. Admittedly, the price of that probably is keeping it simple, but if I needed to update it all the time just to keep it from not sinking under its own weight or the ground shifting beneath it, that would be no fun for me.
- balabaster 8y ago
  Imagine a world where new exploits and hacks didn't come along every day and compromise the systems your app sits on because you didn't keep up with patches and upgrades...
- minor3rd 8y ago
  You are looking to save yourself a week of time a year and then 3 years later for some reason or another you will HAVE to upgrade and good luck making that change when the world has moved past you.
- bl4ckm0r3 8y ago
  you don't need maintenance to remain in production, you need maintenance to reduce the tech debt in the infrastructure you decided to use (code, frameworks, third party libraries, security issues). Even just vanilla languages get upgraded every X months/years etc. Not maintaining the code is just a bad gift you are giving to your (or someone's) future. I have been in upgrades from perfectly working software written in an older (almost 4) version of java that was needed to add new features and it took a hell of a time and I have never seen it working at the end. I don't think it's a safe choice to "let it be" when it comes to software.
Phrozyn 8y ago
I completely agree with this, starting a new position and coming into infra running 5 year old software is not fun, generally neglected, and full of deprecated features/code that is improved in later versions. Not to mention the security risk running old software can often create.

jasonkester 8y ago

I guess we have different philosophies then. My take is that software in production should not require maintenance to remain in production. Imagine a world where you didn't need to spend a whole week every year, per project, just keeping your existing software alive. Imagine not having to put off development of the stuff you want to build to accommodate technical debt introduced by 3rd parties. That's the reality in Windows-land, at least. And I seem to remember it being like that in the past on the Unix side too.

isostatic 8y ago
Security wise you should of course be taking patches, however those patches should not be breaking functionality.
patrec 8y ago
Your vision is only workable for software for which there are no security concerns. This might improve to the extent industry slowly moves away from utterly irresponsible technologies like memory-unsafe languages and brain damaged parsing and templating approaches and more or less the whole web stack. I wouldn't hold my breath though. And even software that's not cavalierly insecure will have security flaws, albeit at a lower rate.
- dalf 8y ago
  What if the new node version fix an bug / issue / CVE that doesn't concern the software ? Is it resonable to postpone the upgrade for later ? Example : the software uses python requests. A new version fixes CVE-2018-18074 about Authorization header, but you don't use this header, for sure. Is it resonable to upgrade a little bit later ?
  - viraptor 8y ago
    Depends on how mature is your security team/process. Can you spend time tracking separate announced bugs and make case by case decision for each cve? How much would you trust that review? Do you review dependencies which may trigger the same issue? Or is it going to take less time/effort to upgrade each time? Or is the code so trivial you can immediately make the decision to skip that patch? There's no perfect answer - you have to decide what's reasonable for your teams.
  - nerdbeere 8y ago
    The cool thing about serverless infrastructure is that it does not really concern you. As long as you are on a maintained version of the underlying platform your provider will take care of the updates. If your software runs on a unmaintained platform there won't be any security fixes and that's why amazon forces you to upgrade at some point.
    - ldoughty 8y ago
      AWS, at least, didn't make any promises for updates for serverless Lambda that I can see in their docs.
      - nerdbeere 8y ago
        Right, because it's not relevant to you. You don't care about the underlying infrastructure in terms of security, amazon does that for you.
- jasonkester 8y ago
  Keep in mind that you're arguing against an existence disproof. The Microsoft stack, for example, is a pretty big target for attack, and has seen its share of security issues over the years. But developers don't need to make any code changes or redeploy anything to mitigate those security issues. It all happens through patches on the server, 99% of which happen automatically via windows update.
  - nostrebored 8y ago
    ... because it is maintained?
    - TomMarius 8y ago
      There are no changes needed on application code side.
      - nostrebored 8y ago
        What definition of maintained are you using? If they're doing security patches and bug fixes it's a maintained codebase.
        jasonkester 8y ago
        We're using the definition a few notches upthread: "Dear manager, for the next weeks/sprint the team needs X days to upgrade the software to version x.x.x otherwise it will stop working" As opposed to: 2011: deploy website, turn on windows update 2011-2019: lead life as normal 2019: website is up and running, serving webpages, and not part of a botnet. That's reality today, and if it helps to refer to it as "maintained", that's fine. The point is that it's preferable to the alternative.
        nostrebored 8y ago
        I think that the parent commenter is referencing node 4.3 being past EOL and being unmaintained software and therefore unfit for prod, unlike the ms stack which is receiving patches
geggam 8y ago
BSD still loves you long time
pnutjam 8y ago
Your describing traditional sysadmin vs devops. Devops means repeating the stress points so that they are no longer stressful and automated as much as possible. I like it way better then the classic, "don't touch this, it's working and the last guy that knew how to fix it is gone.
PavlovsCat 8y ago
That also describes my (very small in scope) PHP and Javascript things. They all still work, and I love that to bits. Admittedly, the price of that probably is keeping it simple, but if I needed to update it all the time just to keep it from not sinking under its own weight or the ground shifting beneath it, that would be no fun for me.
balabaster 8y ago
Imagine a world where new exploits and hacks didn't come along every day and compromise the systems your app sits on because you didn't keep up with patches and upgrades...
minor3rd 8y ago
You are looking to save yourself a week of time a year and then 3 years later for some reason or another you will HAVE to upgrade and good luck making that change when the world has moved past you.
bl4ckm0r3 8y ago
you don't need maintenance to remain in production, you need maintenance to reduce the tech debt in the infrastructure you decided to use (code, frameworks, third party libraries, security issues). Even just vanilla languages get upgraded every X months/years etc. Not maintaining the code is just a bad gift you are giving to your (or someone's) future. I have been in upgrades from perfectly working software written in an older (almost 4) version of java that was needed to add new features and it took a hell of a time and I have never seen it working at the end. I don't think it's a safe choice to "let it be" when it comes to software.

Phrozyn 8y ago

I completely agree with this, starting a new position and coming into infra running 5 year old software is not fun, generally neglected, and full of deprecated features/code that is improved in later versions. Not to mention the security risk running old software can often create.