8 ms·

It’s not just portability that’s an issue with lambda. It’s also churn. Running on Lambda, one day you’ll get an email saying that we’re deprecating node vers

It’s not just portability that’s an issue with lambda. It’s also churn. Running on Lambda, one day you’ll get an email saying that we’re deprecating node version x.x so be sure to upgrade your app by June 27th when we pull the plug. Now you have to pull the team back together and make a bunch of changes to an old, working, app just to meet some 3rd party’s arbitrary timeframe. If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days. That’s the issue I find myself up against more often when relying on Other People’s Infrastructure.

simonebrunozzi 8y ago
Good point, but no. If you have architected your apps properly, decommissioning or sunsetting services or individual components should already have been designed and planned. I know, I know... It's almost never the case.
- yeahitslikethat 8y ago
  You really just don't have to think like this on the msft stack. I'm so glad I chose msft ASP 20 years ago, instead of php, or RoR or python, or node or any of the myriad other stacks that have come and gone since.
  - jjuel 8y ago
    Do you ever need to update your servers to a newer version like say 2016 or now 2019? There are definitely issues on using say old VB6 libraries when you need to upgrade your severs from 2008 to 2019. Not to mention using those old technologies if you do have a new feature or change you end up with an unmaintainable mess. I am MSFT stack programmer, but to claim there are no issues and you just need to patch a server is flat out wrong.
benbristow 8y ago
That's just laziness on your part though. Using an old version of Node is just going to leave you with worse performance and potentially security holes.
- social_quotient 8y ago
  Given the nature of lambdas specifically -What would the security issue be on outdated lambda code? -Wouldn’t the performance of the code would be equal to the performance of when you first deployed.
Cthulhu_ 8y ago
Isn't that always the case though? I mean, outside of e.g. lambdas or other platforms / runtimes as a service? I mean a few years ago there was a huge security flaw in Apache Struts, whose impact was big because it had been used in a lot of older applications - meaning a LOT of people had to be summoned to work on old codebases to fix this issue. The problem isn't a changing runtime - even if you self-host it you should make sure to keep that updated regularly.
- jasonkester 8y ago
  if you self-host it you should make sure to keep that updated regularly. Mild disagreement: My philosophy is that you should choose technologies that aren't likely to introduce breaking changes in the future. As an example, I have sites that were built using ASP.NET version 1.1 that have survived to this day with nothing more than Windows Update on the server and the occasional version bump in the project config when adding a feature that needed the latest and greatest. Compare that to the poor soul who decided to build on top of React when it first came out, and has been rewarded by getting to rewrite his entire application four times in as many years. To return to the point, rather than rewriting around breaking changes from Node x.x to Node y.a, I'd be shopping around for the LTS version of Node x that I could keep the thing running on without intervention from my team.
  - mritun 8y ago
    > As an example, I have sites that were built using ASP.NET version 1.1 that have survived to this day with nothing more than Windows Update You are right; but in my experience those ASP applications also had security holes (CSRF etc) that were never patched. They ultimately either became botnets or faded away when the corp simply faded away. A business that can't afford to pay for cleaning up its business applications is likely to be unable to pay for general upkeep as well. It is simply past the point of being a viable business and is either in limbo or in the grave! See "maintenance free" approach to software as canary in the coal-mine and run away as fast as possible.
    - yeahitslikethat 8y ago
nerdbeere 8y ago
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 ?
aussieguy1234 8y ago
Not a problem. Ill tell TypeScript to output code matching the es version for that version of node.
- thecopy 8y ago
  Sure its a problem. It is still extra effort, no matter if your stack makes it easy or not. It still has to be done.
viraptor 8y ago
Since late last year, you can use old versions if you want to. [0] The provider doesn't enforce the runtime anymore. But I don't think it's the provider issue in the first place. At some point "node x.x" will be EOL and you won't get an email. You'll just stop getting maintenance patches. [0] https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-programming-language-and-share-common-components/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-...
scarface74 8y ago
They didn’t pull the plug. You can’t create or update new lambdas with older versions of Node, but if you have existing code, it won’t just stop working.
chimprich 8y ago
> If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days. What do you mean by your own backend? Your own physical hardware, your own rented hardware, your own EC2 box, your own Fargate container? What if you get an office fire, a hardware failure, a network outage, a required security update, your third party company goes out of business, etc.? There's no such thing as code that doesn't need to be maintained. Lambdas (and competitors) probably require the least maintenance of the lot.
- hinkley 8y ago
  It’s not the quantity of maintenance that’s at issue. It’s the lack of ability to schedule that maintenance. GP is talking about unplanned maintenance, which is a huge problem in many industries, like air travel (any transportation, really), or software.
AlphaWeaver 8y ago
I have written more than a few applications on lambda for several years, and I have gotten this email exactly once, for one function.
garettmd 8y ago
The issue you have isn't lambda, it's using an *aaS that someone else is hosting.
jasonlotito 8y ago
> If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, Until you get audited, and that raises a flag, and now you have to deal with it.

simonebrunozzi 8y ago

Good point, but no. If you have architected your apps properly, decommissioning or sunsetting services or individual components should already have been designed and planned. I know, I know... It's almost never the case.

yeahitslikethat 8y ago
You really just don't have to think like this on the msft stack. I'm so glad I chose msft ASP 20 years ago, instead of php, or RoR or python, or node or any of the myriad other stacks that have come and gone since.
- jjuel 8y ago
  Do you ever need to update your servers to a newer version like say 2016 or now 2019? There are definitely issues on using say old VB6 libraries when you need to upgrade your severs from 2008 to 2019. Not to mention using those old technologies if you do have a new feature or change you end up with an unmaintainable mess. I am MSFT stack programmer, but to claim there are no issues and you just need to patch a server is flat out wrong.

benbristow 8y ago

That's just laziness on your part though. Using an old version of Node is just going to leave you with worse performance and potentially security holes.

social_quotient 8y ago
Given the nature of lambdas specifically -What would the security issue be on outdated lambda code? -Wouldn’t the performance of the code would be equal to the performance of when you first deployed.

Cthulhu_ 8y ago

Isn't that always the case though? I mean, outside of e.g. lambdas or other platforms / runtimes as a service? I mean a few years ago there was a huge security flaw in Apache Struts, whose impact was big because it had been used in a lot of older applications - meaning a LOT of people had to be summoned to work on old codebases to fix this issue. The problem isn't a changing runtime - even if you self-host it you should make sure to keep that updated regularly.

jasonkester 8y ago
if you self-host it you should make sure to keep that updated regularly. Mild disagreement: My philosophy is that you should choose technologies that aren't likely to introduce breaking changes in the future. As an example, I have sites that were built using ASP.NET version 1.1 that have survived to this day with nothing more than Windows Update on the server and the occasional version bump in the project config when adding a feature that needed the latest and greatest. Compare that to the poor soul who decided to build on top of React when it first came out, and has been rewarded by getting to rewrite his entire application four times in as many years. To return to the point, rather than rewriting around breaking changes from Node x.x to Node y.a, I'd be shopping around for the LTS version of Node x that I could keep the thing running on without intervention from my team.
- mritun 8y ago
  > As an example, I have sites that were built using ASP.NET version 1.1 that have survived to this day with nothing more than Windows Update You are right; but in my experience those ASP applications also had security holes (CSRF etc) that were never patched. They ultimately either became botnets or faded away when the corp simply faded away. A business that can't afford to pay for cleaning up its business applications is likely to be unable to pay for general upkeep as well. It is simply past the point of being a viable business and is either in limbo or in the grave! See "maintenance free" approach to software as canary in the coal-mine and run away as fast as possible.
  - yeahitslikethat 8y ago

nerdbeere 8y ago

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 ?

aussieguy1234 8y ago

Not a problem. Ill tell TypeScript to output code matching the es version for that version of node.

thecopy 8y ago
Sure its a problem. It is still extra effort, no matter if your stack makes it easy or not. It still has to be done.

viraptor 8y ago

Since late last year, you can use old versions if you want to. [0] The provider doesn't enforce the runtime anymore. But I don't think it's the provider issue in the first place. At some point "node x.x" will be EOL and you won't get an email. You'll just stop getting maintenance patches. [0] https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-programming-language-and-share-common-components/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-...

scarface74 8y ago

They didn’t pull the plug. You can’t create or update new lambdas with older versions of Node, but if you have existing code, it won’t just stop working.

chimprich 8y ago

> If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days. What do you mean by your own backend? Your own physical hardware, your own rented hardware, your own EC2 box, your own Fargate container? What if you get an office fire, a hardware failure, a network outage, a required security update, your third party company goes out of business, etc.? There's no such thing as code that doesn't need to be maintained. Lambdas (and competitors) probably require the least maintenance of the lot.

hinkley 8y ago
It’s not the quantity of maintenance that’s at issue. It’s the lack of ability to schedule that maintenance. GP is talking about unplanned maintenance, which is a huge problem in many industries, like air travel (any transportation, really), or software.

AlphaWeaver 8y ago

I have written more than a few applications on lambda for several years, and I have gotten this email exactly once, for one function.

garettmd 8y ago

The issue you have isn't lambda, it's using an *aaS that someone else is hosting.

jasonlotito 8y ago

> If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, Until you get audited, and that raises a flag, and now you have to deal with it.