5 ms·

> Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. No because Lambdas are proprietary which means you can't ru

> Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. > Serverless isn't much younger than say, node.js and Rust are. AWS Lambdas which I consider to be the first widely used Lambda service was was released in April 2015 which is 6 years after the release of Node.js. Also, Node.js is way more popular and mature than Lambda solutions. Overall Lambdas are only useful for small, infrequent tasks like calling a remote procedure every day. Otherwise, things like scheduling, logging, resource usage, volume and cost make Lambdas a bad choice compared to traditional VPSs / EC2.

nailer 7y ago
> No because Lambdas are proprietary which means you can't run it in a CI or locally. Arc has a full sandbox, so yes you can run a lambda in a CI or locally. You should know this - if you're developing your apps by deploying every lambda as you edit it you're doing it wrong. Most lambdas don't really need you to simulate AWS. > Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. Sure, persistence exists, but when people say 'stateless' they mean 'has no transient state'. They don't mean 'has no data'. > AWS Lambdas which I consider to be the first widely used Lambda service OK. You don't consider GAE (2008) widely used. I disagree - mainly because I was using GAE back then and thinking about this new world of no-memory, timeouts, etc - but lambda is definitely more popular.
philliphaydon 7y ago
> No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. Lambda is a function call. So it makes no difference if it’s proprietary or not. Are you saying that it’s difficult to test passing an object to a function and asserting that it’s functioning as intended?
- LunaSea 7y ago
  Lambas are not simple functions because your environment is different in local compared to production. If I run a Node.js function in AWS Lambda, my Node.js version might be different, my dependencies might be different, the OS is different, the filesystem is different, so I or one of my node_modules might be able to write to /tmp but not elsewhere, etc. It's the reason people started using Docker really. If you don't have the same environment, you can't call it reproducible or testable for that matter.
  - TazeTSchnitzel 7y ago
    It is far too easy to have all the tests pass locally and be completely broken in production for this reason.
    - jtdev 7y ago
      As with any compute environment...
    - erikerikson 7y ago
      See https://github.com/Nordstrom/serverless-artillery https://github.com/Nordstrom/serverless-artillery Note performance, acceptance, and monitoring modes
  - philliphaydon 7y ago
    Nothing you mentioned has anything to do with the ability to test a Lambda. You’re trying to use limitations and restrictions as friction to backup your inability to test. There’s a lot of annoying things about lambda. And a lot of stuff I wish was easier to find in documentation. But that doesn’t change the fact that Lambda is more or less passing an event object to your function and executing it. Writing a function in node 12 and then running it on node 4 and throwing your hands in the air cos it didn’t work isn’t the fault of Lambda.
    - LunaSea 7y ago
      It's great to see that factual evidence is answered with ad-hominem by the Lambda hype crowd. In any case, if you have a Node.js module or code with a native C/C++ build, that runs shell commands, that writes to disk (not allowed besides /tmp in Lambda) or makes assumptions about the OS, your "simple" function will absolutely return different results. e.g: My lambda is called when somebody uploads an image and returns a resized and compressed version of it. This is done using Node.js and the mozjpeg module which is dependent on cjpeg which is built natively on install. If I test my function on my machine and in Lambda it's very possible that I get different results. Also, certain OSs like Alpine which are heavily used for Docker don't event use glibc as compiler, so again, another difference.
k__ 7y ago
"No because Lambdas are proprietary which means you can't run it in a CI or locally." It kinda is, but not really. You get an event object as param and often only need a few fields from it. Also, you can run Lambda locally, AWS SAM CLI lets you run them in Docker for debugging purposes.
- vips7L 7y ago
  I found SAM to be extremely difficult to use, especially on windows where docker is just plain old terrible.
  - k__ 7y ago
    True. I stopped using windows for dev machines long time ago, but I'd guess with the Linux subsystem stuff it will catch-up in the next years.
    - vips7L 7y ago
      I honestly have no problems developing on windows (except when my macos coworkers dont consider windows). Docker is the only real issue.
      - k__ 7y ago
        Yes, it's unusable on macos and windows. Hopefully WSL2 will solve this.
        guitarbill 7y ago
        Docker largely works fine on macOS? At least for testing, haven't run into any issues other than bad filesystem performance if you're writing a lot of data to a mounted FS. Our team uses it daily - a far cry from "unusable".
        k__ 7y ago
        Maybe you just got a higher pain tolerance or better machines?

nailer 7y ago

> No because Lambdas are proprietary which means you can't run it in a CI or locally. Arc has a full sandbox, so yes you can run a lambda in a CI or locally. You should know this - if you're developing your apps by deploying every lambda as you edit it you're doing it wrong. Most lambdas don't really need you to simulate AWS. > Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. Sure, persistence exists, but when people say 'stateless' they mean 'has no transient state'. They don't mean 'has no data'. > AWS Lambdas which I consider to be the first widely used Lambda service OK. You don't consider GAE (2008) widely used. I disagree - mainly because I was using GAE back then and thinking about this new world of no-memory, timeouts, etc - but lambda is definitely more popular.

philliphaydon 7y ago

> No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. Lambda is a function call. So it makes no difference if it’s proprietary or not. Are you saying that it’s difficult to test passing an object to a function and asserting that it’s functioning as intended?

LunaSea 7y ago
Lambas are not simple functions because your environment is different in local compared to production. If I run a Node.js function in AWS Lambda, my Node.js version might be different, my dependencies might be different, the OS is different, the filesystem is different, so I or one of my node_modules might be able to write to /tmp but not elsewhere, etc. It's the reason people started using Docker really. If you don't have the same environment, you can't call it reproducible or testable for that matter.
- TazeTSchnitzel 7y ago
  It is far too easy to have all the tests pass locally and be completely broken in production for this reason.
  - jtdev 7y ago
    As with any compute environment...
  - erikerikson 7y ago
    See https://github.com/Nordstrom/serverless-artillery https://github.com/Nordstrom/serverless-artillery Note performance, acceptance, and monitoring modes
- philliphaydon 7y ago
  Nothing you mentioned has anything to do with the ability to test a Lambda. You’re trying to use limitations and restrictions as friction to backup your inability to test. There’s a lot of annoying things about lambda. And a lot of stuff I wish was easier to find in documentation. But that doesn’t change the fact that Lambda is more or less passing an event object to your function and executing it. Writing a function in node 12 and then running it on node 4 and throwing your hands in the air cos it didn’t work isn’t the fault of Lambda.
  - LunaSea 7y ago
    It's great to see that factual evidence is answered with ad-hominem by the Lambda hype crowd. In any case, if you have a Node.js module or code with a native C/C++ build, that runs shell commands, that writes to disk (not allowed besides /tmp in Lambda) or makes assumptions about the OS, your "simple" function will absolutely return different results. e.g: My lambda is called when somebody uploads an image and returns a resized and compressed version of it. This is done using Node.js and the mozjpeg module which is dependent on cjpeg which is built natively on install. If I test my function on my machine and in Lambda it's very possible that I get different results. Also, certain OSs like Alpine which are heavily used for Docker don't event use glibc as compiler, so again, another difference.

k__ 7y ago

"No because Lambdas are proprietary which means you can't run it in a CI or locally." It kinda is, but not really. You get an event object as param and often only need a few fields from it. Also, you can run Lambda locally, AWS SAM CLI lets you run them in Docker for debugging purposes.

vips7L 7y ago
I found SAM to be extremely difficult to use, especially on windows where docker is just plain old terrible.
- k__ 7y ago
  True. I stopped using windows for dev machines long time ago, but I'd guess with the Linux subsystem stuff it will catch-up in the next years.
  - vips7L 7y ago
    I honestly have no problems developing on windows (except when my macos coworkers dont consider windows). Docker is the only real issue.
    - k__ 7y ago
      Yes, it's unusable on macos and windows. Hopefully WSL2 will solve this.
      - guitarbill 7y ago
        Docker largely works fine on macOS? At least for testing, haven't run into any issues other than bad filesystem performance if you're writing a lot of data to a mounted FS. Our team uses it daily - a far cry from "unusable".
        k__ 7y ago
        Maybe you just got a higher pain tolerance or better machines?