Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Introducing Provisioned Concurrency for Lambda Functions

aws.amazon.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#61

Post by macintux »

msftie wrote: post #10
macintux wrote: post #5

Request for anyone on the Lambda team who happens to read this: your API doesn’t appear to offer a way to retrieve the “last modified by” user when grabbing function metadata. Very unlike other AWS APIs and very annoying.

Which API specifically are you referring to (GetFuntionConfiguration ?), and which APIs are you comparing it against?

There are other oddities too. For example, to get a layer name from a lambda definition, the simplest/most robust process I can define:

1 Retrieve all layers with list_layers and index them by ARN

2 Retrieve all function metadata

3 For each function metadata item, extract all layer version ARNs

4 For each layer version ARN, call get_layer_version_by_arn

5 Extract the layer ARN from that result

6 Use that layer ARN to retrieve the name from the data we retrieved in step 1

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#62

Post by NathanKP »

scarface74 wrote: post #39
reilly3000 wrote: post #23

With Fargate Savings Plans and Spot Instances, the cost of running workloads on Fargate is getting substantially cheaper, and with the exception of extremely bursty workloads, much more consistently performant vs Lambda. The cost of provisioning Lambda capacity as well as paying for the compute time on that capacity means Fargate is even more appealing for high volume workloads. The new pricing page for lambda ("Exam…

I agree, but you don’t need to learn how to use a task-definition file. I would actually advise against it. You can create your entire Fargate environment with CloudFormation.

You can also create your entire Fargate environment in a couple lines of TypeScript / Python / Java code using the AWS Cloud Development Kit. The AWS CDK is a declarative SDK that generates and deploys CloudFormation on your behalf, while offering you prebuilt patterns for many common deployment architectures: https://docs.aws.amazon.com/cdk/latest/guide/ecs_example.htm...

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#63

Post by inopinatus »

WNWceAJ9R9Ezc4 wrote: post #57
inopinatus wrote: post #56

Earlier quoted context omitted.

I'm wondering how feasible it'd be to vary PC through the day. The pricing examples include using PC on a limited duty cycle, and billing is defined to start from the moment it's enabled (rather than from when it's ready), so it'd be reasonable to expect there's some level of certainty that the concurrency level is ready within a defined timeframe. What might that timeframe be, and to what level of certainty?

PC supports auto scaling. https://docs.aws.amazon.com/autoscaling/application/userguid...

Sure, but there are no actionable metrics re. response time.

The closest is a suggestion from prior documentation[1] that Lambda "can scale by an additional 500 instances each minute" for a given function, but that's phrased like a promotional claim, not a commitment or even an objective, and it's even unclear whether that's a floor, a ceiling, or some average measure. I wouldn't doubt that PC lives on the same control plane as Lambda's regular scaling, but assuming identical behaviour is unwise unless documented.

Guess I can suck-it-and-see.

[1] https://docs.aws.amazon.com/lambda/latest/dg/scaling.html

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#64

Post by scarface74 »

NathanKP wrote: post #62
scarface74 wrote: post #39

Earlier quoted context omitted.

I agree, but you don’t need to learn how to use a task-definition file. I would actually advise against it. You can create your entire Fargate environment with CloudFormation.

You can also create your entire Fargate environment in a couple lines of TypeScript / Python / Java code using the AWS Cloud Development Kit. The AWS CDK is a declarative SDK that generates and deploys CloudFormation on your behalf, while offering you prebuilt patterns for many common deployment architectures: https://docs.aws.amazon.com/cdk/latest/guide/ecs_example.htm...

That’s cool. I never played with CDK. One issue I had with using CloudFormation was that when I built the Docker file with a tag of :latest and then ran the CF Template, CloudFormation doesn’t perform any updates because the template didn’t change.

Luckily we use CodeBuild and Octopus Deploy. I was able to use the CodeBuild build number environment variable to tag the Docker container, to specify the Octopus build number and use an Octopus Deploy variable in the CF template to force unique and consistent tags.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#65

Post by bni »

NewLogic wrote: post #42

I'm still frustrated that Lambda can't have alias specific environmental variables. Aren't alias' supposed to be used for staging function versions through a release pipeline?

Alias is a super weird feature of AWS Lambda imho. We setup separate Lambdas for dev, test and prod instead, like Serverless Framework does it.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#66

Post by planetary_dust »

reilly3000 wrote: post #23

With Fargate Savings Plans and Spot Instances, the cost of running workloads on Fargate is getting substantially cheaper, and with the exception of extremely bursty workloads, much more consistently performant vs Lambda. The cost of provisioning Lambda capacity as well as paying for the compute time on that capacity means Fargate is even more appealing for high volume workloads. The new pricing page for lambda ("Exam…

It was mentioned today in the serverless leadership session that savings plan is coming to Lambda too.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#67

Post by efi-lumigo »

reilly3000 wrote: post #60
munns wrote: post #54

Earlier quoted context omitted.

Dollar to dollar comparisons are one way to compare these two technologies but it leaves a lot not covered. The application programming model varies greatly (socket/port vs. event). There's also a lot more that Lambda brings to the table in terms of monitoring, logging, etc that you'd need to do work yourself to enable. Fargate is a great product, but it doesn't completely remove all operational work to the degree th…

Agreed. For the vast majority of cases, a Lambda function is easier to ship and maintain, and most likely dramatically cheaper. I really only think the value of using Fargate kicks in compared to Lambda at around 5M+ invocations/month. YMMV based on workflow and workload.

You are comparing only the costs of running them, what about the cost of developers who build/debug/troubleshoot the container. As someone who is running both on Lambda and Fragate it's way harder to make things tick on Fargate

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#68

Post by msftie »

macintux wrote: post #61
msftie wrote: post #10

Earlier quoted context omitted.

Which API specifically are you referring to (GetFuntionConfiguration ?), and which APIs are you comparing it against?

There are other oddities too. For example, to get a layer name from a lambda definition, the simplest/most robust process I can define: 1 Retrieve all layers with list_layers and index them by ARN 2 Retrieve all function metadata 3 For each function metadata item, extract all layer version ARNs 4 For each layer version ARN, call get_layer_version_by_arn 5 Extract the layer ARN from that result 6 Use that layer ARN to…

Layer Name and Layer Arn (the Layer Version Arn without a version suffix) are interchangeable in APIs that require a Layer Name parameter. I understand that you're trying to extract the "LayerName" field returned in the API response in ListLayers, but you can do it more concisely.

If you just need the Layer Arn to call other APIs:

a) You could eliminate steps 1 and 6, and use the Layer Arn value from 5 to call APIs that require a layer name.

b) Alternatively, you could yourself chop off the version number from the Layer Version Arn string(s) in step 4, and skip the GetLayerVersionByArn call in step 5 all together.

If you explicitly require the name, not the Layer Arn:

c) You could parse it right out of the Layer Version Arn yourself.

When it comes to doing your own string manipulation for (b) or (c), there are many ways to skin a cat ... but you could use regex (the pattern is in the API documentation), or split on colons and index the second to last element in the array.

Is it useful to return the Layer Name in more APIs? What is your use-case?

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#70

Post by efi-lumigo »

nexuist wrote: post #7

I am a huge fan of serverless, and AWS as well. I also find it deeply ironic that their solution to cold starts is to keep the function running 24/7... Could I include openssh and Apache in my Lambda instance? Maybe run a Minecraft server? :P

Cold start is inherent to the Lambda model, trying fixing cold start will probably bend the model, there is no way around it
Post reply on HN