Kyle W.

AWS Community Day NL

On the 3rd of October I attended AWS Community Day NL 2022 hosted in Amersfoort. This gathering consisted of a day of conference talks separated into tracks, a keynote and chat with Dr. Werner Vogels, as well as an AWS Game day which I did not attend. Here are my thoughts on the talks.

SLS204 - Building Serverless Rust App using AWS SDK for Rust - Shing Lyu

This was a nice overview of the templates, tools and starter projects that the engineers at AWS have made for running Rust on Lambdas. As of writing, the SDK is a developer preview and the lambda runtime is based on the custom runtime, so you can expect limited support and stability; AWS recommends to not run production code on this, but anecdotally this is already the case with some companies.

They have created a cargo command to help build the code into the correct bootstrap zip format that lambda expects. With this, you can use whatever method you'd normally use to deploy the code to a lambda function.

From a question of an audience member, it was revealed that the performance they’ve seen is unmatched to any other runtime they develop. Only the Golang runtime comes close from a warm start, but it is definitely slower from a cold start. Though, take this with a grain of salt, as no official benchmarks or tests have been published.

SLS303 - Building a mindset to successfully adapt DynamoDB’s Single Table Design - Anurag Kale

This talk focussed on the soft skills/strategies involved with helping developers within a company move towards using single table design effectively. There was a brief explanation of single table design and some of the advantages of designing this way, especially when using AWS DynamoDB. If you want to learn more about this, they recommend reading The DynamoDB Book.

A useful tip to help create diagrams for the data, is to not focus on what form it will be stored in the database, but how the data will be consumed and used. With this you can still map out a data model using entity-relationship diagrams as this can document and help developers and stakeholders understand the data.

Thinking about how the data will be used is also an effective start to designing how the data should be stored in a single table. You can implement the logic into the save/store actions, where you would normally require a join for querying combined data in a 3rd normal form database. You can do this for the different scenarios where the data will most often be used together.

The talk rounded off with some tips on knowledge-sharing methods, such as organising events and jam sessions. This is particularly useful if you need help changin company-wide mindsets on how to design your data.

DOP302 - Mistakes I made writing Infrastructure as Code, and how to avoid them - Ben Bridts

I learnt a lot about different techniques you could use to create a library of reusable constructs for your IAC, but also how misuse of them can lead to unfortunate mistakes.

My summary of the first mistake would be: "Don’t write infrastructure as code that relies on state or produces artefacts.". If you are building infrastructure with CDK by relying on pre-existing conditions, you cannot be confident that that infrastructure will deploy consistently. Seems like an obvious point, but it can be quickly forgotten. When creating resources programmatically, and you feel like you can do something smartly, you may disregard the fact that this program will output infrastructure.

Another tool that can backfire if not used carefully is CloudFormation Custom Resources. Due to the reliance on creating programmatic resources at deploy-time rather than through a generated template, it can be quite easy to have a faulty resource that will only work on some of the resource events. This can lead to resources that are orphaned, leading to increased hidden costs, and difficulty cleaning up environments. CloudFormation registry can help avoid some of these mistakes and tends to be recommended over custom resources.

This last mistake focusses on maintainability of a generic construct library, meant for reuse within an organisation across different teams and domains. You should avoid making overly generic constructs that do more than one thing. If it is more complex, then it should be specific in its function. Losing sight of this can lead to managing expectations through passing a long list of properties down a chain of custom constructs, defaults can become hidden, and the meaning becomes obfuscated. There is a simple explanation of how constructs can be composed in the AWS documentation.