#02 - The Countdown to Re:Invent

Fantastic insights by our expert of the week Luciano Mammino, the latest news, results of last week's poll, and more...

Sep 13, 2024

Welcome

In last week’s newsletter, we discussed AWS announcing the latest Heroes, Ran Isenberg answered our ‘expert of the week’ questions, and we had some great content from the community.
Now we are hitting mid-September a lot of us are counting down to Re:Invent, whether we are attending, speaking, or watching online ready to see the latest releases. I saw a great post by Mark Sailes recently with his Re:Invent tips, so here are my own top three for people attending in person:
Be strategic about sessions: most hotels are an Uber away from each other or at least a 40-minute walk, so don’t get caught out booking back-to-back sessions at different hotels!
Dry Lips: As odd as this sounds, with the desert heat comes dry lips, so 100% take a lip balm or two with you!
Book in chill time: make sure you take time to meet other attendees, network, and just take a load off your tired feet! If you are an AWS Community Builder I can’t state enough how amazing it is to network in person with each other in the Builders Lounge.

📰 Articles that caught the eye

An alternative to batch jobs: scheduling events with EventBridge Scheduler by Zied Ben Tahar.
A Critical Look at AWS Lambda Extensions: Pros, Cons, and Recommended Use Cases by Ran Isenberg.
Luc van Donkersgoed covers PostNL’s Serverless Journey.
Thoughtworks wrote an interesting piece called Time to get serious about AI testing.
Benjamen Pyle wrote a great article on Building the Perfect Compliment to DynamoDB with Typesense.
Elias Brange wrote a great article called Never Miss a Beat: Better CloudWatch Alarms on Metrics with Missing Data.

🚀 New Releases

🎓 Ask the Expert

Each week I ask a different expert the same three questions to get their personal insights - this week we have Serverless Hero Luciano Mammino!

What is one common mistake you see teams making when implementing serverless solutions, and how can they avoid it?

As a cloud consultant and serverless expert, I work with many customers that need help with modernizing their applications and transitioning to more managed, serverless solutions. One common challenge I see, particularly with AWS Lambda, isn’t so much a mistake but more of a knowledge gap. Teams with traditional backgrounds often see Lambda as just another, fancier deployment method. In doing so, they sometimes try to squeeze their stateful web servers into a single Lambda function. While this might seem like a good first step into the serverless world, it usually doesn’t yield the best results.
It’s crucial to understand that AWS Lambda provides a completely different approach to building web applications, with its own unique tradeoffs. Since Lambda functions are stateless by design, relying on persistent memory or long-running connections – as you might in a traditional web app – can cause issues. Lambda is event-driven, so the best way to think about it is in terms of event handlers with clearly defined interfaces. You need to define which events are supported and what workflows should be triggered, which also changes how you handle errors and recover from them. Each Lambda function should have a single responsibility and clearly defined permission boundaries. By packing multiple endpoints into one Lambda, you miss out on some of its key advantages.

To address these challenges, it’s helpful to approach migration to AWS Lambda not as a simple lift-and-shift, but as an opportunity to rethink and modernise the entire application. This requires a significant educational effort, as teams need to embrace new paradigms and push themselves to learn new technologies. It’s also important to have a clear idea of what you want to achieve with the migration. Sometimes, companies migrate simply because “everyone else is doing it,” but not every organization will benefit the same way. Starting by questioning whether migration is necessary and clearly defining the expected business outcomes can set the project on the right track.
Which serverless tool, concept, or service are you most excited about right now, and why?

If you’ve seen me speak at a recent conference or checked out some of my recent work, you probably know how excited I am about using Rust to write Lambda functions. I’ve been learning Rust for the past 4-5 years, initially as a personal challenge to explore languages suited for lower-level programming with a fresh approach to memory management compared to what I was used to (like JavaScript/Node.js, Python, PHP, Java, and .NET). Once I got comfortable with Rust’s syntax and unique features, I fell in love with it and started finding more and more reasons to use it.
Naturally, as a Lambda enthusiast, I wanted to experiment with Rust in that space, and let me tell you, Rust and AWS Lambda make a fantastic combination! There are so many reasons why, and I could go on about them for hours (which I definitely have!), but if I had to sum it up: Rust can make your Lambda functions faster, more cost-efficient, and even more environmentally friendly. Plus, the tooling and developer experience are top-notch, which makes it even more worth exploring.
If you’re excited about Rust and looking for a way to introduce it in your organization, Lambda could be the perfect entry point. You don’t need to be that person that advocates for “Let’s rewrite everything in Rust!”. You can start small—maybe focus on that one Lambda function that gets invoked thousands or even millions of times a day. That’s where you’ll likely see the biggest performance and cost improvements. Rewrite that function, measure the performance and cost improvements, bring more people along in this experiment and then decide together if it’s worth investing more time into migrating other functions. One of the great things about Lambda is its modular nature—each function is independent, so it’s relatively easy to rewrite or replace them without a huge, all-at-once migration.
What is your favourite trick or tip when working with serverless that the readers may find interesting?

This might not be my absolute favourite topic, but it's something I recently discovered and think deserves more attention. When you talk about Rust and Lambda, you inevitably get into custom Lambda runtimes. Rust, like Go and C++, doesn’t have a managed runtime, so you need to use a custom one (typically Amazon Linux 2023). If you're used to managed runtimes like Node.js or Python, you probably haven’t given much thought to the runtime itself, so you might be asking yourself, "What exactly is a Lambda runtime?".
I've tried explaining this in different ways, but recently, I came across a great example. If you create a Lambda function from the AWS web console and select Amazon Linux 2023 as your runtime, you’ll actually get a Lambda written in Bash by default! Yep, Bash. Now, I’m no Bash enthusiast, and I wouldn't use it for much beyond simple scripting, but the code AWS provides is a real gem—clear, concise, and well-commented. In just 22 lines (including comments), it does an amazing job of explaining how a basic Lambda runtime works and highlights the difference between the runtime itself and the handler function.
If you've ever been confused about runtimes versus handlers or just want to understand how a Lambda runtime works under the hood, I highly recommend checking it out!

💡 Quick Hints & Tips

Each week I share two or three quick hints or tips based on things I notice in day-to-day engineering life:

[Tip 1] Did you know when working with Amazon Bedrock agents you can pass additional custom information into the invoke agent SDK call, in the form of sessionState:

const input: InvokeAgentRequest = {
      agentId,
      agentAliasId,
      sessionId,
      inputText: prompt,
      sessionState: {
        sessionAttributes: {
          userId: userId,
          currentDateTime: new Date().toISOString(),
        },
      },
    };

 const command: InvokeAgentCommand = new InvokeAgentCommand(input);

In this example above, we can pass the user ID of the logged-in user and the current date and time to be used in our agent action group executor code. An example could be booking a hotel for the correct user by ID through our agent.

[Tip 2] Did you know when deploying through the AWS CDK you can change three levels to determine when you need to approve changes before deploying:

cdk deploy --require-approval LEVEL

The three security levels are:

never: approval is never required.
any-change: requires approval on any IAM or security-group-related change.
broadening (default): requires approval when IAM statements or traffic rules are added; removals don't require approval.

🎙️ YouTube & Podcasts

‘Why Fathom is running serverless at scale instead of containers’ with Yan Cui.
Andres Moreno and Khawaja Shams record Episode #8: Commitment issues of the Believe In Serverless YouTube channel.
Learn how to accelerate API delivery and quality using SmartBear SwaggerHub on Serverless Office Hours with Julian Wood.
Build Serverless Web Applications with Rust and Cloudflare Workers with James Eastham.

✖️ Tweet of the Week

This tweet from Luc van Donkersgoed caught my eye this week, but it was the comments that were even more fascinating.

If you read through the comments, it is clear that it is actually 50/50 between blogs and videos that people prefer for learning. Personally, I favour blogs or detailed articles with code examples, as I prefer to go at my own pace (and typically skim-read too). As it happens, though, I will be going all in on YouTube and videos in the coming weeks as it was on my list for 2024, and I want to make my content as accessible as possible!

🗳️ Poll of the Week

Firstly, last week’s poll results were in, and most people felt that AWS Step Functions do add a level of accidental complexity and service lock-in. If you are interested in the tweet that sparked the debate, you can find it here.

This week, we ask the question “What is your go-to IaC tool in late 2024?“

Feel free to add in the comments why you answered the way you did.

🗣️ Inspirational Quotes and Thoughts

This quote should give you the confidence to start that blog, learn something new, and just start with baby steps and see where it takes you. Even if you fail, it is a learning opportunity.

“No one knows what they’re doing. Nobody.

Not even the ones with degrees, and big job titles, and more things than you.
Not even the people on your vision board.

Everyone is just trying loudly, failing loudly, and trying again.

And so should you.”
- Kaya Nova

If I reflect on my own experience, just last week, I started this newsletter. Am I an expert in newsletters? No. Do I trust in the process that I will work it out, and learn from it? Yes.

⭐ Spotlight

I just wanted to highlight Andres Moreno this week for all he is doing in the community. It has been awesome to see Andres step into regularly hosting the Believe In Serverless podcast, live sessions with guests, and still blogging too. Not just that, anybody who has spent time with him knows he is just an all-around fantastic person, fun, and a breath of fresh air! Thank you for all you do for our community!

👋🏼 Wrapping Up

Thank you for reading the second Serverless Advocate Newsletter! If you want to find out a little more about me, please have a look at:

https://www.serverlessadvocate.com/

If anybody is attending the AWS Community Summit in Manchester on the 26th of September then hit me up as it would be great to meet as many people as possible!

See you next time,

Lee