I've gotten a lot of questions about "how do I become an AWS serverless hero?" or "what does being an AWS hero mean?" so I thought I'd share my thoughts here
Firstly, it's NOT a programme that recognizes expertise, it's a programme that recognizes your contribution towards the community - i.e. it's not about what you know, but how much you empower others.
And no, you don't need to be certified, certs don't help AFAIK.
2/
It's a great recognition - I love it, and it has definitely helped my career progression. But it's still just icing on the cake. Empowering others is rewarding enough on its own and has defined my career, with or without the heroes programme.
3/
Whether or not you get recognized as an AWS hero is also down to luck - that someone from AWS takes notice of your contributions and nominates you.
Don't give up, keep helping others and hopefully it'll happen 🤞
4/
As for what you get for being an AWS hero - free trips to Vegas for re:invent every year is pretty sweet. But more useful for me are the regular briefings on product roadmap and getting access to AWS teams, and being part of the heroes network.
5/
I've learnt about product features in the pipeline and gotten involved with many beta tests through the heroes programme and it's great to be able to provide early feedback to services I use daily and help them get even better.
6/
And lastly, the AWS heroes programme has so many smart people from all walks of life and it's a pretty awesome network to be a part of!
end/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I have written over 800 technical articles in the last 14 years and they have been read 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 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.