10 ms·

Disclaimer: I work for Salesforce, Heroku’s parent organisation. I have had so many conversations with devops managers and developers who are individual contri

Disclaimer: I work for Salesforce, Heroku’s parent organisation. I have had so many conversations with devops managers and developers who are individual contributors and the Lambda hype reached frothing levels at one point. Contradictory requirements of scale down to zero, scale up infinitely with no cold starts, be cheap and no vendor lock in seemed to all be solved at the same time by Lambda. Testability? Framework adoption? Stability? Industry Skills? Proven Architectures...? Are some of the other question marks I never heard a good answer for.

liveoneggs 7y ago
the answer is: lambda! Try paying attention
nailer 7y ago
> Testability? Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. > Framework adoption? Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up https://arc.codes https://arc.codes at re:Invent, which is what I'm using and I generally like it. > Stability? Industry Skills? Proven Architectures...? These are all excellent questions. GAE, the original serverless platform, was around 2010 (edit: looks like 2008 https://en.wikipedia.org/wiki/Serverless_computing https://en.wikipedia.org/wiki/Serverless_computing). Serverless isn't much younger than say, node.js and Rust are. There are patterns (like sharding longer jobs, backgrounding and assuming async operations, keeping lambdas warm without being charged etc) that need more attention. Come ask me to speak at your conference!
- LunaSea 7y ago
  > 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.
- dullgiulio 7y ago
  Just to be clear: lambdas are not stateless if you, for example, connect to a DB or use any other external service. State could be somewhere else, but if you are not also "pure", you don't have any improvement over a normal service.
  - chucksmash 7y ago
    State is saved somewhere, sure. How many useful applications are truly stateless when considered in their entirety? This isn't the sense in which servers are usually said to be stateless, however. A Lambda that reads and writes state from a database when invoked is not maintaining state outside of the request-response cycle itself, so it can be said to be stateless.
    - dullgiulio 7y ago
      Yes, but the parent said "statelessness that makes it easier to TEST". It is not stateless in that sense: purity makes it easier to test. Here you need to mock all interactions with external services, just like you'd do with non-serverless applications.
      - nailer 7y ago
        It is stateless in that sense. To run your lambda, there needs to be zero things in memory, unlike a traditional express/django/rails or other non-serverless apps. If your lambda involves persistent storage, your testing might want to wipe or prepopulate the DB with some objects first, but that's not hard and doesn't add complexity, and as mentioned you don't need anything in memory.
    - rapind 7y ago
      It's funny because the only use case I was considering lambda for was a pure / stateless function. As soon as you add state / side-effects I assume you've greatly increased your complexity and testing (you'd want to have separate tests for all of the inputs / outputs that resemble production... which is when things can get complicated). I'm probably looking at it wrong I guess. I considered using lambda to unload some CPU intensive calculations / logic and that's it. I figured it would be good for that as long as the latency didn't outweigh any benefits.
scarface74 7y ago
You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax. And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re already locked in. If you are using it for APIs, just use one of the officially supported packages that let you add a few lines of code and deploy your standard C#/Web API, Javascript/Node Express, Python/Flask/Django... app as a lambda. Testability? Framework adoption? Stability? Industry Skills? Proven Architectures...? Are some of the other question marks I never heard a good answer for. If you haven’t heard the “right answers” for those questions you haven’t been listening to the right people. Lambdas are just as easy to test as your standard Controller action in your framework of choice.
- x86_64Ubuntu 7y ago
  Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.
  - crtlaltdel 7y ago
    seriously, its a function. if you remove the aws/lambda specifics you _should_ have something testable that you then call from your lambda handler.
    - LargeWu 7y ago
      That works for unit testing a specific component, but not so well for testing your system end-to-end.
      - mypalmike 7y ago
        The need for a staging instance for integration testing doesn't disappear when you run your API in lambda.
scoot 7y ago
/disclaimer/disclosure/ When you disclose something, it's a disclosure.
- Angostura 7y ago
  Unless its a disclaimer, because the poster knows that there is likely to be bias in their post, is aware of that and doesn't want to fix that.
  - scoot 7y ago
    Uh, no [1]. Why do HN folks find this so difficult? It's like putting your shoes on the wrong way around. After you've done it, it's clearly uncomfortable. So don't do it. https://en.wikipedia.org/wiki/Disclaimer https://en.wikipedia.org/wiki/Disclaimer
wolco 7y ago
Heroku is owned by salesforce? You learn something everyday.
- anderspitman 7y ago
  Yeah I actually didn't know that either. Interesting
- sideral 7y ago
  Salesforce has stock in many companies through Salesforce Ventures, including Optimizely, Twilio, Box, Dropbox and Stripe.

liveoneggs 7y ago

the answer is: lambda! Try paying attention

nailer 7y ago

> Testability? Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. > Framework adoption? Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up https://arc.codes https://arc.codes at re:Invent, which is what I'm using and I generally like it. > Stability? Industry Skills? Proven Architectures...? These are all excellent questions. GAE, the original serverless platform, was around 2010 (edit: looks like 2008 https://en.wikipedia.org/wiki/Serverless_computing https://en.wikipedia.org/wiki/Serverless_computing). Serverless isn't much younger than say, node.js and Rust are. There are patterns (like sharding longer jobs, backgrounding and assuming async operations, keeping lambdas warm without being charged etc) that need more attention. Come ask me to speak at your conference!

LunaSea 7y ago
> 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.
dullgiulio 7y ago
Just to be clear: lambdas are not stateless if you, for example, connect to a DB or use any other external service. State could be somewhere else, but if you are not also "pure", you don't have any improvement over a normal service.
- chucksmash 7y ago
  State is saved somewhere, sure. How many useful applications are truly stateless when considered in their entirety? This isn't the sense in which servers are usually said to be stateless, however. A Lambda that reads and writes state from a database when invoked is not maintaining state outside of the request-response cycle itself, so it can be said to be stateless.
  - dullgiulio 7y ago
    Yes, but the parent said "statelessness that makes it easier to TEST". It is not stateless in that sense: purity makes it easier to test. Here you need to mock all interactions with external services, just like you'd do with non-serverless applications.
    - nailer 7y ago
      It is stateless in that sense. To run your lambda, there needs to be zero things in memory, unlike a traditional express/django/rails or other non-serverless apps. If your lambda involves persistent storage, your testing might want to wipe or prepopulate the DB with some objects first, but that's not hard and doesn't add complexity, and as mentioned you don't need anything in memory.
  - rapind 7y ago
    It's funny because the only use case I was considering lambda for was a pure / stateless function. As soon as you add state / side-effects I assume you've greatly increased your complexity and testing (you'd want to have separate tests for all of the inputs / outputs that resemble production... which is when things can get complicated). I'm probably looking at it wrong I guess. I considered using lambda to unload some CPU intensive calculations / logic and that's it. I figured it would be good for that as long as the latency didn't outweigh any benefits.

scarface74 7y ago

You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax. And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re already locked in. If you are using it for APIs, just use one of the officially supported packages that let you add a few lines of code and deploy your standard C#/Web API, Javascript/Node Express, Python/Flask/Django... app as a lambda. Testability? Framework adoption? Stability? Industry Skills? Proven Architectures...? Are some of the other question marks I never heard a good answer for. If you haven’t heard the “right answers” for those questions you haven’t been listening to the right people. Lambdas are just as easy to test as your standard Controller action in your framework of choice.

x86_64Ubuntu 7y ago
Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.
- crtlaltdel 7y ago
  seriously, its a function. if you remove the aws/lambda specifics you _should_ have something testable that you then call from your lambda handler.
  - LargeWu 7y ago
    That works for unit testing a specific component, but not so well for testing your system end-to-end.
    - mypalmike 7y ago
      The need for a staging instance for integration testing doesn't disappear when you run your API in lambda.

scoot 7y ago

/disclaimer/disclosure/ When you disclose something, it's a disclosure.

Angostura 7y ago
Unless its a disclaimer, because the poster knows that there is likely to be bias in their post, is aware of that and doesn't want to fix that.
- scoot 7y ago
  Uh, no [1]. Why do HN folks find this so difficult? It's like putting your shoes on the wrong way around. After you've done it, it's clearly uncomfortable. So don't do it. https://en.wikipedia.org/wiki/Disclaimer https://en.wikipedia.org/wiki/Disclaimer

wolco 7y ago

Heroku is owned by salesforce? You learn something everyday.

anderspitman 7y ago
Yeah I actually didn't know that either. Interesting
sideral 7y ago
Salesforce has stock in many companies through Salesforce Ventures, including Optimizely, Twilio, Box, Dropbox and Stripe.