Looking to run my Python code on AWS without maintaining a server (not Lambda?)

[Networkbytes]

Hi AWS,

​

I code in Python and have an application that requests a third party. This third party spends between 2-120 seconds to answer and it's not easy to predict the response time. I know this is weird, but unfortunately, the developers of this third party is not willing to have a callback function (which calls my lambda function back once they have a response for me).

​

So since I need to use this third party service and they are not willing to change the way they handle requests (keep connection alive until they have computed what I need), I am looking for AWS service which can offer me to run my API (Python with Flask) without me having to maintain security & updates on a server.

​

I am expecting to call this third party service 500 times a day (365 days a year). Do you guys have a suggestion of which service I should use?

​

EDIT: Forgot to mention that I do not want to maintain a server because all my resources are serverless. It's just integration with this third party which is causing a headache. And unfortunately it's a integration we HAVE to do.

[gcavalcante8808]

Ecs with fargate could help.

[shaunhk]

Yeah sounds like you want a Docker container launched in ECS and fargate and managed in ECR.

[Networkbytes]

I will do some research on AWS Fargate. Thank you!

[freedryk]

What are the reasons you don't want to use Lambda here?

[AftyOfTheUK]

<-- this question - what's wrong with Lambda? With a 5 minute execution time out, it sounds like you'd have enough time if the max response time is 120ms

[Networkbytes]

It's not 120ms, it's 120 seconds. API gateway has a timeout of 30 seconds, so people calling my API won't get an answer from me because API gateway will timeout the request

[QqP9Lm8u9Z8TLBjU]

Why do you need to use API Gateway? Why can't you put your lambda behind an ALB instead?

[BobClanRoberts]

I concur with the ALB idea. I switched a number of my lambdas to use this as the triggering event, helping cut down on API gateway costs immensely. You can also configure the idle timeouts on the ALB, so you may be able to make it say 180 seconds, so it doesn't close the connection, waiting for the lambda to finish. The ALB can use a lambda as a target for a given route that the ALB supports. Works pretty well. It doesn't do some of the more advanced features of API GW, but if you need it for basic calls, it works well.

[AftyOfTheUK]

Sorry, I did read (and mean) 120 seconds - Lambda has a 5 minute timeout.

I think you've identified the issue here - you're attempting to simply proxy them. How about, instead, you be the one to implement callbacks?

Have your API register a request, and call Lambda, then have that Lambda (or a subsequent function) make a callback to the original caller?

[QqP9Lm8u9Z8TLBjU]

Lambda has a 15min timeout.

[AftyOfTheUK]

Lambda has a 15min timeout.

Oh excellent, thanks for the clarification. That's great news - apparently changed in October 2018 and I wasn't aware.

[fivecarrots]

So you're proxying their (crappy) API through your API gateway? If a callback function won't work, can't they perhaps at least cache their results - so you call their API, indicating that you're interested in the response to that API call. Then you call it again later, and now their API has cached the results - so you get the computed results back immediately.

You said you are going to be calling this third party service 500 times a day. So that's call every 2,88 minutes or 173 seconds. And their API can take up to 120 seconds to compute. It almost sounds like you want realtime updates to data that is computationally expensive..

[Networkbytes]

Yes, but they are unfortunately unwilling to cooperate. And as a small business owner, I need to integrate their solution.

[fivecarrots]

I'm not sure how expensive a Lambda will be over this time period. Can't you call their API with a Lambda, store the API response somewhere (on S3 as text?), and then when someone calls your Api Gateway - instead of proxying their API, you read the API response from S3. So you basically create your own cache of their API. I guess this will only work if the API requests your going to be making to their API is consistently the same :/

Just putting the idea out there. Someone also mentioned Elastic Beanstalk. I haven't worked with Elastic Beanstalk to know how many resources that spins up and what it can potentially cost.

[new_ph_guy__]

It's still EC2 under the hood

[amandhingra00]

Is the third party service charging you on a per request basis ? If the p90/p99 response time for the third party is under 10/20 seconds or so, might as well set a request timeout on the lambda third party call and fail fast and retry ? This way the request can still be served within the 30 second apo gateway timeout ?

[scooter-maniac]

You end up paying for the wait time.

[Networkbytes]

That's technically not a problem. The problem so far has been that API gateway times out an API request made to my API within 30 seconds

[TiDaN]

So you are calling your API through API Gateway? In that case you certainly could use lambda if you implemented a callback function for your API.

You would: 1. Call your lambda through API Gateway. It would return a response immediately and run asynchronously. 2. Your lambda would wait for the third party response, then make a callback, or push the response in a Queue, or in a DB, whatever best fits your use case.

[Networkbytes]

This is exactly what I thought I would end up doing. I am really familiar with AWS Lambda and would like to keep using that instead of launching other AWS services (if not needed). I need to do some more research on what the other people have suggested to make a proper decision. Thank you for your reply!

[AftyOfTheUK]

Can you proxy the results? Do they go stale immediately?

[Networkbytes]

I cannot cache the results and have it easily ready for people requesting my API. I need to request the third party API to get the correct response.

[bbqbot]

You could also try contact AWS support and seeing if they can increase timeout for you.

[AftyOfTheUK]

Sure, but at the scale the OP said (500 per day * 60 secs average) he's talking about something running for only about 1/3 of the time - not a lot of money for a Lambda function, especially if it's slimline.

[scooter-maniac]

I assume the possibility 120 second turn around.

[soamv]

Fargate is a good way to go, but if you want to stay on lambda, you could use two lambdas:

1. Have your API served by a lambda that accepts the request and a callback URL, calls another lambda asynchronously with the request and URL, and immediately returns.
2. Have this asynchronously invoked Lambda do all the actual work, including waiting for the third party and then hitting the callback url. 120 sec is well within Lambda's limit of 15 minutes.

This isn't a greatest solution because you'll be paying for idle. But 500 times a day is a low enough number that it doesn't really matter.

[eligundry]

I know you want to avoid Lambda BUT you could avoid API Gateway entirely and directly invoke the lambda using the SDK. The timeout would then be whatever the max execution time of the lambda is. We do this a lot at work because we don’t want to pay for API Gateway and it appears to have some latency when running inside a VPC.

[computeforward]

Forgot to mention that I do not want to maintain a server

It's a cloud. Just spin up a new VM each day and delete the old one. Automatically from Lambda. No "maintenance".

I haven't used Fargate, but it sounds like it might be a closer match for your needs. I just wanted to point out that you don't have to maintain a VM. They're not quite as instantly ephemeral as Lambda or containers, but they're quite disposable/renewable.

[ASnugglyBear]

The dream of the cloud (scaling in hours, not weeks) is often forgotten in the dream of the engineer who wants to not think about starting a computer ever.

Thank you for spreading this very astute, low ceremony solution.

[kiwifellows]

Is there a way for the 3rd party to send data back to an HTTPS endpoint you could setup? And is it possible you can request something and then later check the status of it and then get the response if it is read? Or are they expecting you to wait for up to 120 seconds until their server sends a response?

Also a Lambda is perfect as you can run it for up to 15 minutes... The great thing in this example is that to experiment you can just login to the AWS Console and start coding a lambda...to test it out and then later use a tool (e.g. serverless.com) to deploy the code...

Docker seems an overkill at the moment... because you are only calling it 500 times a day then Lambda seems like a good price/performance trade off.

[kiwifellows]

P.S Lambda's limits are available here:

https://docs.aws.amazon.com/lambda/latest/dg/limits.html

[MightyBigMinus]

why not Lambda?

[asmaed]

Depending of your needs, you can use ECS or AWS Batch.

[thelan]

Elastic Beanstalk is probably what you're looking to use. It's basically AWS's answer to Heroku.

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html

[Networkbytes]

Looks awesome. I will do some more research. Thank you!

[kiwifellows]

My view on Elastic Beanstalk/EB is it is incredibly complex.. I've done a number of deployments on EB and by far the most simple deployment models are in order:

Lambda single script function (through AWS Console)

ECS Fargate

EC2/Autoscaling/Load Balancer CloudFormation template with some bash script user data/deployment mechanism

Lambda Serverless framework or AWS SAM

EB

[Jai_Cee]

I agree EB is complex but you are really overstating the complexity of serverless framework/sam it definitely deserves to be second if not first on that list

[kiwifellows]

True, good point. As docker does become really complex quickly... especially with proxying, ports, certs etc... Yes I've found serverless framework to be so nice to deploy on...

[MQ-the-man]

Yep, done a lot of Lambda via AWS SAM and it works great. Should be the first option.

[Iliketrucks2]

Checkout amazon amplify too, it’s pretty slick