14 ms·

I disagree with all the comments posted so far. This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elasti

I disagree with all the comments posted so far. This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with. The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. Is it worth 8x the cost and 15% reduction in performance? The article argues no. If anything, AWS should price API GW and Serverless more competitively. It's nice to see though that the Firecracker implementation savings has been passed down to AWS Customers. If the article saw a 1.5-2 times increase in cost, the debate would be much more interesting. I'm in the container camp because serverless isn't cheap and you can't have long running processes.

lucasverra 7y ago
Agreed, let me add my 2cts : >The whole idea of serverless is so you don't have to manage infrastructure. ...when you are validating your product/market (100 request/day is a success here). Not everyone on HN is a core dev, tech is getting democratised. So 1 week of time dealing with servers and accounts and infra is a week not asking the right questions.
- nirvdrum 7y ago
  It really depends what you're doing. I've been trying out serverless on-and-off for weeks now and still don't have a basic two tier application going the way I want. I'd have been substantially better off dropping $5/month on a DigitalOcean droplet and running PostgreSQL and Rails on it. DigitalOcean even has really helpful templates to start up basic servers. This may be a specific criticism of AWS Amplify, but all I've been doing is trading off some arcane knowledge in open source software for arcane knowledge in some vendor-specific system. Most of my time has been spent searching for answers to Amazon-specific issues that haven't been solved in any of their SDKs. Or I wind up walking through their SDK code trying to figure out how to metaprogram my way around it. Perhaps if I used the web UI to stand everything up, it would have gone a lot smoother. I'll admit I'm a sucker for infrastructure as code. But, as it stands, I can't see how this really saves anyone any time. It's still an incredibly manual process without much in way of help or support the moment you veer off the one path Amazon has decided you should be on. (To make things more concrete, I still don't have Cognito working with optional TOTP 2FA. The withAuthenticator component apparently only renders the TOTP setup if 2FA is required. I've spent hours trying to work this one out, including spending time on the Amplify Gitter channel.)
  - guitarbill 7y ago
    > DigitalOcean even has really helpful templates to start up basic servers. > I'll admit I'm a sucker for infrastructure as code. ... which you have to maintain, which probably means Ansible/Chef/Puppet/Salt/etc scripts. Which is fine, it's just a trade-off. I've spent weeks maintaining those kinds of things though, and inevitably when you come back in a year, something's broken. CloudFormation isn't great, but it usually gets the things provisioned - CF Cognito support sucks though, and haven't been impressed with Cognito at all. Seems too enterprise-y. Like e.g. CodeBuild, which supports 0 open-source use-cases. IDK what some of those teams are doing, but even Azure Pipelines is years ahead. I think that's a general problem with AWS at the moment. Too many sub-par offerings. Still worth it for S3, DynamoDB, SQS, and Lambda or EC2 (just, the EC2 UX is awful). And those are huge time savers.
    - nirvdrum 7y ago
      I guess my point is I'm going to have to maintain something, it's more useful for me to know how to maintain a PostgreSQL installation than it is some custom Amazon framework or tool. Serverless certainly hasn't been the "fire and forget" system I was sold on. And for just starting up, I can stage an Ubuntu server and set it to auto-update and really not have to touch it for quite a while. I happen to have extensive sysadmin experience and authored a reasonably popular provisioning tool, but I can appreciate not everyone wants to learn it. However, getting AppSync with its Velocity templates talking to DynamoDB and authenticating with Cognito requires quite a bit of knowledge as well. And time spent learning that only benefits you if you never leave the AWS ecosystem. I suppose I could look at Aurora instead, although Amplify only supports MySQL Aurora, so no luck with Postgres again. Likewise, the price advantage goes away. And now I'm stuck figuring out a wildly convoluted TCO calculator. I could look at another hosted DB solution, but now I either need to move everything to a new provider or find a way to deal with WAN latency for simple DB operations. Moving means learning yet even more otherwise useless knowledge about a single provider. I'm sure a lot of this is just growing pains. But as a lone dev just poking at something in his spare time, all these "get running in 30 min. or less" tutorials fall apart the moment you try to do something outside that tutorial. And the number of services available, their weird pricing structures, their implicit deficiencies and explicit limitations, just mean I'm still wasting time not building software :-/
- james_s_tayler 7y ago
  I think this is an important consideration that a lot of people miss. One of the trends of both serverless and containers it that compared to older models they are allowing smaller and smaller teams to do bigger and bigger things. So, in certain respects it's an enabler. Context always matters.
- hdra 7y ago
  Counterpoint to that though: "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. None of that is particularly "accessible" for someone trying to get running ASAP. I agree tech is getting democratised, but when talking about products that allows it, I'm thinking of products like Firebase or the recent darklang, not AWS Lambda. From all the Lambda usage that I've encountered so far, they are still very much in the domain of a "sysadmin".
  - dragonwriter 7y ago
    > "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. You only have to setup security groups if you are running lambda's in a VPC, which in the simple case (e.g., not running a cloud extension of an internal corporate network) you probably don't. https://lumigo.io/blog/to-vpc-or-not-to-vpc-in-aws-lambda/ https://lumigo.io/blog/to-vpc-or-not-to-vpc-in-aws-lambda/ And, yeah, its a lot simpler than a traditional server setup without that. And even with it.
  - lucasverra 7y ago
    Agreed, AWS lambda is still (very) scary. To me, serverless is more glitch.com [1] than AWS. When there is is no infra to deal with, U/DevX becomes much easier. "Remix this" is pure product joy [1]: https://glitch.com/~mapbox-demo https://glitch.com/~mapbox-demo
  - ewidar 7y ago
    I've found https://github.com/Miserlou/Zappa https://github.com/Miserlou/Zappa to be super useful for simple Lambda deployments. It's only for python, but I am pretty sure you have other solutions for node, ruby...
    - kstrauser 7y ago
      We use http://apex.run/ http://apex.run/ but mainly because that’s what we started with and it hasn’t given us a reason to look around yet.
- wolco 7y ago
  Learning how to setup everything will be too much for you. Use Hostgator and you can start marketing immediately.
EwanToo 7y ago
If they had used an ALB instead of API Gateway, the cost might well have been a 2x increase, especially given that would replace the ELB they're already using. The ALB option has it's own caveats though...
- einaregilsson 7y ago
  Yeah, that would have been a much better fit. I just didn't know you could put ALB in front. (Also, a "load balancer" in front of serverless... , and yes I know load balancer do more than load balance.) I mainly went with API Gateway since that's the default setup the serverless framework uses.
  - pojzon 7y ago
    For AWS it was november 2018 when it was annanced. Still a pretty new thing if you ask me. Many Cloud Architects still dont understand all pros and cons of this solution.
    - scarface74 7y ago
      One con is that using an application load balancer with lambda restricts you to 1MB requests (and responses?) as opposed to 10 with APIGW. Lambda itself has a 6Mb limit.
- primitivesuave 7y ago
  One frustrating caveat of the ALB approach is there is a hard 1 MB limit on both the request and response size, while APIGW has a hard 6 MB limit.
discordance 7y ago
>The whole idea of serverless is so you don't have to manage infrastructure That's one of the ideas. Serverless shines for burst-y traffic where the traffic timing is unknown. If I had known static high loads I wouldn't use serverless.
- Jack000 7y ago
  isn't that just a limitation of the current incarnation of serverless systems? ie. serverless is only effective for burst traffic because it's expensive. You would think that after you tailor the code to the platform and make it stateless, it would cost less for the cloud provider and not more.
  - icebraining 7y ago
    If Amazon has to dedicate a full server permanently to your applications, I don't see why it would cost them more or less depending on the statelessness of your application.
    - jfoster 7y ago
      Are you sure your assumption that Amazon still has to dedicate a full server permanently to the application is correct?
      - icebraining 7y ago
        If you application, due to the requests it receives, consumes enough CPU time to occupy all the cores available in a server and/or most of its RAM, how can they not?
- cuu508 7y ago
  Bursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway & Lambda is significantly more expensive than the more traditional options.
ilimilku 7y ago
Exactly. This guy nails it. The serverless paradigm is a managed service, so you are paying extra for that management. Serverless also is built for automated connectivity within the AWS ecosystem, i.e. as a nerve center for all of AWS's nifty gizmos. This is why Amazon places such an emphasis on training certified solutions architects who know what works best for each situation.
- sl1ck731 7y ago
  Amazon puts emphasis on "certifying" solutions architects to turn them into marketing mouthpieces and AWS proponents. Source: Seen it happen, am certified.
dunk010 7y ago
> I'm in the container camp because serverless isn't cheap and you can't have long running processes. Do you think you'll have the same opinion in five years time? Or how about three years?
- tedk-42 7y ago
  Containers will be around for at least another 5 years. If you look at where AWS makes most of their money, it's selling EC2 hardware.
  - 1337shadow 7y ago
    Containers have been around for decades in many forms (chroots, vserver ...) and will live for other decades because they are much more resource efficient than VMs while allowing immutable image deployments.
pas 7y ago
There's already serverless where you don't have to do anything with OS/servers/infra: PaaS, like Heroku. But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|
- scarface74 7y ago
  Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?
  - pas 7y ago
    Sure, it's not FaaS, but it fits the "you don't have to care for OS and servers" criteria, and it's always on (and auto-scalable). Running FaaS on AWS without knowing anything about servers and "OS stuff" screams like building the roof without the foundation. And I know that it sounds convenient to run everything as isolated little abstract functions, and ... it works, but it's pricey. But you can do it for cheap, you can deploy Kubless or OpenFaaS (or OpenWhisk or whatever is Apache's equivalent). Naturally AWS exploits this knowledge gap for a lot of their managed services.
    - scarface74 7y ago
      It’s not a “knowledge gap”. I know how to set up databases, queueing/messaging servers, software load balancers, etc., but maintenance takes time and companies pay to save time.
      - pas 7y ago
        That's true. And that's one of the things that a FaaS/PaaS gives you. Heroku's 24 time limit is perfect for eliminating the problems with starting the environment for each request, but still completely absolves the client from doing the grunt OS maintenance.
  - dragonwriter 7y ago
    > Heroku is not Serverless in the modern definition of the word Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.
hdra 7y ago
>The whole idea of serverless is so you don't have to manage infrastructure Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed. All in all, I can't really say Lambda is really all that "easy" considering options like AWS EB/ECS can be setup relatively easily.
- pbalau 7y ago
  > you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed. You know those url.py files in a django install? Those are the equivalent of ELB/APIGW thing. You don't manage those, you make them once. Not sure where you personally draw the line between app development and infra work, but for me "request that comes on this path, calls this function", either via ELB -> backend or APIGW -> lambda, or you know, whatever you use for your django app -> a function defined in a view.py, is app, not infra.
  - akhilcacharya 7y ago
    For the record, you can easily abstract that away or include it in your own code with frameworks like Chalice [0] [0] https://github.com/aws/chalice https://github.com/aws/chalice
- einaregilsson 7y ago
  There are definitely still things you need to think about with Lambda, like how much memory you want to allocate etc.
peterwwillis 7y ago
> The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. The reasons to use Serverless is the same as everything else in the cloud: 1) fast scaling, 2) sometimes it is cheaper depending on X, and finally 3) you don't have to think about where to run it.
- jrochkind1 7y ago
  > You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. You can consider it so theoretically, but for many teams, especially small teams, OS-level systems admin is a different skillset and non-trivial burden that they are glad to pay a premium for, which is why offerings like heroku are successful. It may work that way for you, but it definitely does not for many many teams. "You already have to walk to the store, so hiking the appalachian trail is just another part of your walking strategy" -- this is an exageration, the difference between walking to the store and hiking the trail is probably larger than adding OS-level maintenance, but it shows "you already have to do X so doing anything else that I can also call 'X' should be trivial" is a flawed form of analysis, it tells us nothing that you can call all of it "walking" or all of it "patching strategy".
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]
- coldtea 7y ago
  >If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. This is "you'll always have to do X, so might as well do 10x" argument...
scarface74 7y ago
Docker can also be serverless and gets rid of all the limitations of lambda - Fargate.
- dragonelite 7y ago
  I tried using google cloud run, with a rust web server. I think google only counts request processing time and rounds up to the nearest 100ms. All i had to do was provide a container with a web service that reads a environment variable to listen to a specific port.
  - snisarenko 7y ago
    I am considering using g cloud run for my next project. How did you like it ?
    - dragonelite 7y ago
      Too be honest it was really just a small project to get used with Actix web a rust web frame work and to setup a google cloud build ci/cd that would build a container i could host somewhere. I only used cloud run because i saw a youtube suggestion about it xD So there was no load except me and some friends pushing f5 a couple of times. You can create a web service in whatever language and framework you want, all you need to do is read a PORT environment variable for incoming messages. The freedom was really awesome, instead of being confined to supported languages and frameworks you get in the functions landscape. Only confinement was that you're pretty much limited to HTTP calls, unless that has changed. Personally i find the freedom of pick your own language and framework a big positive, and billing is finer on cloud run compared to AWS Fargate(rounded up to next sec) if im not mistaken. I do wish they would make billing even more finer instead of rounding up to the next 100 ms, rounding up to the next 10ms would be nicer when you use non GC or Runtimed languages, like Rust.
- mywittyname 7y ago
  Fargate is not a replacement for Lambda. While there's some capability overlap, each have their own respective niches.
skrebbel 7y ago
> I'm in the container camp Can anyone explain to me why there's "camps" to this debate?
- tedk-42 7y ago
  I'd say modern API deployments are either containerised or go the serverless route. On one hand you have a docker image with your source code/static binary baked in. The other you have your source code/binary encapsulated in a serverless framework (with an Event handler of sorts as your input). The container doesn't lock you into a particular ecosystem, but hasn't solved how you deploy and run your container (Heroku, managed k8s, AWS ECS/EKS/Fargate). Serverless on the other hand will give you a runtime for your API and allow you to go live (assuming you've setup an account or whatever). To migrate something that already works to serverless is a bad idea. Maybe if you're pretty comfortable with serverless frameworks and you like to hack a lot of projects up quickly, sure serverless might be a good fit. But why not instead start off with a container? At least you have the flexibility to run that on whatever you damn want - Even a t2.small instance with a docker daemon running.
  - inimino 7y ago
    What do you mean by "modern"? Expensive and poorly understood?
  - jacques_chester 7y ago
    Heroku gives you a runtime environment also, using Buildpacks. In that respect it's already "Serverless".
- inimino 7y ago
  Because most people with strong opinions aren't experienced enough to justify them from direct experience. Instead we have religions, tribal affiliations, camps.
ordinaryperson 7y ago
Exactly. Like anything, right tool for the right job. I was hosting my personal website on EC2 with an RDS instance and it cost around $20/month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 & Cloudfront: now my bill is $0.80/month. Another example: at work we inherited an old EC2 instance that was set up solely to run cron jobs on other servers. Occasionally it would lock up or go down, for whatever reason, creating chaos for the servers that needed specific jobs run frequently. We switched to AWS Lambda functions for those cron jobs and they've never failed once. If you're running a games website that gets pinged 24/7, don't use Serverless. But the notion that it's slow and overpriced is misguided if you're applying the wrong use case.
- ramraj07 7y ago
  How did you replace a site that needed rds with s3? Was it a blog that you moved to Jekyll or something?
  - edaemon 7y ago
    They may have used S3 Select: https://aws.amazon.com/blogs/aws/s3-glacier-select/ https://aws.amazon.com/blogs/aws/s3-glacier-select/
  - cdumler 7y ago
    If you are comfortable with React, look at GatsbyJS. It is pretty amazing what you can build into a static site.
  - stevehawk 7y ago
    most likely either Jekyll or Gatsby
  - Tenoke 7y ago
    S3 is just slower but in theory you can do everything you can with rds. So e.g. if the queries you are making aren't time sensitive or are easily cached switching to s3 can be okay.
- anteatersa 7y ago
rhizome 7y ago
The whole idea of serverless is so you don't have to manage infrastructure That's the selling point of AWS in general, but I wouldn't be surprised if (non-tiny) companies are still spending at least as much on AWS/etc. as they would on in-house infra. That is, they're paying for it anyway, and possibly at a premium.

lucasverra 7y ago

Agreed, let me add my 2cts : >The whole idea of serverless is so you don't have to manage infrastructure. ...when you are validating your product/market (100 request/day is a success here). Not everyone on HN is a core dev, tech is getting democratised. So 1 week of time dealing with servers and accounts and infra is a week not asking the right questions.

nirvdrum 7y ago
It really depends what you're doing. I've been trying out serverless on-and-off for weeks now and still don't have a basic two tier application going the way I want. I'd have been substantially better off dropping $5/month on a DigitalOcean droplet and running PostgreSQL and Rails on it. DigitalOcean even has really helpful templates to start up basic servers. This may be a specific criticism of AWS Amplify, but all I've been doing is trading off some arcane knowledge in open source software for arcane knowledge in some vendor-specific system. Most of my time has been spent searching for answers to Amazon-specific issues that haven't been solved in any of their SDKs. Or I wind up walking through their SDK code trying to figure out how to metaprogram my way around it. Perhaps if I used the web UI to stand everything up, it would have gone a lot smoother. I'll admit I'm a sucker for infrastructure as code. But, as it stands, I can't see how this really saves anyone any time. It's still an incredibly manual process without much in way of help or support the moment you veer off the one path Amazon has decided you should be on. (To make things more concrete, I still don't have Cognito working with optional TOTP 2FA. The withAuthenticator component apparently only renders the TOTP setup if 2FA is required. I've spent hours trying to work this one out, including spending time on the Amplify Gitter channel.)
- guitarbill 7y ago
  > DigitalOcean even has really helpful templates to start up basic servers. > I'll admit I'm a sucker for infrastructure as code. ... which you have to maintain, which probably means Ansible/Chef/Puppet/Salt/etc scripts. Which is fine, it's just a trade-off. I've spent weeks maintaining those kinds of things though, and inevitably when you come back in a year, something's broken. CloudFormation isn't great, but it usually gets the things provisioned - CF Cognito support sucks though, and haven't been impressed with Cognito at all. Seems too enterprise-y. Like e.g. CodeBuild, which supports 0 open-source use-cases. IDK what some of those teams are doing, but even Azure Pipelines is years ahead. I think that's a general problem with AWS at the moment. Too many sub-par offerings. Still worth it for S3, DynamoDB, SQS, and Lambda or EC2 (just, the EC2 UX is awful). And those are huge time savers.
  - nirvdrum 7y ago
    I guess my point is I'm going to have to maintain something, it's more useful for me to know how to maintain a PostgreSQL installation than it is some custom Amazon framework or tool. Serverless certainly hasn't been the "fire and forget" system I was sold on. And for just starting up, I can stage an Ubuntu server and set it to auto-update and really not have to touch it for quite a while. I happen to have extensive sysadmin experience and authored a reasonably popular provisioning tool, but I can appreciate not everyone wants to learn it. However, getting AppSync with its Velocity templates talking to DynamoDB and authenticating with Cognito requires quite a bit of knowledge as well. And time spent learning that only benefits you if you never leave the AWS ecosystem. I suppose I could look at Aurora instead, although Amplify only supports MySQL Aurora, so no luck with Postgres again. Likewise, the price advantage goes away. And now I'm stuck figuring out a wildly convoluted TCO calculator. I could look at another hosted DB solution, but now I either need to move everything to a new provider or find a way to deal with WAN latency for simple DB operations. Moving means learning yet even more otherwise useless knowledge about a single provider. I'm sure a lot of this is just growing pains. But as a lone dev just poking at something in his spare time, all these "get running in 30 min. or less" tutorials fall apart the moment you try to do something outside that tutorial. And the number of services available, their weird pricing structures, their implicit deficiencies and explicit limitations, just mean I'm still wasting time not building software :-/
james_s_tayler 7y ago
I think this is an important consideration that a lot of people miss. One of the trends of both serverless and containers it that compared to older models they are allowing smaller and smaller teams to do bigger and bigger things. So, in certain respects it's an enabler. Context always matters.
hdra 7y ago
Counterpoint to that though: "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. None of that is particularly "accessible" for someone trying to get running ASAP. I agree tech is getting democratised, but when talking about products that allows it, I'm thinking of products like Firebase or the recent darklang, not AWS Lambda. From all the Lambda usage that I've encountered so far, they are still very much in the domain of a "sysadmin".
- dragonwriter 7y ago
  > "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. You only have to setup security groups if you are running lambda's in a VPC, which in the simple case (e.g., not running a cloud extension of an internal corporate network) you probably don't. https://lumigo.io/blog/to-vpc-or-not-to-vpc-in-aws-lambda/ https://lumigo.io/blog/to-vpc-or-not-to-vpc-in-aws-lambda/ And, yeah, its a lot simpler than a traditional server setup without that. And even with it.
- lucasverra 7y ago
  Agreed, AWS lambda is still (very) scary. To me, serverless is more glitch.com [1] than AWS. When there is is no infra to deal with, U/DevX becomes much easier. "Remix this" is pure product joy [1]: https://glitch.com/~mapbox-demo https://glitch.com/~mapbox-demo
- ewidar 7y ago
  I've found https://github.com/Miserlou/Zappa https://github.com/Miserlou/Zappa to be super useful for simple Lambda deployments. It's only for python, but I am pretty sure you have other solutions for node, ruby...
  - kstrauser 7y ago
    We use http://apex.run/ http://apex.run/ but mainly because that’s what we started with and it hasn’t given us a reason to look around yet.
wolco 7y ago
Learning how to setup everything will be too much for you. Use Hostgator and you can start marketing immediately.

EwanToo 7y ago

If they had used an ALB instead of API Gateway, the cost might well have been a 2x increase, especially given that would replace the ELB they're already using. The ALB option has it's own caveats though...

einaregilsson 7y ago
Yeah, that would have been a much better fit. I just didn't know you could put ALB in front. (Also, a "load balancer" in front of serverless... , and yes I know load balancer do more than load balance.) I mainly went with API Gateway since that's the default setup the serverless framework uses.
- pojzon 7y ago
  For AWS it was november 2018 when it was annanced. Still a pretty new thing if you ask me. Many Cloud Architects still dont understand all pros and cons of this solution.
  - scarface74 7y ago
    One con is that using an application load balancer with lambda restricts you to 1MB requests (and responses?) as opposed to 10 with APIGW. Lambda itself has a 6Mb limit.
primitivesuave 7y ago
One frustrating caveat of the ALB approach is there is a hard 1 MB limit on both the request and response size, while APIGW has a hard 6 MB limit.

discordance 7y ago

>The whole idea of serverless is so you don't have to manage infrastructure That's one of the ideas. Serverless shines for burst-y traffic where the traffic timing is unknown. If I had known static high loads I wouldn't use serverless.

Jack000 7y ago
isn't that just a limitation of the current incarnation of serverless systems? ie. serverless is only effective for burst traffic because it's expensive. You would think that after you tailor the code to the platform and make it stateless, it would cost less for the cloud provider and not more.
- icebraining 7y ago
  If Amazon has to dedicate a full server permanently to your applications, I don't see why it would cost them more or less depending on the statelessness of your application.
  - jfoster 7y ago
    Are you sure your assumption that Amazon still has to dedicate a full server permanently to the application is correct?
    - icebraining 7y ago
      If you application, due to the requests it receives, consumes enough CPU time to occupy all the cores available in a server and/or most of its RAM, how can they not?
cuu508 7y ago
Bursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway & Lambda is significantly more expensive than the more traditional options.

ilimilku 7y ago

Exactly. This guy nails it. The serverless paradigm is a managed service, so you are paying extra for that management. Serverless also is built for automated connectivity within the AWS ecosystem, i.e. as a nerve center for all of AWS's nifty gizmos. This is why Amazon places such an emphasis on training certified solutions architects who know what works best for each situation.

sl1ck731 7y ago
Amazon puts emphasis on "certifying" solutions architects to turn them into marketing mouthpieces and AWS proponents. Source: Seen it happen, am certified.

dunk010 7y ago

> I'm in the container camp because serverless isn't cheap and you can't have long running processes. Do you think you'll have the same opinion in five years time? Or how about three years?

tedk-42 7y ago
Containers will be around for at least another 5 years. If you look at where AWS makes most of their money, it's selling EC2 hardware.
- 1337shadow 7y ago
  Containers have been around for decades in many forms (chroots, vserver ...) and will live for other decades because they are much more resource efficient than VMs while allowing immutable image deployments.

pas 7y ago

There's already serverless where you don't have to do anything with OS/servers/infra: PaaS, like Heroku. But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|

scarface74 7y ago
Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?
- pas 7y ago
  Sure, it's not FaaS, but it fits the "you don't have to care for OS and servers" criteria, and it's always on (and auto-scalable). Running FaaS on AWS without knowing anything about servers and "OS stuff" screams like building the roof without the foundation. And I know that it sounds convenient to run everything as isolated little abstract functions, and ... it works, but it's pricey. But you can do it for cheap, you can deploy Kubless or OpenFaaS (or OpenWhisk or whatever is Apache's equivalent). Naturally AWS exploits this knowledge gap for a lot of their managed services.
  - scarface74 7y ago
    It’s not a “knowledge gap”. I know how to set up databases, queueing/messaging servers, software load balancers, etc., but maintenance takes time and companies pay to save time.
    - pas 7y ago
      That's true. And that's one of the things that a FaaS/PaaS gives you. Heroku's 24 time limit is perfect for eliminating the problems with starting the environment for each request, but still completely absolves the client from doing the grunt OS maintenance.
- dragonwriter 7y ago
  > Heroku is not Serverless in the modern definition of the word Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.

hdra 7y ago

>The whole idea of serverless is so you don't have to manage infrastructure Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed. All in all, I can't really say Lambda is really all that "easy" considering options like AWS EB/ECS can be setup relatively easily.

pbalau 7y ago
> you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed. You know those url.py files in a django install? Those are the equivalent of ELB/APIGW thing. You don't manage those, you make them once. Not sure where you personally draw the line between app development and infra work, but for me "request that comes on this path, calls this function", either via ELB -> backend or APIGW -> lambda, or you know, whatever you use for your django app -> a function defined in a view.py, is app, not infra.
- akhilcacharya 7y ago
  For the record, you can easily abstract that away or include it in your own code with frameworks like Chalice [0] [0] https://github.com/aws/chalice https://github.com/aws/chalice
einaregilsson 7y ago
There are definitely still things you need to think about with Lambda, like how much memory you want to allocate etc.

peterwwillis 7y ago

> The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. The reasons to use Serverless is the same as everything else in the cloud: 1) fast scaling, 2) sometimes it is cheaper depending on X, and finally 3) you don't have to think about where to run it.

jrochkind1 7y ago
> You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. You can consider it so theoretically, but for many teams, especially small teams, OS-level systems admin is a different skillset and non-trivial burden that they are glad to pay a premium for, which is why offerings like heroku are successful. It may work that way for you, but it definitely does not for many many teams. "You already have to walk to the store, so hiking the appalachian trail is just another part of your walking strategy" -- this is an exageration, the difference between walking to the store and hiking the trail is probably larger than adding OS-level maintenance, but it shows "you already have to do X so doing anything else that I can also call 'X' should be trivial" is a flawed form of analysis, it tells us nothing that you can call all of it "walking" or all of it "patching strategy".
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
coldtea 7y ago
>If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. This is "you'll always have to do X, so might as well do 10x" argument...

scarface74 7y ago

Docker can also be serverless and gets rid of all the limitations of lambda - Fargate.

dragonelite 7y ago
I tried using google cloud run, with a rust web server. I think google only counts request processing time and rounds up to the nearest 100ms. All i had to do was provide a container with a web service that reads a environment variable to listen to a specific port.
- snisarenko 7y ago
  I am considering using g cloud run for my next project. How did you like it ?
  - dragonelite 7y ago
    Too be honest it was really just a small project to get used with Actix web a rust web frame work and to setup a google cloud build ci/cd that would build a container i could host somewhere. I only used cloud run because i saw a youtube suggestion about it xD So there was no load except me and some friends pushing f5 a couple of times. You can create a web service in whatever language and framework you want, all you need to do is read a PORT environment variable for incoming messages. The freedom was really awesome, instead of being confined to supported languages and frameworks you get in the functions landscape. Only confinement was that you're pretty much limited to HTTP calls, unless that has changed. Personally i find the freedom of pick your own language and framework a big positive, and billing is finer on cloud run compared to AWS Fargate(rounded up to next sec) if im not mistaken. I do wish they would make billing even more finer instead of rounding up to the next 100 ms, rounding up to the next 10ms would be nicer when you use non GC or Runtimed languages, like Rust.
mywittyname 7y ago
Fargate is not a replacement for Lambda. While there's some capability overlap, each have their own respective niches.

skrebbel 7y ago

> I'm in the container camp Can anyone explain to me why there's "camps" to this debate?

tedk-42 7y ago
I'd say modern API deployments are either containerised or go the serverless route. On one hand you have a docker image with your source code/static binary baked in. The other you have your source code/binary encapsulated in a serverless framework (with an Event handler of sorts as your input). The container doesn't lock you into a particular ecosystem, but hasn't solved how you deploy and run your container (Heroku, managed k8s, AWS ECS/EKS/Fargate). Serverless on the other hand will give you a runtime for your API and allow you to go live (assuming you've setup an account or whatever). To migrate something that already works to serverless is a bad idea. Maybe if you're pretty comfortable with serverless frameworks and you like to hack a lot of projects up quickly, sure serverless might be a good fit. But why not instead start off with a container? At least you have the flexibility to run that on whatever you damn want - Even a t2.small instance with a docker daemon running.
- inimino 7y ago
  What do you mean by "modern"? Expensive and poorly understood?
- jacques_chester 7y ago
  Heroku gives you a runtime environment also, using Buildpacks. In that respect it's already "Serverless".
inimino 7y ago
Because most people with strong opinions aren't experienced enough to justify them from direct experience. Instead we have religions, tribal affiliations, camps.

ordinaryperson 7y ago

Exactly. Like anything, right tool for the right job. I was hosting my personal website on EC2 with an RDS instance and it cost around $20/month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 & Cloudfront: now my bill is $0.80/month. Another example: at work we inherited an old EC2 instance that was set up solely to run cron jobs on other servers. Occasionally it would lock up or go down, for whatever reason, creating chaos for the servers that needed specific jobs run frequently. We switched to AWS Lambda functions for those cron jobs and they've never failed once. If you're running a games website that gets pinged 24/7, don't use Serverless. But the notion that it's slow and overpriced is misguided if you're applying the wrong use case.

ramraj07 7y ago
How did you replace a site that needed rds with s3? Was it a blog that you moved to Jekyll or something?
- edaemon 7y ago
  They may have used S3 Select: https://aws.amazon.com/blogs/aws/s3-glacier-select/ https://aws.amazon.com/blogs/aws/s3-glacier-select/
- cdumler 7y ago
  If you are comfortable with React, look at GatsbyJS. It is pretty amazing what you can build into a static site.
- stevehawk 7y ago
  most likely either Jekyll or Gatsby
- Tenoke 7y ago
  S3 is just slower but in theory you can do everything you can with rds. So e.g. if the queries you are making aren't time sensitive or are easily cached switching to s3 can be okay.
anteatersa 7y ago

rhizome 7y ago

The whole idea of serverless is so you don't have to manage infrastructure That's the selling point of AWS in general, but I wouldn't be surprised if (non-tiny) companies are still spending at least as much on AWS/etc. as they would on in-house infra. That is, they're paying for it anyway, and possibly at a premium.