Development with AWS & LocalStack

This is the preamble to a series of posts I’ve put together for a slimline way to define data sets with JUnit, if you’d rather skip the ramble and see the code, jump here.

I’ve been a strong proponent of cost effective development practices in my work, and I think that needs to happen at every layer of the lifecycle.

I’ll set aside the architectural considerations of why you’ve settled on AWS or the specific component for your use case and focus on the build stage, particularly how to run repeated tests against a DynamoDB table without having to hook up to a live AWS account.

But… surely testing DynamoDB isn’t that big a deal, its got a cost effective model, and spinning up new resources is what the cloud is for right?

Well… that’s fine but you start to build in the complexities in a few different ways:

1. Have all developers share the same table (in a non-production account)
   • This is by far the quickest and simplest way to get started, but quickly starts to show its issues when you get multiple developers working in parallel
2. Have multiple tables and give everyone a different table each
   • This starts to affect your codebase and runs the risk that some non production configuration code will slip in
3. Assign a different AWS region to every developer to prevent crossover
   • Just no… don’t do this, it won’t scale if you have more developers than regions and you’ll be subject to latency
4. Give each developer a different AWS Account
   • This is certainly an option, especially if you’re using multiple AWS services
   • Can have a governance challenge about cleaning up AWS Resources
   • If you do go this approach, I’d strongly recommend you use AWS Organisations, and probably restrict access using SCP Policies for your developer accounts
5. Simulate DynamoDB locally

(And yes, I have heard all of the above being suggested)

There’s two options for bringing DynamoDB closer to your developer’s hands, running the official AWS DynamoDB Local, a decent enough option if you’re doing a test of a fairly stable or complex application that doesn’t change the data tier in a significant way.

But what if you’re making significant changes to your service tier, or want to run unit tests in isolation from other work in a consistent repeatable manner?

That almost calls out Docker to me, something that LocalStack has already seized upon and provides us capability to build repeatable infrastructure components for our applications.

In the next set of posts I’ll discuss setting up a Java Development Environment using LocalStack with repeatable JUnit tests, that restores its datasets similar to DBUnit helping to reduce the complexity of cascading database updates affecting subsequent tests.

Over the course of this series I’ll come back and provide the links to the follow up posts here once they’ve been updated:

1. Development with AWS & LocalStack (this post)
2. Unit Testing Java and DyanmoDB, with JUnit & LocalStack
3. Configuration through Annotation
4. Building a @Dataset

Note: I’ll also point out that in a purist cost effective sense, why would you use Java at all rather than Python or Node? Likely because you already have an organisation that’s built on Java skills and introducing a new language like Python or Node.JS would have a higher TCO than your purpose can justify. This first post shouldn’t affect that in any way, but if you’re not using Java, the next few posts might not have a huge degree of practical interest to you