astuyvenberg

SST has a good guide for migration: https://docs.sst.dev/migrating/serverless-framework

Otherwise you might consider doing the same with CDK. As a last resort you can use CloudFormation's new import/export tools and manage the stacks with SAM.

It's really too bad, I'm sure a more reasonable pricing scheme (framework only?) would lead to more adoption, but I'm sure that revenue had been a huge challenge lately and it seems like that means it's the end of the road for the Serverless Framework until v3 is forked.

(disclosure: I worked there for a while)

I write about cloud minutia and generally focus on serverless. I try to focus on reproducible benchmarks and actionable advice. If you've wondered about the performance of AWS-SDK v2 or v3 in NodeJS, or weird edge case behaviors anywhere from Lambda to zip files, you may be interested.

There are limits to the number of functions per account, and number of resources per CloudFormation stack (etc); but within those parameters it's usually a good idea to use one function for a specific controller or action. This allows you to limit IAM permissions, configure memory/CPU, and define associated resources at a per-controller level.

I've rewatched it several times and love how they blend archival footage, interviews, and illustration to show the history of rock climbing.

So far I've ridden one very good path connecting a few suburbs to Boston (Minuteman Bike Trail, a rails to trails path). There are other paths, but they're combined with running/walking trails and generally not conducive to bicycle travel.

The bike lanes of nearby Somerville and Cambridge are okay, but still lacking in comparison with Minneapolis.

The comparison of bicycle infrastructure (and number of people cycling) is stark. Given how bad the vehicle traffic is in Boston, I expected lots of bike commuters.

But there's no cohesive bicycle infrastructure here. Protected lanes barely exist, and even when they do, they suddenly end - leaving you on the side of a busy road.

Maybe one day Boston can catch up.

- Serverless Framework. Write 5 lines of YAML and have an API endpoint that scales to infinity and back to zero. Still blows my mind. (I am biased though)

- Fullstory/real user monitoring/session replay tools. Such a clear way to see what someone was doing when they ran into a bug.

- Github Copilot. Still amazes me!

- QMK is second to none. With the moonlander specifically I can flash my keyboard from any OS with nothing but a browser and a paperclip.

- Tenting is easy, adjustable, and feels good to use. I liked the thumb cluster tenting (over the ergodox) because it felt more natural.

- Excellent build quality, wrist rests are comfy, and it's pretty portable (it's in my carryon bag right now).

- High quality switch and cap choices (mostly, the custom thumb buttons are obviously nonstandard. But I strongly disliked the rubber function key row of the advantage 2)

- I occasionally play FPS games, and like that I can disconnect the right half of the keyboard and gain more mousepad real estate.

Kinesis pros:

- Mainly the shape. I think the kinesis is probably the most natural device to type on. The moonlander is comfy, but I think the kinesis is still more natural overall. The sculpted key-well is ideal, IMHO.

Both keyboards have eliminated my carpal tunnel symptoms, so I don't have any issues recommending either. If you're going to travel with a keyboard, definitely get the moonlander. But I think from a pure ergonomic standpoint - the kinesis wins.

If I ever switch jobs and have a keyboard stipend, I'll purchase the Advantage 360 and write a full review. But I'm very happy with my present position :)

That said, I'm not sure I can justify another keyboard.

A couple thoughts occurred to me as I read the post:

- Lambda functions deployed using Docker images can be up to 10GB.[1] Would that change your math here? I'm curious what the tradeoff would be vs parallelizing more function executions searching smaller datasets on both cost and performance.

- Great notes on the anti-competitive nature of the current market. If there was an open standard on crawling, maybe we'd see more innovation here.

- Cool use of a bloom filter!

1. https://aws.amazon.com/blogs/compute/working-with-lambda-lay...

The concept of "the market" for engineering talent is far more nuanced and multifaceted than the nice x/y plots used to correlate compensation and experience (not meant as a criticism to the author at all).

On the contrary - I was an employee at Serverless Inc, working on the Serverless Framework for the last two years, we used this pattern extensively (and very successfully) in our open source repos.

You can even find an example here which provisions real live AWS infrastructure: https://github.com/serverless/dashboard-plugin/tree/master/i...

We used part of our enterprise SaaS product to provision temporary credentials via STS and an assumable role, and it works great. You could do the same thing with something like HC Vault.

For Lambda, S3, DynamoDB, the perpetual free tier means we've never paid to run our own tests. API Gateway isn't free (after 1 year), but it's still pennies per month. We've had several cases where tests stuck around a long time, but a billing alert and occasionally some CloudFormation stack cleanup takes care of that.

We still have offline unit tests which test business logic, but everything else runs against the cloud - even our development environments ship code straight to lambda.

The blog post in the parent comment lays out our experience and my thoughts, but because of the pretty generous free tier, I don't think we've ever paid a penny for a build/dev/test AWS account.

I try not to develop locally at all anymore. If you're looking for more practical advice, perhaps this will help: https://dev.to/aws-builders/developing-against-the-cloud-55o...

Where possible, I prefer to utilize short-term, pay-per-use infrastructure for development and testing.