5 ms·

Maybe tangential but how do people feel about implementing a typical RESTful database API in Lambda & API Gateway? Most of the prototypical examples of Lambda

by abalone 10y ago

Maybe tangential but how do people feel about implementing a typical RESTful database API in Lambda & API Gateway? Most of the prototypical examples of Lambda I see are for things like data processing pipelines. I know in theory Lambda should be able to handle just about any kind of request from a browser or mobile app short of a websocket connection, and Amazon does have some sample code and a brief case study on their site. But I'm wondering if it's really ready for this or if people have experiences going near-100% serverless for their apps.

vidar 10y ago
I would be very interested in the answer to this question. If it can surpass Flask in terms of simplicity in creating a simple REST API it would be a major milestone.
scrollaway 10y ago
I find it to be an antipattern. Lambda excels at taking in arbitrary amounts of long-running jobs and feeding you its output. For example: Upload a png image to convert it to jpg. Zip a directory of S3 objects. Etc. Lambda gets very costly and inconvenient when you're just taking in requests you could handle by a couple of load-balanced web servers. The whole "running a whole website on Lambda" craze does not actually yield any benefit and is more complex, harder to play with than a simple ec2 instance (which, with a good setup, needs very little "server" management at all). Also, API Gateway is just horribly inflexible imho.
- abalone 10y ago
  I've heard API Gateway is painful to configure but that frameworks like serverless.com help a lot. But I'm surprised to hear that Lambda gets costly. Is this from real experience or is it just theoretical? My impression was that Lambda saves you money by not having to pay for excess capacity. But I haven't done the math. I'll admit, it's also appealing to not even have to worry about configuring a web server cluster to scale up and down.
  - scrollaway 10y ago
    Lambda costs are two-fold: You have a set cost per API request as well as a cost per 100ms chunks of work. On top of this, you can't increase one of CPU or Memory allocation without increasing the other. This means if you're very memory-efficient and CPU-bound, you'll be eating extra runtime costs. You also kind of end up using the entire Amazon toolchain, which has costs embedded in every single bit of it. SNS, SQS, API Gateway, S3 requests, S3 network out, etc they all have costs. And here's the thing: Lambda has a ton of layering on top of it, which you wouldn't have in an EC2 environment where you have full control. You can't optimize Lambda, you can optimize EC2. My company is currently paying $4k/mo in Lambda costs, parsing log files in Python into XML and doing an S3 call at a peak of 40 requests / second. Back of the envelope, we can probably get this down to <$300/mo by overprovisioning a few m4.large instances. But now there's the question of having to manage a processing queue, reprocessing, etc so it's hard to tell how much would actually be saved. (On top of that, if a box goes down, that's a significant chunk of processing unable to be taken care of; with Lambda, that doesn't happen). All in all, has been excellent to us to get started, but there's a point where we definitely want to investigate a dedicated system we have full control of. Lack of Python 3 support was the #1 reason I wanted to do that, so now there's a bit less motivation - it's a lot of work. I'll certainly write a blog post about it if we decide to move our main processing off Lambda. Edit: This looks like it has a lot of interesting numbers. https://www.reddit.com/r/Python/comments/4hebys/cost_analysis_for_python_scripts_aws_ec2_vs_aws/ https://www.reddit.com/r/Python/comments/4hebys/cost_analysi...
    - Rapzid 10y ago
      What sort of logs and processing are you doing? Do you mean 40 log entries per second, or 40 calls against your log processing service/infrastructure?
      - scrollaway 10y ago
        ~40 500kb logs per second. The logs are Hearthstone games.
  - southpolesteve 10y ago
idbehold 10y ago
Uh, the API Gateway can't handle binary requests/responses very well and it certainly cannot handle multipart requests/responses. Additionally it has a 30 second timeout so I would say it's definitely not something you could just replace your hosted web server with completely yet.
- abalone 10y ago
  Looks like it does handle binary now, if not multipart yet.[1] Granted the 30 second timeout is a constraint, but how bad a constraint is it? Ideally long-running requests like that should be rearchitected to return fast and deliver the results asynchronously, right? The bigger problem I see is the lack of websockets support, which makes delivering async results harder. Supposedly AWS IoT does it but that seems like an even more exotic usage than implementing a REST service in Lambda. Basically I get that it's still early days and there are gaps here and there, but am wondering if it's actually an "antipattern" to use Lambda this way or just a little early. [1] https://aws.amazon.com/about-aws/whats-new/2016/11/binary-data-now-supported-by-api-gateway/ https://aws.amazon.com/about-aws/whats-new/2016/11/binary-da...
  - jkarneges 10y ago
    We did a write-up last year about combining our WebSocket gateway with a FaaS backend: http://blog.fanout.io/2016/09/29/serverless-websocket-chat/ http://blog.fanout.io/2016/09/29/serverless-websocket-chat/ The FaaS used in the article is Microcule, but the same approach should work with Lambda now that API Gateway supports binary.
  - idbehold 10y ago
    It handles binary, but not well. http://forum.serverless.com/t/returning-binary-data-jpg-from-lambda-via-api-gateway/796 http://forum.serverless.com/t/returning-binary-data-jpg-from... > Ideally long-running requests like that should be rearchitected to return fast and deliver the results asynchronously, right? Ideally for whom? I can't think of an engineer who wouldn't rather do a simple request/response. It's certainly cheaper than spending the money to keep a connection open longer than 30 seconds, but far from ideal.
andrewstuart 10y ago
I've built a complete web application that is entirely serverless except for the database - I have an instance running Postgres. This is because Postgres I the only database I want to use because it always meets my needs. Everything else is serverless however. My application has: -- AWS Cognito as the user management and auth -- AWS Cloudfront serving a Reactjs front end as static files -- AWS EC2 running Postgres as the database -- AWS Lambda Python functions for the back end -- AWS SES serverless email inbound and outbound processing -- AWS SQS for email processing coordination Oh I do in fact have another server which does spam checking of emails, PDF conversion of emails, text extraction of emails and parsing of emails - this works best on a server rather than serverless. The most interesting thing I found along the way is that the API gateway (which I liked a whole lot by the way, and found to be powerful and easy to configure) is completely unnecessary. My application simply directly calls the Lambda functions to get and set the data that it needs - dramatic simplification. Of further note is that I only have one Lambda function for the entire back end - this further reduces the need for layers of APIs and parameters. All my Python code goes into the one function which is structured as a complete application. An additional benefit of this is that AWS Lambda can be slow to first run a function unless it is "warm". If you have lots and lots of small Lambda functions then any given function is less likely to be warm. With everything in the one Lambda function, then all parts of my Lambda function are more likely to be warm. So no API gateway completely rips out an entire layer of complexity, and then only one single Lambda function rips out another layer of complexity. It's very nice to be able to write front end functions in ReactJS that just call the back end function that they need. Making changes means I just change the functions and don't need to fiddle with all sorts of REST API layers or anything to accommodate the change. I started with node.js as the Lambda back end but switched to Python because personally I find that Python with its synchronous programming model is much easier to reason about for back end stuff. I'm more than happy using ES2015 at the front end for ReactJS.
- derivagral 10y ago
  Is this a hobby project? What ballpark are your hosting costs? I left AWS for Heroku after they wanted over $50/mo for postgres+route53+ec2 small; if Heroku got expensive for me I'd hit something like Linode/DO before AWS at this point. As a reference, this is for non-revenue generating hobby sites/projects.
Rapzid 10y ago
I'm running/wrote a flask-restfull app on lambda via Serverless with the wsgi plugin behind API Gateway. Not a huge fan of Python, but it's all working well enough.
cddotdotslash 10y ago
We did this at CloudSploit. Our entire service is written using Lambda-based APIs behind the API Gateway. The biggest challenge at first was the cold boot times. If our API went un-pinged for more than five minutes the next request would take > 5 seconds (!). This was solved with a CloudWatch event that invokes the function every 4 seconds (which is silly in my mind, but it works). You can read more about our process here: https://blog.cloudsploit.com/we-made-the-whole-company-serverless-5a91c27cd8c4#.7zts1fh27 https://blog.cloudsploit.com/we-made-the-whole-company-serve...
southpolesteve 10y ago
If you go to www.bustle.com or www.romper.com you get a JS app server side rendered by AWS Lambda and delivered through API Gateway (CDN in front of that). We do 50+ million unique visitors a month. Our team is super happy with the result and our AWS bill is smaller than it was on EC2. Cost was not a motivating factor for the switch but it is nice when the bill goes down. It is most definitely ready. I gave a talk at Node Interactive last year that has some more detail https://www.youtube.com/watch?v=c4rvh_Iq6LE&index=2&list=PLfMzBWSH11xYaaHMalNKqcEurBH8LstB8 https://www.youtube.com/watch?v=c4rvh_Iq6LE&index=2&list=PLf...
- abalone 10y ago
  Very cool. At your scale have you noticed any problems with cold start latencies? I know cold starts are an issue when services have a lull in usage, and that you can work around it. But I'm curious whether cold starts also happen when there's a surge in demand and AWS needs to spin up more containers or whatever it uses to host Lambdas.
  - southpolesteve 10y ago
    We haven't seen any issues. Most of our latency critical functions are called a lot. We do get significant spikes in traffic but our CDN does handle some of that load.

by abalone 10y ago

vidar 10y ago

I would be very interested in the answer to this question. If it can surpass Flask in terms of simplicity in creating a simple REST API it would be a major milestone.

scrollaway 10y ago

I find it to be an antipattern. Lambda excels at taking in arbitrary amounts of long-running jobs and feeding you its output. For example: Upload a png image to convert it to jpg. Zip a directory of S3 objects. Etc. Lambda gets very costly and inconvenient when you're just taking in requests you could handle by a couple of load-balanced web servers. The whole "running a whole website on Lambda" craze does not actually yield any benefit and is more complex, harder to play with than a simple ec2 instance (which, with a good setup, needs very little "server" management at all). Also, API Gateway is just horribly inflexible imho.

abalone 10y ago
I've heard API Gateway is painful to configure but that frameworks like serverless.com help a lot. But I'm surprised to hear that Lambda gets costly. Is this from real experience or is it just theoretical? My impression was that Lambda saves you money by not having to pay for excess capacity. But I haven't done the math. I'll admit, it's also appealing to not even have to worry about configuring a web server cluster to scale up and down.
- scrollaway 10y ago
  Lambda costs are two-fold: You have a set cost per API request as well as a cost per 100ms chunks of work. On top of this, you can't increase one of CPU or Memory allocation without increasing the other. This means if you're very memory-efficient and CPU-bound, you'll be eating extra runtime costs. You also kind of end up using the entire Amazon toolchain, which has costs embedded in every single bit of it. SNS, SQS, API Gateway, S3 requests, S3 network out, etc they all have costs. And here's the thing: Lambda has a ton of layering on top of it, which you wouldn't have in an EC2 environment where you have full control. You can't optimize Lambda, you can optimize EC2. My company is currently paying $4k/mo in Lambda costs, parsing log files in Python into XML and doing an S3 call at a peak of 40 requests / second. Back of the envelope, we can probably get this down to <$300/mo by overprovisioning a few m4.large instances. But now there's the question of having to manage a processing queue, reprocessing, etc so it's hard to tell how much would actually be saved. (On top of that, if a box goes down, that's a significant chunk of processing unable to be taken care of; with Lambda, that doesn't happen). All in all, has been excellent to us to get started, but there's a point where we definitely want to investigate a dedicated system we have full control of. Lack of Python 3 support was the #1 reason I wanted to do that, so now there's a bit less motivation - it's a lot of work. I'll certainly write a blog post about it if we decide to move our main processing off Lambda. Edit: This looks like it has a lot of interesting numbers. https://www.reddit.com/r/Python/comments/4hebys/cost_analysis_for_python_scripts_aws_ec2_vs_aws/ https://www.reddit.com/r/Python/comments/4hebys/cost_analysi...
  - Rapzid 10y ago
    What sort of logs and processing are you doing? Do you mean 40 log entries per second, or 40 calls against your log processing service/infrastructure?
    - scrollaway 10y ago
      ~40 500kb logs per second. The logs are Hearthstone games.
- southpolesteve 10y ago

idbehold 10y ago

Uh, the API Gateway can't handle binary requests/responses very well and it certainly cannot handle multipart requests/responses. Additionally it has a 30 second timeout so I would say it's definitely not something you could just replace your hosted web server with completely yet.

abalone 10y ago
Looks like it does handle binary now, if not multipart yet.[1] Granted the 30 second timeout is a constraint, but how bad a constraint is it? Ideally long-running requests like that should be rearchitected to return fast and deliver the results asynchronously, right? The bigger problem I see is the lack of websockets support, which makes delivering async results harder. Supposedly AWS IoT does it but that seems like an even more exotic usage than implementing a REST service in Lambda. Basically I get that it's still early days and there are gaps here and there, but am wondering if it's actually an "antipattern" to use Lambda this way or just a little early. [1] https://aws.amazon.com/about-aws/whats-new/2016/11/binary-data-now-supported-by-api-gateway/ https://aws.amazon.com/about-aws/whats-new/2016/11/binary-da...
- jkarneges 10y ago
  We did a write-up last year about combining our WebSocket gateway with a FaaS backend: http://blog.fanout.io/2016/09/29/serverless-websocket-chat/ http://blog.fanout.io/2016/09/29/serverless-websocket-chat/ The FaaS used in the article is Microcule, but the same approach should work with Lambda now that API Gateway supports binary.
- idbehold 10y ago
  It handles binary, but not well. http://forum.serverless.com/t/returning-binary-data-jpg-from-lambda-via-api-gateway/796 http://forum.serverless.com/t/returning-binary-data-jpg-from... > Ideally long-running requests like that should be rearchitected to return fast and deliver the results asynchronously, right? Ideally for whom? I can't think of an engineer who wouldn't rather do a simple request/response. It's certainly cheaper than spending the money to keep a connection open longer than 30 seconds, but far from ideal.

andrewstuart 10y ago

I've built a complete web application that is entirely serverless except for the database - I have an instance running Postgres. This is because Postgres I the only database I want to use because it always meets my needs. Everything else is serverless however. My application has: -- AWS Cognito as the user management and auth -- AWS Cloudfront serving a Reactjs front end as static files -- AWS EC2 running Postgres as the database -- AWS Lambda Python functions for the back end -- AWS SES serverless email inbound and outbound processing -- AWS SQS for email processing coordination Oh I do in fact have another server which does spam checking of emails, PDF conversion of emails, text extraction of emails and parsing of emails - this works best on a server rather than serverless. The most interesting thing I found along the way is that the API gateway (which I liked a whole lot by the way, and found to be powerful and easy to configure) is completely unnecessary. My application simply directly calls the Lambda functions to get and set the data that it needs - dramatic simplification. Of further note is that I only have one Lambda function for the entire back end - this further reduces the need for layers of APIs and parameters. All my Python code goes into the one function which is structured as a complete application. An additional benefit of this is that AWS Lambda can be slow to first run a function unless it is "warm". If you have lots and lots of small Lambda functions then any given function is less likely to be warm. With everything in the one Lambda function, then all parts of my Lambda function are more likely to be warm. So no API gateway completely rips out an entire layer of complexity, and then only one single Lambda function rips out another layer of complexity. It's very nice to be able to write front end functions in ReactJS that just call the back end function that they need. Making changes means I just change the functions and don't need to fiddle with all sorts of REST API layers or anything to accommodate the change. I started with node.js as the Lambda back end but switched to Python because personally I find that Python with its synchronous programming model is much easier to reason about for back end stuff. I'm more than happy using ES2015 at the front end for ReactJS.

derivagral 10y ago
Is this a hobby project? What ballpark are your hosting costs? I left AWS for Heroku after they wanted over $50/mo for postgres+route53+ec2 small; if Heroku got expensive for me I'd hit something like Linode/DO before AWS at this point. As a reference, this is for non-revenue generating hobby sites/projects.

Rapzid 10y ago

I'm running/wrote a flask-restfull app on lambda via Serverless with the wsgi plugin behind API Gateway. Not a huge fan of Python, but it's all working well enough.

cddotdotslash 10y ago

We did this at CloudSploit. Our entire service is written using Lambda-based APIs behind the API Gateway. The biggest challenge at first was the cold boot times. If our API went un-pinged for more than five minutes the next request would take > 5 seconds (!). This was solved with a CloudWatch event that invokes the function every 4 seconds (which is silly in my mind, but it works). You can read more about our process here: https://blog.cloudsploit.com/we-made-the-whole-company-serverless-5a91c27cd8c4#.7zts1fh27 https://blog.cloudsploit.com/we-made-the-whole-company-serve...

southpolesteve 10y ago

If you go to www.bustle.com or www.romper.com you get a JS app server side rendered by AWS Lambda and delivered through API Gateway (CDN in front of that). We do 50+ million unique visitors a month. Our team is super happy with the result and our AWS bill is smaller than it was on EC2. Cost was not a motivating factor for the switch but it is nice when the bill goes down. It is most definitely ready. I gave a talk at Node Interactive last year that has some more detail https://www.youtube.com/watch?v=c4rvh_Iq6LE&index=2&list=PLfMzBWSH11xYaaHMalNKqcEurBH8LstB8 https://www.youtube.com/watch?v=c4rvh_Iq6LE&index=2&list=PLf...

abalone 10y ago
Very cool. At your scale have you noticed any problems with cold start latencies? I know cold starts are an issue when services have a lull in usage, and that you can work around it. But I'm curious whether cold starts also happen when there's a surge in demand and AWS needs to spin up more containers or whatever it uses to host Lambdas.
- southpolesteve 10y ago
  We haven't seen any issues. Most of our latency critical functions are called a lot. We do get significant spikes in traffic but our CDN does handle some of that load.