I'm taking my Production-Ready Serverless workshop online! π₯³π We're running a 4-week workshop that take you through building a production-ready #serverless app from testing, deployment, security right through to observability. homeschool.dev/class/productiβ¦#aws#awslambda
The curriculum covers everything you need to know for building production-ready #serverless apps, and there's something for everyone, from novice to experienced #AWS and #AWSLambda users. And the content is up-to-date and relevant for 2020 and (hopefully) beyond.
Every week we release new video lectures and hands-on exercises on Monday. You can do them at your own pace and get help from us & other students on our Discord server. And on Friday, we'll do a live Q&A session to answer your most burning questions, not limited to the curriculum
I know you have a lot of options right now, with everything going online, but we hope our format would give you the best combination of self-paced studies and instructor-led courses where you can get more timely feedback on questions that go beyond the scope of the course.
I hope to see you in the workshop! even if you can't join us, we would very much appreciate it if you can help spread the word on social media and tell your friends and colleagues too πππ
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
One of the most misunderstood aspects of Lambda is how throttling applies to async invocations.
Or rather, how it doesn't!
π§΅
With Lambda's Invoke API, you can choose invocationType as "RequestResponse" (ie, sync) or "Event" (i.e. async).
With sync invocations, throttling limits are checked to make sure you stay within:
* regional concurrency limit
* the function's reserved concurrencydocs.aws.amazon.com/lambda/latest/β¦
However, this is not true for async invocations.
The Event Invoke Frontend service accepts the request and passes it onto an internal queue.
Concurrency limits are not checked at this point and are instead applied later when the internal poller attempts to invoke the function synchronously.
If you want to learn more about how Lambda works under the hood, make sure you watch @julian_wood's fantastic session from re:Invent 2022.
Like that scene in The Wolf of Wall Street where Di Caprio asked Jon Bernthal to sell him a pen.
First, create the demand, then supply the solution.
Sell the problem to the reader. Help them understand why itβs a problem worth solving.
If the readers are not interested in the problem you're solving, they won't care about whatever solution you propose, no matter how good the solution is.
Payload-based filtering was one of the key reasons to choose EventBridge over SNS. This makes SNS a much more viable option in Event-Driven Architecture.
This is a very interesting thread and the surrounding discussions. I've had similar discussions in the past, but I don't want to make too many assumptions here because I wasn't part of the conversation with the client.
First of all, serverless has been successfully adopted at a much bigger scale in other companies. LEGO for example have 26 squads working mostly with serverless, and PostNL has been all in on serverless since 2018.
So technology is probably not the problem.
From the clues I'm able to pick up, the team has given it a go but they faced tooling gaps when you have both serverful (RDS) and serverless components, and maybe needed help to navigate those hard edges and adapt their practices to work better with serverless
The "serviceful" mindset means you'll need to learn and use many services in your architecture. Having the right tool to help you along can make a world of difference. And here are 7 of my favourites.
Serverless IDE is a VSCode extension that will save you countless hours when you work with CloudFormation, AWS SAM or the Serverless Framework.
Auto-completion, schema validation, CF docs on hover, and many more.