munns

Yes.

But being real, we hear you on this one. I can't comment on API Gateway's roadmap here but this is something both teams is aware of. The reason it is the way it is today is for a valid reason. But this is def something we hear pretty often.

- Chris

Except that none of the rest of your infrastructure is there, and that APIs represent just a non-majority part of Lambda workloads.

Today, for a nonstop workload you might save money with Fargate or ECS.

Hey everyone, we're really excited about this feature launch, and I wanted to come in to clarify any misconceptions.

With this capability you can now package Lambda functions using familiar container image tools (Dockerfile, cli tools, build systems) but you still need to code them for the event model, have a handler, etc.

It's a big improvement, but its not "run any container in Lambda".

Either way, hope you go and try it out and we'd love feedback on how it can be better.

- Chris Munns, Lead of Dev Advocacy - Serverless@AWS

Awesome! That was the idea here. Lots of sub 100ms workloads and we really want you to be able to pay for what you use.

- Chris, Serverless@AWS

A lot of this was based around the fact that we've seen languages become just so much more performant. This includes Go/Rust/etc, but a lot of Node.js workloads are also sub 100ms, or fast enough that they'd benefit from this pretty well.

- Chris, Serverless@AWS

You are billed by the execution time of the function. So from the millisecond we hand the event over to you until you return a response or timeout.

- Chris - Serverless@AWS

How long would you like it to be?

Chris Munns - Lead of Dev Advocacy for Serverless@AWS

This is however a soft-limit per region

Thank you for clarifying! I know quite a lot has supposedly shifted. Will update my original comment.

Fwiw: Slack, Lift, AirBnb, Snapchat, Stripe are all 100% public cloud based (in so far as I know). So up through 8+ figures they are still doing it too.

removed Uber as its not 100% cloud (or at least wasn't in the past)

On your own metal it looks like it does in this post.

With managed services it looks a world different.

As the original creator of the presentation referenced by the blog author (later re-delivered by Joel in the linked post) I am super excited to see this still have an impact on people, but I'd say today in 2019 you'd probably do things very differently(as others call out).

Tech has progressed really far and there are tools like Netlify for hosting that would replace 90% of the non-DB parts of this. Cloud providers have also grown drastically and so again a lot of this would/could look a lot lot different.

Fwiw original deck from Spring of 2013, delivered at a VC event and then went on to be the most viewed/shared deck on Slidehare for a bit: https://www.slideshare.net/AmazonWebServices/scaling-on-aws-...

thanks, - munns@AWS

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 that Lambda does.

We've just published a second post on this launch: https://aws.amazon.com/blogs/compute/new-for-aws-lambda-pred...

Fwiw new networking for VPC is completely rolled out for all public regions now. (#2) (and thank you, its called "Attached to a VPC" and not in :) )

This covers you straight through 4.

Now it's possible that your execution environment could be sitting for sometime waiting for any action and so pre-handler DB connections and things like that might need to be tweaked in this model.

Thanks, - munns

Hey all, I lead developer advocacy for serverless at AWS and was part of this product launch since we started thinking about it(quite some time ago I should say). I'm running around re:Invent this week, but will try and pop in and answer any questions I can.

Provisioned Concurrency (PC) is an interesting feature for us as we've gotten so much feedback over the years about the pain point of the service over head leading to your code execution (the cold start). With PC we basically end up removing most of that service overhead by pre-spinning up execution environments.

This feature is really for folks with interactive, super latency sensitive workloads. This will bring any overhead from our side down to sub 100ms. Realistically not every workload needs this, so don't feel like you need this to have well performing functions. There are still a lot of thing you need to do in your code as well as knobs like memory which impact function perf.

- Chris Munns - https://twitter.com/chrismunns

Miles and I know each other, what's wrong with a friendly hug?

Do you need a hug hesburg?

No. I've been at AWS for over 7 years in a few different roles. Came to the serverless space >2.5 years ago because I felt passionate about it (could have literally done almost anything). Again, sorry for mis-posting under my older personal account, it was rarely used fwiw.

Hug back at ya big guy!

Yup! Haven't done it in years and created this different account to be more clear/direct in who I am. That is also why I called it out at the start and bottom of all my responses.

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

The issue of the application artifact size is definitely real and it blocks some NLP/ML workloads for sure. Consider that a today problem that isn't hard in Lambda.

But we've 100% got customers doing near realtime streaming analytics in complicated pipelines feeding off of things like Kinesis Data Streams. This FINRA example is one datapoint: https://aws.amazon.com/solutions/case-studies/finra-data-val... and this Thompson Reuters one: https://aws.amazon.com/solutions/case-studies/thomson-reuter...

These are nontrivial and business critical workloads.

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

edit:

-------------------------------------

Missosoup i see you making changes to your comment and it greatly changes the tone/context. i won't adjust my own reply in suit but leave it as it was for your original comments on this.

and I totally posted this from the wrong account... sigh.. this is me. Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

and I totally posted this from the wrong account... sigh..

this is me. Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

Amazonian who has lived in Manhattan the past decade. The two neighborhoods I've lived in over the past 5 years have seen 20-30% increases: Chelsea and Upper East Side. Not sure that folks are seeing minor in Brooklyn either.

+1 on this. The paper doesn't really address the most typical usecases of Serverless which are typically API backends, streaming data processing (feeding off Kinesis/Kafka/similar), and reactions to one off-ish events like object uploads to storage or events from other systems. While folks like those building Pywren have found success with highly parallel workloads, FaaS still isn't the typical way people go after distributed computing workloads, and no one from the vendor side is pushing this. - munns - Lead Dev Advocate - AWS Serverless

I wrote the first version of this deck back in 2013: https://www.slideshare.net/AmazonWebServices/scaling-on-aws-... and it since then went on to become one of the most delivered talks by AWS across the world. I thought I'd pop into this thread and answer some questions/help provide guidance as to why it exists. Note that first deck was mostly tossed together while on an Amtrak from NYC to Philly in an early morning, so excuse the typos and graphics glitches.

Generally speaking we've/I've seen a number of customers struggle with pre-optimization of their infrastructure and/or just not knowing what they should think about and when, when it comes to scale and architecture patterns. Think of this deck as an 80/20 rule for the most general and basic of people. Also, 2013 was a very very different world in the cloud and in infrastructure than today.

This deck was all pre-Docker/k8s, pre-Lambda/FaaS, pre-alot-of-cool-db-tech. However as a general starting point a lot of it still holds just fine. You should probably start with a relational DB if you have a more traditional background using them. You probably don't need autoscaling Day 1 (but it's nice via things like ElasticBeanstalk).

Someone commented that metrics/logging/monitoring is a Day 0 thing, and it absolutely is, but it is the kind of thing most companies skimp out on until very late in the game. Not pushing for excellence in this area will block you from success down the line. The same is hiring someone with dedicated Ops/SRE responsibilities, and/or making sure someone on the team has the right experience in that space.

DB growth/scaling is now a lot more transparent than it used to be, but I still see people doing less than ideal things with them. This is an area the industry needs to be sharing more best practices on (while still respecting some of the best practices from decades of SQL).

On costs; today some of the biggest sites in the world run on a public cloud. They do that for many reasons, but cost effectiveness at scale is pretty well proven when measured the right way. Most math ignores people and opportunity cost and that's what get's you more than metal and power. There is also now today the wealth of managed services that equate to replacement of people with a returned value greater than the people cost (essentially the ROI on managed services outpaces the value of you doing it yourself greatly). The SaaS ecosystem is also vastly larger than it was in 2013. I hope to never run a logging cluster, monitoring systems, backup tools, etc, myself again.

Anyway, glad to see this deck still kicks around and that people are discussing it. Happy to try and answer more questions on this. - munns@

Roger that! Thanks!

hi! yes there will be support in SAM CLI that when you do local testing referring against a Layer it will pull it down for you. - Chris, Serverless @ AWS

You could do that, it's true, and folks did that with node.js to shim Go before Lambda had official Go support. But being able to just create/use/share a custom runtime inside of an organization will be easier for them overtime vs. the shim method. - Chris from Serverless@AWS.