12 ms·

Going Serverless: From Common Lisp and CGI to AWS Lambda and API Gateway

85 points by lispm 8y ago

ForHackernews 8y ago
> Moreover, given the minimal traffic this web tutorial is targeting — the backend is likely to easily fits the free tier of cloud providers. So, the infrastructure cost will be essentially zero. And you can’t beat zero cost, really. Right up until it hits the frontpage of HN...
- tazjin 8y ago
  HN frontpage traffic is not as high as you might think ... the websites that go down from it are probably just poorly built.
  - ForHackernews 8y ago
    I don't think this setup will go down, but it could certainly end up costing much more than $0.
    - viraptor 8y ago
      The free tier is 1M requests. If they're very lightweight, it should easily handle the spike without extra cost. I've been on HN front-page a few times and the traffic is never that high.
threeseed 8y ago
I will never understand why people are attracted to the Lambda SAM style of programming. Sure there are scalability benefits but it comes at the cost of complexity, development time, vendor lock in, wildly variable p95/p99 numbers, a nightmare debugging experience and costs that are expensive and fluctuating. You could just build a Docker web app eg Rails/Play, deployed in ECS or Elastic Beanstalk with the same scalability in easily 1/10 the time and complexity. And if you get sick of AWS trivially move it to GCP, Azure or on-premise.
- mateuszf 8y ago
  I agree, to be fair though - almost all of this could be mitigated in future by better tooling.
  - toomuchtodo 8y ago
    Hope is not an architectural methodology.
    - moduspol 8y ago
      If every emerging technology were scrapped early on due to lack of tooling, we'd have no mature technologies.
      - toomuchtodo 8y ago
        Fair point, as long as it’s someone else’s time and dime to mature these arguably fad technologies of questionable value. Until then, it’s not a mature technology, it should not be sold as such, and you take significant risk in implementing with it.
        deleted 8y ago
        [deleted]
      - Annatar 8y ago
        Very few technologies in IT are actually mature, and of those that are, it’s exactly their documentation and tooling which makes them mature.
  - ariehkovler 8y ago
    Serverless tooling is coming fast. 1. Biggest issue with serverless is debugging when you can't make a local environment and can't install anything like a conventional debugger in the serverless environment. I know of at least one company with a new and very elegant solution for this problem. 2. Visibility and monitoring is also a challenge and there are a bunch of serverless monitoring startups. 3. Security is interesting because, again, you can't install anything to protect your code: no Web Application Firewalls, for example. And there are several interesting theoretical attacks on serverless apps. Already, there are specialist serverless security companies. A lot of companies don't 'migrate' to serverless. They use a Lambda or GCP Function to handle one small part of a backend task like image processing or some other form of backend tooling. Serverless is often just a good way of gluing other microservices together.
vrodic 8y ago
Most of these articles I read about AWS Lambda (they rarely mention API Gatweway because it's expensive) sound like paid marketing. I've seen just API Gateway costing more than entire infrastructure costs of similarly sized websites. If you can properly saturate EC2 it will be significantly less expensive than Lambda but with lambda you have to pay API GW and the vendor lock-in price. I've started flagging these submissions.
- nothrabannosir 8y ago
  That calculation doesn’t include the salary of the person managing those EC2 instances. Lambda is easier to manage and costs less time than an EC2 box. SSH keys, backups, AMI base images, system updates , it all adds up. Ansible and terraform are so far removed from the core competency of any company that you really need to ask yourself, for any second you spend working on them: is this worth it? At almost no company’s scale* is it so. Salary is a hidden cost people often forget. Or time spent by your programmer’s debugging infra; time not spent creating value. Frustration from having to deal with TF or ansible in the first place. These are all benefits of a serverless solution which cost aware criticisms should at least try to quantify and take into account. Signed, not-a-shill. * I’ll rephrase: a significant amount of companies don’t have the luxury of being so swamped by requests they can saturate EC2 boxes and make the devops overhead (which, I’m arguing, is big but relatively constant/“sub linear”) worth the price difference (which scales linearly). Significant enough for these articles to have a raison d’être.
  - sheeshkebab 8y ago
    Salary of developers and sre that needs to manage this either way? Lambda and api gateway is nothing but expensive vendor lock-in.
    - moduspol 8y ago
      Excellent point. That's why we don't bother with server virtualization, Docker, or Ansible.
bsbechtel 8y ago
Has anyone heard of implementing an architecture where you have normal server backend architecture, while using serverless to handle traffic spikes and any failover? If you properly modularize your backend codebase, it shouldn't be excessively costly to duplicate it across a serverless architecture and in some sort of node instance. My biggest issue with serverless is the high cost at scale, which could be mitigated with this type of architecture. Are there any other benefits or concerns regarding something like this?
- liveoneggs 8y ago
  why would you do this when regular autoscale could just be used instead?
  - wahnfrieden 8y ago
    Autoscale doesn't allow you to scale to zero (as any requests would fail, rather than wait on resources to scale up). EC2 autoscaling takes a minute or two. This means you need to run with enough headroom to absorb spikes before you're able to spin up more resources. Depending on traffic patterns this can get very expensive (or not a problem at all, with predictable loads).
    - liveoneggs 8y ago
      if you're worried about the "zero" traffic situation I am not sure you also need to worry much about the "massive" traffic situation
      - wahnfrieden 8y ago
        I am sure :) Our customers are concentrated around N. America, with minimal activity at night and weekends. We have a complex product with a wide surface area. Some of our services don't see usage constantly throughout the day. Our usage is unpredictable and spiky, worsening our ability to cost optimize EC2 autoscaling. Then there's staging environments...
cubano 8y ago
So this is question I've wanted to ask for awhile. Is AWS Lambda really "serverless", or is the server part just buried so deep in the stack that the app devs can disregard it? And if it is truly "serverless", what mechanism is being used to "serve" the function calls? How is this radically different from say a REST-api that auto-routes function names from url POSTs and GETs? I suppose I could look all this stuff up, but to be honest having a quick rundown of this tech stack here on HN sure would save me the time. Thanks in advance.
- certifiedloud 8y ago
  It's the latter. The server is just abstracted away. As far as I know lambda is just docker containers running on EC2.
  - toomuchtodo 8y ago
    They’re not Docker containers specially, but they are containers.
- pjc50 8y ago
  Obviously it does have servers and is quite similar to the router you describe. It's also similar to the old CGI and FastCGI systems. It's only serverless in the sense that you don't have to use servers as a unit of account; at no point do you have to say "how many servers are we paying for?" or "what sort of servers should we get/lease/instantiate on EC2".
  - elboru 8y ago
    Rarely the meaning of a technology name is "obvious", this particular name is pretty misleading (every single tutorial about the topic starts explaining that serverless doesn't really mean serverless). The first time I heard about serverless, I imagined some kind of decentralized technology, but as we all know, it turned out to be a marketing thing.
- colde 8y ago
  It is serverless in the sense that the dev (or sysadm) doesn't have to worry about the server. You can't touch anything that affects the OS in any way, you only really give it your code and binaries to run. In ways it's similar to Heroku but with a very different pricing model.
sheeshkebab 8y ago
Serverless is a latest heavily marketed fad. There are some edge cases where it’s useful - education, low use throw away bots - other than that it’s all marketing bs.
- eitally 8y ago
  Please defend this position.
- pavolt 8y ago
  > Serverless is a latest heavily marketed fad. Serverless is the future of the Industry. Lambda is not Serverless , it's just a FaaS which is a component of an entire Serverless Architecture. Most specifically the majority of services provided by AWS and in the Cloud already are Serverless : - Pay per usage ( GB , Execution , API Call ) - No Scaling or Provisioning ( SQS , CloudFront , Firebase ) - High Avaibility by default ( SQS , CloudFront , Firebase ) - Auto Scaling by default ( Azure CosmosDB , Firebase ) - Little to no technical limits for the service ( GCloud DataStore , S3 etc... ) If you have very little knowledge about something you shouldn't criticize it , that make you sounds even more ignorant. Most of the stuff that people actually use on AWS (S3 , CloudFront , SQS , SNS ) are delivered with a serverless architecture in mind. Again , if you are thinking "Lambda === Serverless" you really need to read more about this topic.
  - zdragnar 8y ago
    Wait, we're calling S3, Firebase and any sort of metered charge scheme (aka pay per usage) "serverless" now? That's news to me, I've apparently been using serverless since I started programming as a full-time career 10 years ago! Here I thought most of those were just "cloud" services or "third party APIs".
    - pavolt 8y ago
      > I've apparently been using serverless since I started programming as a full-time career 10 years ago! You have indeed. As I mentioned above , S3 is a serverless service. Last time I checked , you don't provisioned , partition or scale S3 this is done by AWS behind the scene. Same for Firebase , same for many services. Now the move is into the "compute" aspect of thing and the architecture. Lambda basically replace, in a limited way , the compute aspect of your architecture (EC2) but obviously it has it's limits. There is a confusion between "Serverless Framework" which is an automation of Lambda + API Gateway + CloudFormation , and "Serverless Computing" which is basically an "event driven" , "pay per execution" , "auto scaling / self healing" architecture.
shaunpersad 8y ago
I don't get why Lambda gets all the love while Google Cloud Functions doesn't. I've tried both, and GCF is vastly superior in many ways. 1) Developer experience is pretty terrible in Lambda, whereas GCF is compatible with Express.js to the point where you can simply pass in an Express app instance to it (which makes vendor lock-in a moot point as well). Develop your app more or less like you normally would, and just export it to GCF. Job done. 2) Deploying is a simple cli command away, even with native binaries. 3) No API Gateway necessary for HTTP functions. 4) It's now compatible with Cloud SQL so you don't have to give up your traditional database. 5) No crazy IAM permissions hoops to jump through to get anything to work. Disclaimer: I'm not affiliated with Google.
- giancarlostoro 8y ago
  I feel the same about Azure Functions but I think its all dependant upon which provider you're in bed with at the time. If some one has plenty on AWS and is happy with those resources on AWS they will likely try or use Lambda
  - ryanmarsh 8y ago
    I'll respond to you and GP. Lambda is more challenging to use than Azure Functions and GCF. I should know, I use Lambda every day. To be honest the overall developer experience with almost any tool on AWS is more painful compared to Google Cloud or Azure. I think the reason AWS gets all the love is, GCF only came out of beta very recently. Azure doesn't generally get as much press as AWS or Google Cloud. As a secondary issue, "why use something with a poorer developer experience"? My answer: AWS's tools are quite complicated but it's also clear to me that Amazon takes AWS very seriously. My interactions with Google Cloud's products, support, and account management have left me with concerns about their long term commitment. This is a personal gut feel. I trust Amazon and Bezos' commitment to AWS. Focus and commitment are things we're all aware Google has had issues with in the past. As far as Microsoft is concerned, I see the great strides they're making and I would consider Azure for future projects. I'm growing to trust Nadella's Microsoft. It's clear they're betting the farm on multi-platform and cloud. Time will tell. Again this is just a personal viewpoint. Lastly, once you climb the hill of learning IAM, CloudFormation, etc... you can be quite productive.
code_sloth 8y ago
Can someone remind me what serverless does better than existing tech?
pmoriarty 8y ago
It's a pity that Lambda doesn't directly support Lisp or Scheme.
- mark_l_watson 8y ago
  I think that you can create standalone executables and load those with lambda. I think they need to be statically linked.
acejam 8y ago
At my company we have a few small basic API's now running on Lambda and API Gateway. We're a big AWS shop and I can't envision us ever moving to Google or Azure, so vendor lock-in isn't much of a concern. At first local development was a bit challenging, but frameworks like Serverless help with that. Also, many don't know this, but you can run and debug AWS Lambda locally with AWS' own tooling. Using this to build out and test Lambda's before creating them with Terraform has been priceless: https://github.com/awslabs/aws-sam-cli https://github.com/awslabs/aws-sam-cli

85 points by lispm 8y ago

> Moreover, given the minimal traffic this web tutorial is targeting — the backend is likely to easily fits the free tier of cloud providers. So, the infrastructure cost will be essentially zero. And you can’t beat zero cost, really. Right up until it hits the frontpage of HN...

tazjin 8y ago
HN frontpage traffic is not as high as you might think ... the websites that go down from it are probably just poorly built.
- ForHackernews 8y ago
  I don't think this setup will go down, but it could certainly end up costing much more than $0.
  - viraptor 8y ago
    The free tier is 1M requests. If they're very lightweight, it should easily handle the spike without extra cost. I've been on HN front-page a few times and the traffic is never that high.

threeseed 8y ago

I will never understand why people are attracted to the Lambda SAM style of programming. Sure there are scalability benefits but it comes at the cost of complexity, development time, vendor lock in, wildly variable p95/p99 numbers, a nightmare debugging experience and costs that are expensive and fluctuating. You could just build a Docker web app eg Rails/Play, deployed in ECS or Elastic Beanstalk with the same scalability in easily 1/10 the time and complexity. And if you get sick of AWS trivially move it to GCP, Azure or on-premise.

mateuszf 8y ago
I agree, to be fair though - almost all of this could be mitigated in future by better tooling.
- toomuchtodo 8y ago
  Hope is not an architectural methodology.
  - moduspol 8y ago
    If every emerging technology were scrapped early on due to lack of tooling, we'd have no mature technologies.
    - toomuchtodo 8y ago
      Fair point, as long as it’s someone else’s time and dime to mature these arguably fad technologies of questionable value. Until then, it’s not a mature technology, it should not be sold as such, and you take significant risk in implementing with it.
      - deleted 8y ago
        [deleted]
    - Annatar 8y ago
      Very few technologies in IT are actually mature, and of those that are, it’s exactly their documentation and tooling which makes them mature.
- ariehkovler 8y ago
  Serverless tooling is coming fast. 1. Biggest issue with serverless is debugging when you can't make a local environment and can't install anything like a conventional debugger in the serverless environment. I know of at least one company with a new and very elegant solution for this problem. 2. Visibility and monitoring is also a challenge and there are a bunch of serverless monitoring startups. 3. Security is interesting because, again, you can't install anything to protect your code: no Web Application Firewalls, for example. And there are several interesting theoretical attacks on serverless apps. Already, there are specialist serverless security companies. A lot of companies don't 'migrate' to serverless. They use a Lambda or GCP Function to handle one small part of a backend task like image processing or some other form of backend tooling. Serverless is often just a good way of gluing other microservices together.

vrodic 8y ago

Most of these articles I read about AWS Lambda (they rarely mention API Gatweway because it's expensive) sound like paid marketing. I've seen just API Gateway costing more than entire infrastructure costs of similarly sized websites. If you can properly saturate EC2 it will be significantly less expensive than Lambda but with lambda you have to pay API GW and the vendor lock-in price. I've started flagging these submissions.

nothrabannosir 8y ago
That calculation doesn’t include the salary of the person managing those EC2 instances. Lambda is easier to manage and costs less time than an EC2 box. SSH keys, backups, AMI base images, system updates , it all adds up. Ansible and terraform are so far removed from the core competency of any company that you really need to ask yourself, for any second you spend working on them: is this worth it? At almost no company’s scale* is it so. Salary is a hidden cost people often forget. Or time spent by your programmer’s debugging infra; time not spent creating value. Frustration from having to deal with TF or ansible in the first place. These are all benefits of a serverless solution which cost aware criticisms should at least try to quantify and take into account. Signed, not-a-shill. * I’ll rephrase: a significant amount of companies don’t have the luxury of being so swamped by requests they can saturate EC2 boxes and make the devops overhead (which, I’m arguing, is big but relatively constant/“sub linear”) worth the price difference (which scales linearly). Significant enough for these articles to have a raison d’être.
- sheeshkebab 8y ago
  Salary of developers and sre that needs to manage this either way? Lambda and api gateway is nothing but expensive vendor lock-in.
  - moduspol 8y ago
    Excellent point. That's why we don't bother with server virtualization, Docker, or Ansible.

bsbechtel 8y ago

Has anyone heard of implementing an architecture where you have normal server backend architecture, while using serverless to handle traffic spikes and any failover? If you properly modularize your backend codebase, it shouldn't be excessively costly to duplicate it across a serverless architecture and in some sort of node instance. My biggest issue with serverless is the high cost at scale, which could be mitigated with this type of architecture. Are there any other benefits or concerns regarding something like this?

liveoneggs 8y ago
why would you do this when regular autoscale could just be used instead?
- wahnfrieden 8y ago
  Autoscale doesn't allow you to scale to zero (as any requests would fail, rather than wait on resources to scale up). EC2 autoscaling takes a minute or two. This means you need to run with enough headroom to absorb spikes before you're able to spin up more resources. Depending on traffic patterns this can get very expensive (or not a problem at all, with predictable loads).
  - liveoneggs 8y ago
    if you're worried about the "zero" traffic situation I am not sure you also need to worry much about the "massive" traffic situation
    - wahnfrieden 8y ago
      I am sure :) Our customers are concentrated around N. America, with minimal activity at night and weekends. We have a complex product with a wide surface area. Some of our services don't see usage constantly throughout the day. Our usage is unpredictable and spiky, worsening our ability to cost optimize EC2 autoscaling. Then there's staging environments...

cubano 8y ago

So this is question I've wanted to ask for awhile. Is AWS Lambda really "serverless", or is the server part just buried so deep in the stack that the app devs can disregard it? And if it is truly "serverless", what mechanism is being used to "serve" the function calls? How is this radically different from say a REST-api that auto-routes function names from url POSTs and GETs? I suppose I could look all this stuff up, but to be honest having a quick rundown of this tech stack here on HN sure would save me the time. Thanks in advance.

certifiedloud 8y ago
It's the latter. The server is just abstracted away. As far as I know lambda is just docker containers running on EC2.
- toomuchtodo 8y ago
  They’re not Docker containers specially, but they are containers.
pjc50 8y ago
Obviously it does have servers and is quite similar to the router you describe. It's also similar to the old CGI and FastCGI systems. It's only serverless in the sense that you don't have to use servers as a unit of account; at no point do you have to say "how many servers are we paying for?" or "what sort of servers should we get/lease/instantiate on EC2".
- elboru 8y ago
  Rarely the meaning of a technology name is "obvious", this particular name is pretty misleading (every single tutorial about the topic starts explaining that serverless doesn't really mean serverless). The first time I heard about serverless, I imagined some kind of decentralized technology, but as we all know, it turned out to be a marketing thing.
colde 8y ago
It is serverless in the sense that the dev (or sysadm) doesn't have to worry about the server. You can't touch anything that affects the OS in any way, you only really give it your code and binaries to run. In ways it's similar to Heroku but with a very different pricing model.

sheeshkebab 8y ago

Serverless is a latest heavily marketed fad. There are some edge cases where it’s useful - education, low use throw away bots - other than that it’s all marketing bs.

eitally 8y ago
Please defend this position.
pavolt 8y ago
> Serverless is a latest heavily marketed fad. Serverless is the future of the Industry. Lambda is not Serverless , it's just a FaaS which is a component of an entire Serverless Architecture. Most specifically the majority of services provided by AWS and in the Cloud already are Serverless : - Pay per usage ( GB , Execution , API Call ) - No Scaling or Provisioning ( SQS , CloudFront , Firebase ) - High Avaibility by default ( SQS , CloudFront , Firebase ) - Auto Scaling by default ( Azure CosmosDB , Firebase ) - Little to no technical limits for the service ( GCloud DataStore , S3 etc... ) If you have very little knowledge about something you shouldn't criticize it , that make you sounds even more ignorant. Most of the stuff that people actually use on AWS (S3 , CloudFront , SQS , SNS ) are delivered with a serverless architecture in mind. Again , if you are thinking "Lambda === Serverless" you really need to read more about this topic.
- zdragnar 8y ago
  Wait, we're calling S3, Firebase and any sort of metered charge scheme (aka pay per usage) "serverless" now? That's news to me, I've apparently been using serverless since I started programming as a full-time career 10 years ago! Here I thought most of those were just "cloud" services or "third party APIs".
  - pavolt 8y ago
    > I've apparently been using serverless since I started programming as a full-time career 10 years ago! You have indeed. As I mentioned above , S3 is a serverless service. Last time I checked , you don't provisioned , partition or scale S3 this is done by AWS behind the scene. Same for Firebase , same for many services. Now the move is into the "compute" aspect of thing and the architecture. Lambda basically replace, in a limited way , the compute aspect of your architecture (EC2) but obviously it has it's limits. There is a confusion between "Serverless Framework" which is an automation of Lambda + API Gateway + CloudFormation , and "Serverless Computing" which is basically an "event driven" , "pay per execution" , "auto scaling / self healing" architecture.

shaunpersad 8y ago

I don't get why Lambda gets all the love while Google Cloud Functions doesn't. I've tried both, and GCF is vastly superior in many ways. 1) Developer experience is pretty terrible in Lambda, whereas GCF is compatible with Express.js to the point where you can simply pass in an Express app instance to it (which makes vendor lock-in a moot point as well). Develop your app more or less like you normally would, and just export it to GCF. Job done. 2) Deploying is a simple cli command away, even with native binaries. 3) No API Gateway necessary for HTTP functions. 4) It's now compatible with Cloud SQL so you don't have to give up your traditional database. 5) No crazy IAM permissions hoops to jump through to get anything to work. Disclaimer: I'm not affiliated with Google.

giancarlostoro 8y ago
I feel the same about Azure Functions but I think its all dependant upon which provider you're in bed with at the time. If some one has plenty on AWS and is happy with those resources on AWS they will likely try or use Lambda
- ryanmarsh 8y ago
  I'll respond to you and GP. Lambda is more challenging to use than Azure Functions and GCF. I should know, I use Lambda every day. To be honest the overall developer experience with almost any tool on AWS is more painful compared to Google Cloud or Azure. I think the reason AWS gets all the love is, GCF only came out of beta very recently. Azure doesn't generally get as much press as AWS or Google Cloud. As a secondary issue, "why use something with a poorer developer experience"? My answer: AWS's tools are quite complicated but it's also clear to me that Amazon takes AWS very seriously. My interactions with Google Cloud's products, support, and account management have left me with concerns about their long term commitment. This is a personal gut feel. I trust Amazon and Bezos' commitment to AWS. Focus and commitment are things we're all aware Google has had issues with in the past. As far as Microsoft is concerned, I see the great strides they're making and I would consider Azure for future projects. I'm growing to trust Nadella's Microsoft. It's clear they're betting the farm on multi-platform and cloud. Time will tell. Again this is just a personal viewpoint. Lastly, once you climb the hill of learning IAM, CloudFormation, etc... you can be quite productive.

code_sloth 8y ago

Can someone remind me what serverless does better than existing tech?

pmoriarty 8y ago

It's a pity that Lambda doesn't directly support Lisp or Scheme.

mark_l_watson 8y ago
I think that you can create standalone executables and load those with lambda. I think they need to be statically linked.

acejam 8y ago

At my company we have a few small basic API's now running on Lambda and API Gateway. We're a big AWS shop and I can't envision us ever moving to Google or Azure, so vendor lock-in isn't much of a concern. At first local development was a bit challenging, but frameworks like Serverless help with that. Also, many don't know this, but you can run and debug AWS Lambda locally with AWS' own tooling. Using this to build out and test Lambda's before creating them with Terraform has been priceless: https://github.com/awslabs/aws-sam-cli https://github.com/awslabs/aws-sam-cli