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.
It's by far the best client for DynamoDB, and makes it easy to manage tables across accounts & regions, plus tools for data modelling and importing/exporting data too.
I love the guided workflows for creating event patterns and input transformers, and it has a unique ability to replay archived events in ORDER (btw, #awswishlist for this to be part of the service)
I have written ~800 technical articles/whitepapers in the last 10 years and they have been viewed millions of times.
I see a lot of folks making the same mistakes I did early on in my journey.
So here are some principles to help you get better at writing.
🧵
1. 𝗦𝗲𝗹𝗹 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻
Like that scene in wolf of wall street where Di Caprio asked Jon Bernthal to sell him a pen.
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.
Here are 10 performance optimization tips I learned after rebuilding two of my landing pages from scratch.
If you're a backend-focused dev like me, these might be new to you too.
They gave my sites a great perf improvement, especially on mobile.
🧵
1. If you have a logo image above the fold, then tell the browser to prioritize downloading it by adding it as a preload in the <head> section of the index.html
I love step functions, but the 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 workflow's pricing model (based on no. of state transitions) can get hairy at high throughput and/or for large state machines with lots of states.
𝗘𝘅𝗽𝗿𝗲𝘀𝘀 workflows solve the cost issue but you lose a lot in the process.
U can't visualize executions, no exactly-once execution, and limited to 5 mins.
A nice pattern is to combine 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 and 𝗘𝘅𝗽𝗿𝗲𝘀𝘀 workflows and get the best from both by nesting 𝗘𝘅𝗽𝗿𝗲𝘀𝘀 workflow inside a 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 workflow.
If you wrap the parts of a workflow that can rack up a high no. of transitions (e.g. a polling loop) in an 𝗘𝘅𝗽𝗿𝗲𝘀𝘀 workflow, then you can keep the cost in check, while the parent 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 workflow gives you exactly-once exec and long execution time (1 year).
Lambda is usually very cost-effective, you only pay when they run (with ms billing) and they scale to zero.
But a combination of misconfiguration and a high throughput use case can give you a nasty surprise when you get your AWS bill, esp if you don't have billing alerts set up.
A few of my clients have experienced this type of problem before. For example, when a function that is invoked millions of times a day is allocated with way too much memory. Or when provisioned concurrency is enabled on a function with a lot of memory.
Great question from my current cohort of students, paraphrased:
"Should you always use Step Functions to chain together a few Lambda functions? Are there patterns to simplify this? How about using SQS between the functions?"
Here are my thoughts 🧵
Firstly, on the broader topic of orchestration vs choreography, I've written my thoughts before. TL;DR is that I prefer orchestration for intra-service workflows, and use events for inter-service communication.