munns

from the post: Combining Cloudflare Workers, Hyperdrive, and PlanetScale relational databases allows you to build modern globally distributed applications without worrying about database connection limits or latency. Your Workers run globally at the edge, Hyperdrive provides intelligent connection pooling and caching, and PlanetScale delivers ultra fast and reliable databases for both Postgres and MySQL/Vitess.

Thanks for that callout, absolutely right. Fixed!

IN a direct reply to Op: There is definitely a lot that goes into learning serverless tech like AWS Lambda.

I lead Developer Advocacy for Serverless at AWS and we're constantly looking at ways to help streamline and simplify this process for you. You can find a lot of information on a site we've launched to rollup lots of resources: https://serverlessland.com .

Right now the best dev process is a mix of using local emulation via AWS SAM CLI (http://s12d.com/sam) or tools like localstack. But it's true that you'll never be able to completely mimic all the various services and their functionality.

Would love to know more of what left you feeling underwhelmed by SAM. It has almost all the functionality of CloudFormation, which is quite a lot.

Thanks, - Chris Munns - Lead of Serverless DA @ AWS

It was a long day yesterday, thank you :)

Same as Lambda has before. The state you have is most likely short lived as we reap worker environments every so often, but in-between invokes you could persist some data in memory or tmp space.

Awesome, thanks for sharing this.

::waves at Yuri::

Thanks! It's been a fun/interesting 4 years in this space :)

There's no impact of this feature to how you invoke your Lambda functions.

No good way to do this today. You are right in that you'd be forcing cold-starts. You could use a Lambda Extension to provide some sort of after-processing clean up of vars or /tmp space.. but thats hypothetical I haven't seen anyone do that yet.

Yes, but you deploy it from one region.

This is all based on how the RunTime API worked already (pre-dates this launch by 2 years or so). We wanted to not change too many bits.

Since function code has no listening socket/port as it were you need something (like the bootstrap script in a custom RunTime) to pull the local interface for the runtime API. That runs on the underlying worker and communicates with the API for Lambda.

Thanks! Appreciate the feedback and hope this helps you out. Let us know if it doesn't :)

- Chris

That is not at all what my words say and I won't reply to that thread which was started by a former competitor to troll this convo today.

The perceived lock-in is really no different than consuming other technologies. You make a trade-off on what you want to manage vs. handoff to a managed service. For many customers the benefits are well worth it.

It's fine that Lambda wasn't for you, but you aren't being clear here about what issues you saw, just waving the lock-in boogey man so many misunderstand.

There's a few things at play. Functions will still stay warm inbetween invocations and will keep local any data already in the worker. We also maintain a couple different levels of cache so as to not hit ECR often.

I know we've got a few blog posts coming out over the next couple weeks on this new feature, and each tells a few bits and pieces about the story.

Depending on volume you'll probably find that Lambda will be cheaper for that workload, especially with the new 1ms billing.

- Chris - Serverless@AWS

thar be dragons :)

Enough that in 2019 it was the most popular topic at re:Invent (our big user conference) and that today per our re:Invent announcement almost half of all new compute workloads in Amazon are based on it. Pretty heavily used across different industries and verticals.

The naming is a bit of a misnomer, today L@E doesn't run at the edge (in our PoPs) but when you deploy it copies to every region and then CloudFront routes you to the lowest latency region for your request.

Yes, either those docs will ship today or sometime this week. They are doing everything in batches but I've seen the SAM support pre-launch (which would require it).

- Chris

It me.

Interesting. Not possible today. We'd still encourage paralyzation up through multiple concurrency of functions being executed.

Yes, you are still limited to 15 minute maximum duration.

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

Yes, to be clear this change was just for Lambda. L@E is honestly a completely different service run by a different part of AWS that just happens to share parts of our core worker platform. I am not 100% aware of when they might adjust their own pricing on this, but also couldn't share any roadmap here (sorry).

Thats me. We've got some fun things we do behind the scenes to keep Lambda container image support snappy. SO yes, up to 10gb artifacts with container image support.

Yes, announced today you can go up to 10gb/6 vCPUs: https://aws.amazon.com/blogs/aws/new-for-aws-lambda-function...

Not entirely. This is something we've been thinking about for years now and is really about tooling and developer workflow. That is where the biggest benefit is for this.

- Chris - Serverless@AWS

Yeah, this is Day 1 for this and I think we've got a bunch of ideas to make it easier in the future. Most importantly we're looking for feedback just like this!

Thanks, - Chris

1. Sorry you are disappointed by this. 2. This is why I wanted to post here, to make it really clear. Andy only got to spend a few seconds on this and couldn't get into all the nuances. The launch post does, and we'll have more posts over the next 3 weeks just on this topic.

Containerization solves a few things. One big one was the container image as a packaging model. As customers struggle with dependency management or installing native packages (RPMs) we're basically faced with reinvent Dockerfile... or just use Dockerfile. This is an over simplification of what's happening, but that was the initial spark of this, many many cycles ago.

I think this is still going to be really valuable for folks, but what you are looking for already exists I'd say, and is Fargate.

Btw, ppl shouldn't be downvoting this, its all very valid.

- Chris, Serverless@AWS

Couldn't share future roadmap here, but these are some cool ideas :)

+1.

That's the idea. Run any container in Fargate. Now use the same tools you use to build/package those containers in Lambda.

No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think. They aren't brought up in any of the convos I have with customers.