Day 2 of re:Invent 2023 has come and gone and it was personally my best day yet. By the numbers, I’m at the halfway point with my two busiest days ahead. Let’s get right to my recap as it’s filled with all kinds of fun interactions.
Let’s dig into Day 2 of AWS re:Invent 2023.
Day 1 of re:Invent has come and gone and it was an epic start to the week. I’ve often heard it said that re:Invent is a marathon and not a sprint and that’s a very true statement. If you are reading this and are at the conference, pace yourself. And if you are at home watching virtually, do the same, but perhaps more mental pacing than physical.
Let’s dig into Day 1 of AWS re:Invent 2023.
Here goes the beginning of a nightly blog post recapping my experience at AWS re:Invent 2023 in Las Vegas. AWS re:Invent officially kicks off on Monday 11/27/2023 but for those of us who arrived early, the week started a bit early. Let’s recap Day 0.
For this series, I’m going to do a nightly recap of the things that I experienced at re:Invent. I plan to share my highlights from people I meet, exciting news drops or sessions I found to be fantastic.
I’ve been working recently with some data that doesn’t naturally fit into my AWS HealthLake datastore. I have some additional information captured in a DynamoDB table that would be useful to blend with HealthLake but on its own is not an FHIR resource. I pondered on this for a while and came up with the idea of piping DynamoDB stream changes to S3 so that I could then pick up with AWS Glue. In this article, I want to show you an approach to building a partitioned S3 bucket from DynamoDB. Refining that further with Glue jobs, tables and crawlers will come later.
I’ve been trying to learn Rust for the better part of this year. My curiosity peaked a few years back when I learned the AWS-led Firecracker was developed with the language. And I’ve continued to want to learn it ever since. Fast-forward and I’m jumping both feet in. That’s usually how I work. I must admit that right now, I’m the most noob of noobs, but that’s not going to keep me from sharing what I’m up to and what I’m learning. For me, this blog is as much about sharing as it is about learning and communicating to those reading that it’s OK to be where you are in your journey. There are no straight lines. Only periods of growth and plateaus. In this article, I’ll walk you through consuming an SQS Event with Lambda and Rust.
When working on building solutions, the answer to some problems is often, it depends. For instance, if I need to deal with data as it changes and use DynamoDB, streams are the perfect feature to take advantage of. However, some data doesn’t need to be dealt with in real-time, once a day or every 30 minutes might be good enough. This was problematic up until recently, as AWS released incremental exports with DynamoDB. In this article, I want to explore building an incremental export with DynamoDB and Step Functions.
I was working recently with some backend code and I needed to communicate the success or failure of the result back to my UI. I instantly knew that I needed to put together a WebSocket to handle this interaction between the backend and the front end. With all the Serverless and non-Serverless options out there though, which way do I go? How about plain old WebSockets with AWS API Gateway and Serverless?
A good friend of mine is working on a really neat redrive tool with SQS and wanted to write an article to describe its purpose and use. I’m super honored that he asked me to share his writing on my blog. Please find below Adam Tran’s “Analyzing and Correcting Errors with Advanced SQS Redrive”
Analyzing dead-letter queues (DLQs) within the AWS ecosystem can be tricky. Receiving and analyzing messages via the AWS Console is very limited, and does not allow for the manipulation of messages in any sensible manner. Sure, you can redrive an entire DLQ, but what if you need to analyze thousands of messages or make changes?
There are many potential solutions to this problem, but a simple solution that I’ve developed is to download your queues’ messages locally where they can be analyzed with any tool of your choosing. I’ve defined a stateful directory structure to reflect where a message is in its journey of analysis so that you can make changes in whatever manner you deem appropriate.
First off, this post is not affiliated with AWS or the re:Invent conference. The content below contains opinions and some tips for navigating your first re:Invent conference. I believe that if you are building on AWS and want to elevate your experience, network and opportunities with the platform, re:Invent is something you need to attend and put on your calendar year over year. Let’s get started and talk about attending your first re:Invent conference.
Event-Driven architecture paired with Serverless technologies are a powerful combo to build applications. But failure does happen and you should expect it to happen. Dealing with that failure is often done by dead-lettering messages into a Dead-Letter-Queue. But what do you do in order to monitor those queues? Most people start manually checking them or perhaps adding a CloudWatch Alarm that triggers an SNS topic. What I’d like to show you is a more advanced version of this monitoring through some code, constructs and AWS CodeSuite of tools. Say hello to monitoring SQS with Datadog.
