8 ms·

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

by 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.
    - sheeshkebab 8y ago
      Docker, ansible, red hat stuff are all open source that you can run on your own. There is no vendor lockin.
      - moduspol 8y ago
        But they significantly reduce the workload on the people that would otherwise have to manage those things, just like a serverless architecture does. If you want to argue about vendor lockin, sure. But removing the necessity of managing scaling, individual instances, and OS / software patching is significant.
        geggam 8y ago
        Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain
        moduspol 8y ago
        > Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. This is no different from any other abstraction. > Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. That's not to say they won't ultimately limit (e.g.) how many S3 buckets you create, but being able to create unlimited S3 buckets is not necessary to use S3 as designed in a near-infinitely scalable way.
        geggam 8y ago
        >Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. All of those services have limits, just because you havent experienced that scale doesnt mean others havent.
- bryanlarsen 8y ago
  Very few companies are big enough that they can make the devops overhead worth the price difference, but most of those plan on eventually being so. So there's an argument to be made that the knowledge should be grown in house while you can still tolerate the small outages you get when you have stuff misconfigured or unbalanced. Probably not a good argument though. If you're successful enough to be saturating servers you're probably successful enough to be hiring experienced competent help for the transition.
- runlevel1 8y ago
  Lambda is often the way to go, but there are a couple tipping points where it becomes less appealing: - When you start having to spend a lot of time working around its limitations. (As is the case with all managed services.) - When the sum of its parts create a distributed system whose complexity costs you more in productivity than it gives back. Performance limits will get better with time. The complexity cost is more difficult to predict. Hopefully it will improve as best-practices emerge and tooling gets better.
- Kabootit 8y ago
  Debugging, organizing, and testing lambdas vs traditional stacks is the hidden costs on the developer side.
  - scarface74 8y ago
    Testing a lambda is just as easy as testing a controller action in the typical MVC framework. You just pass a JSON payload to your lambda handler. Organizing is also simple - if you know CloudFormation. You should learn that anyway to provision resources in a repeatable fashion.
- Zelphyr 8y ago
  In my experience, the developer time it takes to get a serverless application running (on AWS anyway) far exceeds the benefits that serverless brings. We spent over six months on a project written in serverless that we could never really get working properly. We dumped all that code and rewrote it on a standard LAMP stack in less than half that time. Factoring in that the problem was better understood the second time around, it would still have been cheaper to build it the way we are from the beginning.
  - scarface74 8y ago
    Was that due more to lack of training? I am first and foremost a developer, but I’ve spent weeks understanding AWS from a netops, devops and development standpoint. I’m also working on certifications mostly as a method to force me to learn in a structure manner, my company will pay for them, and they still have some market value.
    - romaniv 8y ago
      Training also takes time.
      - scarface74 8y ago
        Are you proposing that developers shouldn’t study and learn about whatever infrastructure they are using?
        tjoff 8y ago
        Isn't that the whole point of the cloud? I mean, if you care about the infrastructure there are few reasons left not to self-host.
        scarface74 8y ago
        The point of the cloud is not to be ignorant about the infrastructure. It’s to not have to babysit hardware and focus on your core competency - let someone else do the “undifferentiated heavy lifting”. I’ve seen cases where “AWS Architects” spun up a bunch of EC2 instances and ran thier own services that had AWS managed equivalents and wonder why everything costs more. Could it possibly be things like they have 3 EC2 instances to run a cluster for Consul instead of using AWS services? It’s slso about elasticity. It’s much easier and cost effective to spin up 20 VMs (whether it be EC2 instances or Lambdas which are basically VMs) to run a test and see how many you actually need. Other times it makes sense to use a bunch of spot instances to save money and choose a cost optimization based on throughout vs. cost for backend processing.
carlsborg 8y ago
> I've seen just API Gateway costing more than entire infrastructure costs of similarly sized websites. Do you mean Api Gateway + the lambdas? API Gateway is $3.50 per 1 million API calls received plus data transfer ($0.09 per GB or $90 per Terrabyte). What kind of API were they serving that was racking up those large bills? Typically you would serve static content off s3 + cloudfront, and just the API off the API gateway/lambdas.
- vrodic 8y ago
  A mid sized web site with 5000RPM would be 219 million of requests per month: so 766 USD/month just for API GW, without data transfer, lambda, static/cdn or DB costs.
  - k__ 8y ago
    I guess this number goes down drastically if you throw in CloudFront.
  - carlsborg 8y ago
    In this scenario, the savings come from time + resources spent on configuration management, system admin and troubleshooting, and server security. Also if you have servers you are probably auto-scaling redundant instances in multiple availability zones and then getting that high CPU utilization is unlikely.
  - aglikson 8y ago
    If you expect a steady load of hundreds of requests per second - maybe API Gateway + Lambda is not the best solution. The use-case in the article did not have such load targets. Lambda is not a silver bullet..
- zackbloom 8y ago
  Serverless doesn't necessarily mean Lambda. You can use Cloudflare Workers and pay $0.50/million requests flat.
kamaal 8y ago
A different take. Recently we had a AWS training at office, and the Amazon person was selling this as largely a infrastructure automation solution than a application hosting solution. In essence his point was to use Lambda as a tool only to work with tasks related to AWS infrastructure automation. And not as a tool for everything. The old adage, of not treating everything as a nail while holding a hammer seems to apply here.
deleted 8y ago
[deleted]
jdietrich 8y ago
>vendor lock-in You can avoid that with the Serverless framework. https://serverless.com/ https://serverless.com/
toomanybeersies 8y ago
I literally had this discussion at work today about vendor lock in. with AWS Lambda. At my old job, we were terrible at wanting to use new shiny things (me included). We had terrible vendor lock-in with AWS, although it did make my resume look nice as I could fill it with fancy AWS products. My supervisor was discussing AWS Lambda with me at lunchtime, and I said that it's not worth it, because any cost savings from using Lambda over a server are outweighed by the cost if we ever wanted or needed to switch vendors. AWS lambda would make sense for large companies, where server time is more expensive than developer time. But for most companies, developer time is more expensive than server time, using shiny new AWS specific tools is just going to hurt later on.
- hvindin 8y ago
  I'm curious, when is server time ever worth more than developer time? I mean, sure, if you're doing something as a hobby and consider your own time free but have to pay $5 for a VM somewhere, then maybe. But especially at large companies, my experience has always been that for any work done the cost of infrastructure is basically a rounding error compared to the cost of developer time. And that doesn't even begin to include the cost of support team time for the eternity that everything seems to need to be maintained for in larger companies. As a recent example, I know that the amount each developer on a team I've worked on costs (not how much they are paid, all contractors from various companies), per person, more than it would cost to buy a mid range server, colocate it in a data center etc - per day. So after a year, if we just bought infrastructure instead of developer time, we could have had a handy ~15,000 mid range servers racked and ready to go.
wahnfrieden 8y ago
Lambda + API Gateway excel at spiky, unpredictable workloads. We have APIs that are spiky enough that EC2 autoscaling cannot spin up instances as quickly as the traffic spike comes in, which means with EC2 services we need to run with a lot of headroom to absorb these spikes. This includes running at night where usage is minimal, but still under threat of sudden spikes. That gets expensive. Our Lambda costs are a fraction for us because of this. BTW, you can use other self-hosted API gateways like Kong with Lambda if you want to cost optimize.
tjenkinsqs 8y ago
Not advertised much, but you can cut down costs by 7x: Instead of API Gateway you can use Cloudflare Workers as "Gateway". It costs $0.50 instead of $3.70 per million requests. Not a drop-in replacement, but definitely an option.
andrewl-hn 8y ago
Also, API Gateway is incredibly slow. We often have lambdas that run for 20-30 ms, but API Gateway adds another 200 ms extra. We ended up running our own HTTP service in Beanstalk that forwards calls to Lambdas. It's stupid that we can create a better gateway than Amazon using their own services.
- acejam 8y ago
  Sounds like you might have a config issue. I have Lambda's that take 20ms and API Gateway returns the entire response in ~40-50ms.
aglikson 8y ago
I guess most of tech articles in general often pay more attention to technology details than to its cost-effectiveness (or even TCO) for certain classes of workloads. If your workload is a 'traditional' web application, saturating a full VM and not too bursty - don't run it on Lambda. Regarding vendor lock-in, I don't think Lambda is important for the vendor lock-in question. If you just need 'compute' capacity, it would be easy to move from Lambda to anything else. But if you also use bunch of other AWS services - then moving the Lambda functions is likely to be your least concern, frankly. On the other hand, if you do leverage various AWS services (other than just IaaS) - switching to Lambda (or other managed platform) could be useful to make your entire architecture (more) serverless.

by vrodic 8y ago

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.
  - sheeshkebab 8y ago
    Docker, ansible, red hat stuff are all open source that you can run on your own. There is no vendor lockin.
    - moduspol 8y ago
      But they significantly reduce the workload on the people that would otherwise have to manage those things, just like a serverless architecture does. If you want to argue about vendor lockin, sure. But removing the necessity of managing scaling, individual instances, and OS / software patching is significant.
      - geggam 8y ago
        Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain
        moduspol 8y ago
        > Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost. This is no different from any other abstraction. > Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. That's not to say they won't ultimately limit (e.g.) how many S3 buckets you create, but being able to create unlimited S3 buckets is not necessary to use S3 as designed in a near-infinitely scalable way.
        geggam 8y ago
        >Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will. All of those services have limits, just because you havent experienced that scale doesnt mean others havent.
bryanlarsen 8y ago
Very few companies are big enough that they can make the devops overhead worth the price difference, but most of those plan on eventually being so. So there's an argument to be made that the knowledge should be grown in house while you can still tolerate the small outages you get when you have stuff misconfigured or unbalanced. Probably not a good argument though. If you're successful enough to be saturating servers you're probably successful enough to be hiring experienced competent help for the transition.
runlevel1 8y ago
Lambda is often the way to go, but there are a couple tipping points where it becomes less appealing: - When you start having to spend a lot of time working around its limitations. (As is the case with all managed services.) - When the sum of its parts create a distributed system whose complexity costs you more in productivity than it gives back. Performance limits will get better with time. The complexity cost is more difficult to predict. Hopefully it will improve as best-practices emerge and tooling gets better.
Kabootit 8y ago
Debugging, organizing, and testing lambdas vs traditional stacks is the hidden costs on the developer side.
- scarface74 8y ago
  Testing a lambda is just as easy as testing a controller action in the typical MVC framework. You just pass a JSON payload to your lambda handler. Organizing is also simple - if you know CloudFormation. You should learn that anyway to provision resources in a repeatable fashion.
Zelphyr 8y ago
In my experience, the developer time it takes to get a serverless application running (on AWS anyway) far exceeds the benefits that serverless brings. We spent over six months on a project written in serverless that we could never really get working properly. We dumped all that code and rewrote it on a standard LAMP stack in less than half that time. Factoring in that the problem was better understood the second time around, it would still have been cheaper to build it the way we are from the beginning.
- scarface74 8y ago
  Was that due more to lack of training? I am first and foremost a developer, but I’ve spent weeks understanding AWS from a netops, devops and development standpoint. I’m also working on certifications mostly as a method to force me to learn in a structure manner, my company will pay for them, and they still have some market value.
  - romaniv 8y ago
    Training also takes time.
    - scarface74 8y ago
      Are you proposing that developers shouldn’t study and learn about whatever infrastructure they are using?
      - tjoff 8y ago
        Isn't that the whole point of the cloud? I mean, if you care about the infrastructure there are few reasons left not to self-host.
        scarface74 8y ago
        The point of the cloud is not to be ignorant about the infrastructure. It’s to not have to babysit hardware and focus on your core competency - let someone else do the “undifferentiated heavy lifting”. I’ve seen cases where “AWS Architects” spun up a bunch of EC2 instances and ran thier own services that had AWS managed equivalents and wonder why everything costs more. Could it possibly be things like they have 3 EC2 instances to run a cluster for Consul instead of using AWS services? It’s slso about elasticity. It’s much easier and cost effective to spin up 20 VMs (whether it be EC2 instances or Lambdas which are basically VMs) to run a test and see how many you actually need. Other times it makes sense to use a bunch of spot instances to save money and choose a cost optimization based on throughout vs. cost for backend processing.

carlsborg 8y ago

> I've seen just API Gateway costing more than entire infrastructure costs of similarly sized websites. Do you mean Api Gateway + the lambdas? API Gateway is $3.50 per 1 million API calls received plus data transfer ($0.09 per GB or $90 per Terrabyte). What kind of API were they serving that was racking up those large bills? Typically you would serve static content off s3 + cloudfront, and just the API off the API gateway/lambdas.

vrodic 8y ago
A mid sized web site with 5000RPM would be 219 million of requests per month: so 766 USD/month just for API GW, without data transfer, lambda, static/cdn or DB costs.
- k__ 8y ago
  I guess this number goes down drastically if you throw in CloudFront.
- carlsborg 8y ago
  In this scenario, the savings come from time + resources spent on configuration management, system admin and troubleshooting, and server security. Also if you have servers you are probably auto-scaling redundant instances in multiple availability zones and then getting that high CPU utilization is unlikely.
- aglikson 8y ago
  If you expect a steady load of hundreds of requests per second - maybe API Gateway + Lambda is not the best solution. The use-case in the article did not have such load targets. Lambda is not a silver bullet..
zackbloom 8y ago
Serverless doesn't necessarily mean Lambda. You can use Cloudflare Workers and pay $0.50/million requests flat.

kamaal 8y ago

A different take. Recently we had a AWS training at office, and the Amazon person was selling this as largely a infrastructure automation solution than a application hosting solution. In essence his point was to use Lambda as a tool only to work with tasks related to AWS infrastructure automation. And not as a tool for everything. The old adage, of not treating everything as a nail while holding a hammer seems to apply here.

deleted 8y ago

[deleted]

jdietrich 8y ago

>vendor lock-in You can avoid that with the Serverless framework. https://serverless.com/ https://serverless.com/

toomanybeersies 8y ago

I literally had this discussion at work today about vendor lock in. with AWS Lambda. At my old job, we were terrible at wanting to use new shiny things (me included). We had terrible vendor lock-in with AWS, although it did make my resume look nice as I could fill it with fancy AWS products. My supervisor was discussing AWS Lambda with me at lunchtime, and I said that it's not worth it, because any cost savings from using Lambda over a server are outweighed by the cost if we ever wanted or needed to switch vendors. AWS lambda would make sense for large companies, where server time is more expensive than developer time. But for most companies, developer time is more expensive than server time, using shiny new AWS specific tools is just going to hurt later on.

hvindin 8y ago
I'm curious, when is server time ever worth more than developer time? I mean, sure, if you're doing something as a hobby and consider your own time free but have to pay $5 for a VM somewhere, then maybe. But especially at large companies, my experience has always been that for any work done the cost of infrastructure is basically a rounding error compared to the cost of developer time. And that doesn't even begin to include the cost of support team time for the eternity that everything seems to need to be maintained for in larger companies. As a recent example, I know that the amount each developer on a team I've worked on costs (not how much they are paid, all contractors from various companies), per person, more than it would cost to buy a mid range server, colocate it in a data center etc - per day. So after a year, if we just bought infrastructure instead of developer time, we could have had a handy ~15,000 mid range servers racked and ready to go.

wahnfrieden 8y ago

Lambda + API Gateway excel at spiky, unpredictable workloads. We have APIs that are spiky enough that EC2 autoscaling cannot spin up instances as quickly as the traffic spike comes in, which means with EC2 services we need to run with a lot of headroom to absorb these spikes. This includes running at night where usage is minimal, but still under threat of sudden spikes. That gets expensive. Our Lambda costs are a fraction for us because of this. BTW, you can use other self-hosted API gateways like Kong with Lambda if you want to cost optimize.

tjenkinsqs 8y ago

Not advertised much, but you can cut down costs by 7x: Instead of API Gateway you can use Cloudflare Workers as "Gateway". It costs $0.50 instead of $3.70 per million requests. Not a drop-in replacement, but definitely an option.

andrewl-hn 8y ago

Also, API Gateway is incredibly slow. We often have lambdas that run for 20-30 ms, but API Gateway adds another 200 ms extra. We ended up running our own HTTP service in Beanstalk that forwards calls to Lambdas. It's stupid that we can create a better gateway than Amazon using their own services.

acejam 8y ago
Sounds like you might have a config issue. I have Lambda's that take 20ms and API Gateway returns the entire response in ~40-50ms.

aglikson 8y ago

I guess most of tech articles in general often pay more attention to technology details than to its cost-effectiveness (or even TCO) for certain classes of workloads. If your workload is a 'traditional' web application, saturating a full VM and not too bursty - don't run it on Lambda. Regarding vendor lock-in, I don't think Lambda is important for the vendor lock-in question. If you just need 'compute' capacity, it would be easy to move from Lambda to anything else. But if you also use bunch of other AWS services - then moving the Lambda functions is likely to be your least concern, frankly. On the other hand, if you do leverage various AWS services (other than just IaaS) - switching to Lambda (or other managed platform) could be useful to make your entire architecture (more) serverless.