11–20 of 140 posts
Unless they have made serious updates to the deployment workflow, feature set, and documentation I would not recommend building your products on it.
Listen folks - it's still a fantasy. Latency is still 5s on many requests = no deal. This has been going on for years. Would someone form AMZ please stand up? I suggest that the latency is 5s for the 'first call', then, subsequent calls are fast - and if you don't use your lambda for a minute or so, it goes back to having latency. I suggest maybe this has something to do with loading it into memory when it's used? Th…
stands up https://www.youtube.com/watch?v=eJO5HU_7_1w You're describing container re-use which is documented in the page here: http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduct... You could have cloud watch run the function every minute? Again, that won't guarantee that your function will be "hot". But it's a quick hack to potentially reduce the frequency of your slow initial start. That said customer feed…
I checked out the doc and didn't see any reference to latency or how to mitigate it, perhaps I'm missing something?
Listen - I'm a massive fan of AWS. We use some core services and are very happy.
I know you listen to customers - but I suggest that Lambda was probably designed for specific kind of services (maybe IT, admin, batch processing etc.) - I'm going to fathom that maybe 'people running web-sites' were top of mind? Again, purely speculation on my part.
But if you want people to seriously switch over - and they will - in droves - if you get it right, is to basically enable fairly responsive services that scale with a minimum of fuss, latency concerns included.
So - if I'm running a web-portal - and I have a customer pull some data to build a chart from somewhere - and I have a Lambda specifically geared for that microservice - then it needs to be quick.
There really should be no need to use other services to have to hack around the latency issue.
Surely - you can parameterize the feature if you want, and require users to set thresholds for how long Lambda's 'stay hot' (and forgive my crude metaphors), or how much throughput etc. - and you could even bill them based upon those parameters. As long as it's fairly concise and understandable.
Perhaps DynamoDB is a good example. We've used it before - and what we love about it is that as long as we design our data correctly we never have to worry. Bursts of traffic, etc. are generally handled well, it scales largely without concern. One poor limitation of that service is the requirement to indicate throughput thresholds, which is too bad, but beyond that, it's ideal.
Amazon Lambdas are basically the 'last piece' of the golden dream of cloud computing - the ability to develop a truly serverless, microserver-based infrastructure, and never have to worry about platforms again. As much as we love EC2s, we would drop them instantly and go to Lambdas if they worked well. (And it's been at least 18 months since we last experimented, BTW). There are tons of SMEs that would do the same - I don't think anyone who isn't directly in the business of tech, and is providing some other kind of consumer or business service, wants the pain of managing EC2s or servers. 'Elastic Beanstalk' etc. is a bandaid - it's not ideal.
Anyhow - Lambdas are very close to being a super great thing, more than that - transformational - if they could just cross that 'real world' usability threshold.
Again - if something has changed WRT latency, and there is something in those docs I'm missing, please let me know.
Listen folks - it's still a fantasy. Latency is still 5s on many requests = no deal. This has been going on for years. Would someone form AMZ please stand up? I suggest that the latency is 5s for the 'first call', then, subsequent calls are fast - and if you don't use your lambda for a minute or so, it goes back to having latency. I suggest maybe this has something to do with loading it into memory when it's used? Th…
Bare ec2: 15ms
Lambda via API Gateway: 276ms
[0]: http://prerender.cloud/lambda-latency [1]: https://news.ycombinator.com/item?id=12678011
Listen folks - it's still a fantasy. Latency is still 5s on many requests = no deal. This has been going on for years. Would someone form AMZ please stand up? I suggest that the latency is 5s for the 'first call', then, subsequent calls are fast - and if you don't use your lambda for a minute or so, it goes back to having latency. I suggest maybe this has something to do with loading it into memory when it's used? Th…
You break the entire model of an oversubscribed multi-tenant container system if you want every lambda hot all the time. If that's what you need...you need a server.
We want micro-services that are available as we need them, at any scale, and we never want to deal with a 'server' again.
"You break the entire model of an oversubscribed multi-tenant container system" - we don't care that much about how it's implemented, or what underlying model is used, as long as it is secure, robust, and reliable.
I love lambda's, but api gateway was far from mature the last time I used it (6 months ago). Unless they have made serious updates to the deployment workflow, feature set, and documentation I would not recommend building your products on it.
Earlier quoted context omitted.
You break the entire model of an oversubscribed multi-tenant container system if you want every lambda hot all the time. If that's what you need...you need a server.
"If that's what you need...you need a server." We want micro-services that are available as we need them, at any scale, and we never want to deal with a 'server' again. "You break the entire model of an oversubscribed multi-tenant container system" - we don't care that much about how it's implemented, or what underlying model is used, as long as it is secure, robust, and reliable.
Listen folks - it's still a fantasy. Latency is still 5s on many requests = no deal. This has been going on for years. Would someone form AMZ please stand up? I suggest that the latency is 5s for the 'first call', then, subsequent calls are fast - and if you don't use your lambda for a minute or so, it goes back to having latency. I suggest maybe this has something to do with loading it into memory when it's used? Th…
I measured the actual latency over the weekend [0] [1] Bare ec2: 15ms Lambda via API Gateway: 276ms [0]: http://prerender.cloud/lambda-latency [1]: https://news.ycombinator.com/item?id=12678011
I understand that Lambdas are 'relatively quick' when they are 'hot' - which is my crude metaphor for 'up and running'.
The issue is, if the Lambda has not been in use for some time (seconds, minutes?), then the 'first call' can have quite a bit of latency - often up to 5 seconds - which killed it for us.
There is no way we could reasonably deploy a service wherein customer would have to wait an additional 5 seconds for a reaction in most use cases.
So close, yet so far.
This was about 18 months ago.
If you have some data that addresses this specific artifact - then that would be great. Possibly things have changed in 18 months.
And I'm not a hater, to us AWS is the best thing since sliced bread.
Can you achieve competitive latency for web pages using API Gateway and Lambda?
I think acloud.guru is served through lambda. I think if you go the single page app route with S3 + cloudfront CDN + API gateway + lambda (so many words/things) you can deliver a really high quality product. You can also cache responses out via elasticache. It's not perfect but the development velocity and potential is really exciting.
Earlier quoted context omitted.
You break the entire model of an oversubscribed multi-tenant container system if you want every lambda hot all the time. If that's what you need...you need a server.
"If that's what you need...you need a server." We want micro-services that are available as we need them, at any scale, and we never want to deal with a 'server' again. "You break the entire model of an oversubscribed multi-tenant container system" - we don't care that much about how it's implemented, or what underlying model is used, as long as it is secure, robust, and reliable.
I'm going to argue that's currently unrealistic, but if you want someone to build something, tell them its impossible.
Clearly its not easy to build a system that'll run code on demand as fast as bare metal; accept the trade offs with the understanding why you're making them.