Thread by @jeremy_daly

I've been spending a lot of time lately with @dynamodb in my #serverless applications, so I thought I'd share my surefire guide to migrating to it from #RDBMS. So here is…

How to switch from RDBMS to #DynamoDB in *20* easy steps… (a thread)

STEP 1: Accept the fact that Amazon.com can fit 90% of their retail site/system’s workloads into DynamoDB, so you probably can too. 🤔

STEP 2: Create an Entity-Relationship Model, just like you would if you were designing a traditional relational database. 👩‍💻

STEP 3: Create a list of ALL your access patterns. If "search" is an access pattern, don't worry, we'll deal with that in STEP 17. 😉

STEP 4: Narrow down your access patterns to the ones *required* by app users. Data analysis and admin tasks, such as analytics, aggregations, behavioral triggers, etc, are all important, but likely not necessary for the end user interacting with your app in real-time. 🚫📊

STEP 5: Determine if your user access patterns require ad hoc queries that need to reshape the data. Likely the answer is, no. However, if you're building an OLAP application, #NoSQL is #NoGOOD. Pat yourself on the back for trying, and use another technology. 🤷‍♂️

STEP 6: Put your head in the microwave for 3 seconds (or however long is necessary for you to forget what data normalization and third normal form are). 🤤

STEP 7: Watch @houlihan_rick's Advanced Design Patterns for Amazon DynamoDB (DAT403-R) talk from @AWSreInvent 2017. 😯

STEP 8: Watch @houlihan_rick's Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401) talk from @AWSreInvent 2018. 😮

STEP 9: Clean up all the tiny pieces of your brain splattered around the room, then regroup, and watch them again, this time at half speed. Take notes. 🤯

STEP 10: Read the "Best Practices for DynamoDB" guide on the @awscloud site. Then read it again. 🤓
docs.aws.amazon.com/amazondynamodb…

STEP 11: Design *ONE* DynamoDB table that uses overloaded indexes to store all of your entities using composite Sort Keys (when necessary), adding additional LSIs and GSIs (again, when necessary) to accommodate the aforementioned access patterns. 😳

STEP 12: Write some sample queries and test your access patterns against your table design. Realize you did it completely wrong this first time, take a breath, drink a beer (or two), and go back to STEP 7. 😞🍺

STEP 13: Test your access patterns against your *NEW* table design. Iterate. Test again. Iterate, and test again. 🤨

STEP 14: Repeat STEP 13 until you are 95% confident that you've got your table design right. 😀

STEP 15: You did it (well, the first part anyway)! 🎉 Celebrate your accomplishment (maybe have another beer), and then wire your DynamoDB access patterns into AppSync or build out an API with API Gateway. Remember to use the Transactions API when necessary. 😎

STEP 16: Test, test, and test again. And when you're done testing, test it again. And make sure you write some tests so you can automatically test it, again and again. ✅

STEP 17: Enable DynamoDB streams and use them to generate/update aggregations and replicate data for reporting, search indexing, and/or other application requirements. (Lambda functions make for really good stored procedures, btw) 🚀

STEP 18: Test your DynamoDB streams *IN THE CLOUD* to ensure data is flowing and downstream resources are being populated/updated correctly. Write some tests to automate this. ☁️

STEP 19: Cross fingers, publish to production. 🤞

STEP 20: Profit! 💰

This was obviously a bit over simplified, but hopefully it gets you started on your journey to discovering the power of @dynamodb. If you don't get it at first, just keep at it. It will eventually "click" (unless you left your head in the microwave too long). Good luck! 👍

Argh, wrong link: