#15 Post re:Invent Week 😴

In this week’s issue, we have more great insights from our Serverless Expert of the week Toli Apostolidis, the spotlight falls on Serverless Hero Kristi Perreault, the latest releases, news and more!

Dec 12, 2024

Welcome

In last week’s article, our serverless expert of the week was AWS Serverless Hero Filip Pýrek, our spotlight fell on author and serverless expert David Anderson, and we congratulated AWS Hero Rossana Suarez for the Go Build Award achievement!
This week our serverless expert of the week is Team Topologies Advocate and Datadog Ambassador Toli Apostolidis, our spotlight falls on AWS Serverless Hero Kristi Perreault, we look at the latest articles, serverless releases, hints and tips, and more!
This week’s newsletter is sponsored by Leighton.

A Glimpse into My Week 🎤

Since my last newsletter last Friday, I have travelled back from Las Vegas over the weekend, getting back late Saturday night following an amazing re:Invent! Like many others, I have really struggled with jet lag since getting back and have been waking up at 3 am each morning following the 24 hours of travel.. 😴

The rest of the week has been catching up on work, including one of our AWS and AI-based marketplace offerings, which has been very fun to build. There are many learnings on this one, which I will be blogging about!

One of the key highlights of re:Invent this year for me was the keynote by Amazon CTO, Dr Werner Vogels, who stated, “Listen to the heroes”, meaning take advantage of the experience, lessons, and knowledge sharing of the 257 global AWS Heroes.

Some of our team also put together the following website which shows the latest social media posts on BlueSky from the heroes.

📰 Articles that caught the eye

⭐ The highlight for me this week was the article by Steve Morland due to the simplicity but power of the example.

🎓 Ask the Expert

Each week, I ask a different serverless expert the same three questions to get their personal insights - this week, we have Team Topologies Advocate and Datadog Ambassador Toli Apostolidis:

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

The number one issue I come across time and time again is the lack of design ahead of time. Serverless can be a double-edged sword. You can get started (too) quickly: within a day you can have a stack in production with everything you ever wanted: infrastructure as code, a schemaless NoSQL database, business logic in your Lambda, an API, an event published to EventBridge, messages in queues and dead letter queues via SQS etc.
However, you still need to design your systems to fit your problem space. For example, I find that teams new to serverless tend to either treat DynamoDB as a relational database or a classic NoSQL database. DynamoDB, as with every technology, is only as good as how you use it. So you have to make some design decisions upfront:

- What are your data access patterns? Incidentally, this will help you design your service more generally. Decide your pk and sk accordingly.

- Are you implementing single table design?

- Are you anticipating creating global secondary indexes?

Another classic example is events. It's so easy to publish events to EventBridge that you tend to forget to design your events accordingly. Invest in event design and event governance. If in doubt, simply use the data and metadata pattern and deploy Event Catalog as a sensible default.

A big aspect of design is practice but you also need to invest in learning: you can get surprisingly far with reading the relative AWS guides online. I promise that if you read the CDK guide, you will know 90% of what you need to know.

My final advice is to not isolate yourself: join the community ("believe in serverless" Discord server, serverless days conferences, etc.) and reach out to your AWS account manager to connect you with experts.

2. Which serverless tool or service are you most excited about right now, and why?

Although I have been helping teams build serverless systems in AWS for 5 years, and I believe in its future, I am intrigued by what Cloudflare is doing in this space.
It's the best alternative I have seen to AWS serverless. Some of the primitives they build will bring us into a new era of abstraction where we don't need to worry about regions, latency and cold starts. It's early days, but it will boost the serverless movement if it works out. I would like to see how AWS responds to Cloudflare's proposition.

3. What is your favourite trick or tip when working with serverless that the readers may find interesting?

Serverless architecture designs often look verbose and complex: a series of AWS icons with arrows flying everywhere. Don't judge or get overwhelmed. Often, they are like this because the designs are more explicit than the normal abstracted boxes and arrows.
My number one tip when creating a new serverless service is to build a walking skeleton of the service: within a day, deploy a hello world API and a hello world event published to production. And iterate from there. Serverless architecture is all about the ability to evolve the designs. Often, the bottleneck can be permissions, pipelines, or observability. Get that right on day one, and iterate from there. Be strict with yourself; don't be tempted to add functionality.
If you are a larger organisation (more than 3-4 teams), invest in a template the teams can use. If you do, don't mix the blueprint or sample code with the "starter template". Create two different repos for these two different purposes!

🚀 New Releases

There were a huge amount of service releases last week with re: Invent in full flow, with this week being a little quieter, as you would imagine. Here are my favourite releases since the last newsletter from re:Invent:

🔥 Tip: Check out https://aws-news.com/ for the very latest up-to-date serverless releases as they happen, created by the talented AWS Serverless Hero Luc van Donkersgoed.

💡 Quick Hints & Tips

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

⭐ [Tip 1] API e2e Tests - Do you want to run e2e API tests but do not know how to get started? The easiest way I have found is to utilise the Newman package with Postman in your pipelines. Newman is essentially a command-line runner for your Postman collections which can simply be installed and used like this:

For more information, check out this article.

⭐ [Tip 2] Stream CloudWatch Logs - Did you know that you can stream your live Amazon CloudWatch logs to your VS Code IDE? Hat-tip to Luca Mezzailra!

This can be really useful when you want to check your logs live using the AWS Toolkit extension in VS Code. You can view a fantastic article here which covers the other aspects of the extension as well.

✖️ Social of the Week

This week’s social is by Yan Cui discussing the biggest serverless announcements at re:Invent:

This is a great bite-sized article giving you the biggest takeaways.

🎙️ YouTube & Podcasts

Here are some of my favourite sessions from re:Invent last week:

🗳️ Poll of the Week

In last weeks poll, we asked the question, “How do the majority of your cloud solutions run as standard?“. What is your standard, minimum, or “go-to” when releasing software in the cloud?

It was interesting to see 86% vote for multi-AZ as their go-to option and 14% saying multi-region. Nobody chose multi-cloud, which is expected.

This week we ask the question, “Would you now consider Amazon Aurora DSQL over Amazon DynamoDB as your go to database?“. Please feel free to add comments below

🗣️ Inspirational Quotes and Thoughts

This week’s quote comes from software ethologist Brian Foote, who also came up with the term “big ball of mud”:

“If you think good architecture is expensive, try bad architecture.”
- Brian Foote

I love this quote because it highlights a crucial truth - the cost of designing good architecture is often far outweighed by the long-term expense of maintaining and running bad architecture. To me, it's not just about immediate operational costs; it's about the sustainability and adaptability of the design itself.

To ensure I'm building “good” architecture, I typically adhere to the following key principles with my teams:

Use evolutionary architecture: Build systems that can adapt and evolve as requirements change.
Just enough up-front design: Strike a balance between planning and flexibility to avoid over-engineering, building the wrong thing, or under-preparation.
Design for failure: Assume things will go wrong and build resilience into the system. This includes threat modelling.
Serverless-first mindset: Prioritise serverless solutions for scalability, cost-efficiency, and reduced operational overhead.

What do you think about the tradeoffs between good and bad architecture with regard to expense? What key principles am I missing?

⭐ Spotlight

This week’s spotlight falls on AWS Serverless Hero Kristi Perreault.

Kristi is a Principal Software Engineer in Cloud Architecture & Engineering Enablement at Liberty Mutual, has been an AWS Serverless Hero since 2022, an international speaker, and is building the Teach Me AWS website alongside Matt Coulter, and currently co-organises the Portsmouth, NH & Belfast, NI AWS User Groups and CDK Day. Thank you for everything you do for our community!