โข Fan-in & Fan-out
โข Simple Web Service
โข Publish/Subscribe
โข Strangler
โข Aggregator
{ 1/7 }
๐๐ฎ๐ป-๐ถ๐ป & ๐๐ฎ๐ป-๐ผ๐๐
Common problem: large tasks that are exceeding Lambda's execution time limit
With Fan-out, you're splitting those large tasks into small ones and delegating those to Lambda workers.
Afterward, results are aggregated (= Fan-in).
Mostly you don't want to couple services via synchronous calls, but rather let them interact via events.
If an event gets published, other services can respond.
The initiating system & the consuming ones can grow independently.
{ 4/7 }
๐ฆ๐๐ฟ๐ฎ๐ป๐ด๐น๐ฒ๐ฟ
Migrating legacy systems is a difficult task - generally, you can just switch everything in one step, but slowly move to the new system.
That's why you can rely on a facade that decides where to route to - the legacy app & the new one.
{ 5/7 }
๐๐ด๐ด๐ฟ๐ฒ๐ด๐ฎ๐๐ผ๐ฟ
If an operation needs to fulfill a set of subtasks - often there are also a lot of 3rd parties involved.
As latencies of external calls significantly impact the operations performance, it's advisable to build a centralized aggregator service.
{ 6/7 }
It will split up necessities and process all requests to downstream third parties.
It will also collect and temporarily store results and finally aggregate them to return them in a single final response.
{ 7/7 }
There are a lot more patterns to explore - mostly someone that helps you to achieve your goals more easily!
All of them are field-tested and will do well against most DIY approaches ๐
Check out if there are weak points in your architecture with Dashbird's Well-Architected Lens ๐
It analyses the ๐๐ฒ๐ฐ๐๐ฟ๐ถ๐๐, ๐ฒ๐ณ๐ณ๐ถ๐ฐ๐ถ๐ฒ๐ป๐ฐ๐ & ๐ฟ๐ฒ๐น๐ถ๐ฎ๐ฏ๐ถ๐น๐ถ๐๐ of your serverless apps.
If you want to read more about the shown and more great patterns, you have to read ๐ฆ๐ฒ๐ฟ๐๐ฒ๐ฟ๐น๐ฒ๐๐ ๐๐ฟ๐ฐ๐ต๐ถ๐๐ฒ๐ฐ๐๐๐ฟ๐ฎ๐น ๐ฃ๐ฎ๐๐๐ฒ๐ฟ๐ป๐ by Eduardo Romero (@foxteck) on Medium.
๐๐ฒ๐'๐ ๐ฏ๐ฒ ๐ต๐ผ๐ป๐ฒ๐๐: generally, debugging is not a fun task ๐คข
Especially for serverless, event-driven & distributed systems.
From Lambda's logging basics to ๐๐ฎ๐๐ถ๐ป๐ด ๐๐ถ๐บ๐ฒ & ๐ป๐ฒ๐ฟ๐๐ฒ๐ โ
Lambda's a serverless technology provided by AWS.
But that ๐ฑ๐ผ๐ฒ๐๐ป'๐ ๐บ๐ฒ๐ฎ๐ป that there are no servers.
In the background, there are countless micro-containers running on top of the traditional servers.
Where do all the logs of those containers go to?
By default, they will end up in CloudWatch.
Every Lambda will receive its own ๐น๐ผ๐ด ๐ด๐ฟ๐ผ๐๐ฝ.
Like a repository for logs.
Not only that, every micro-container will create a new so-called ๐น๐ผ๐ด ๐๐๐ฟ๐ฒ๐ฎ๐บ.
Think of it as a text file where logs are written to.
It's managed, highly available & scales on-demand with low latencies.
For getting you hooked, at Prime Days 2021 DynamoDB served ๐ด๐ต.๐ฎ ๐บ๐ถ๐น๐น๐ถ๐ผ๐ป ๐ฟ๐ฒ๐พ๐๐ฒ๐๐๐/๐๐ฒ๐ฐ๐ผ๐ป๐ฑ at its peak.
I'm still in the early stages & already got a lot of lessons learned โ
๐๐ฎ๐๐ป๐ฐ๐ต ๐ฒ๐ฎ๐ฟ๐น๐
Maybe you've got another dozen ideas for features you think are needed for your MVP.
But until you've launched and you've got actual (paying) users, you've got no guarantee that your business case is even valid.
Intersects with the previous point: don't make the shinest code, with 100% code coverage and the perfect architecture, as it requires way too much effort.
Don't over or underdo it.
Make it work & manageable.