When working in teams to develop software, it is always the case that the step you take from your local machine to your lowest cloud environment is the biggest. From there to Production your envs should be fairly similar.

The method to deal with this problem, as with any problem, is to make effective choices. We need to have a clearly defined meta-goal. We need to ensure our solutions provide more utility than the complexity they generate and we need to attempt to ensure there are no better alternatives.

This essentially means understanding what you want to achieve and implementing a plan to solve for the issues which is the best of a set of possible plans.

When the intention is to deliver some valid software product then the goal should be to get the features of the software to production as fast and as safe as possible.

( I outline this in https://medium.com/@njgibbon/effective-choices-local-cloud-dev-194416cf0379 )

Now, I want look at the specific use-case of AWS Local Dev.

Some options

1: Just commit to the CI pipeline and build in the Lowest Cloud env.

Unable to test = likely to break something.

This could be disruptive to others.

Time-consuming to kick-off an automated build each time you trial and error to make your code work in the cloud.

2: Connect your local code to the Lowest Cloud env.

Difficult to coordinate with other people and the existing cloud services.

Likely to cause a bit of a mess.

May not get the correct access rights.

3: Create isolated Cloud Services to use locally per Developer.

More work to set up and cleardown.

Additional costs.

May not have the correct access rights.

4: ‘Phoenix’ Environments for checking.

Complicated to set up initially.

Can’t phoenix all dependencies.

Not enough understanding and not sure on the best context for this practise.

5: Use Mocks.

Time-consuming to create or set up.

Feature (in)fidelity.

No doubt there are situations where any of these options could seem preferable and this list isn’t exhaustive. I will try to layout some arguments for using LocalStack and other mocks locally.

LocalStack

“LocalStack provides an easy-to-use test/mocking framework for developing Cloud applications.”

It supports 17~ cloud APIs and my team recently found good use for it to work with SQS and S3 when developing microservices.

Advantages

No cost for creating cloud services.

No disruption of others.

No infrastructure management overhead.

Code delivered to the cloud has went through a decent quality check.

No access requirements.

No need to change code — just parameterise some properties.

Enables development offline.

Enables development when cloud components aren’t built yet.

Enables a simple & powerful trunk-based CI workflow.

Mitigations

Fairly straight forward to get working and no need for time-consuming custom stub code.

Fairly active support and updates; fairly good feature coverage.

Indeed, Localstack isn’t a panacea for all local cloud development problems. But, it can do a lot of work. If you look through the ‘Options’ list above and think using mocks would be a good fit I suggest giving it a try.

A Simple & Powerful Trunk-Based CI Workflow

First pick a defect or feature and slice it into sensible sized chunks where you can assert what success would mean. Branch off Master and develop offline with mocks for your dependencies (there shouldn’t be too many due to microservice architecture). Use this structure to sanity check your changes as best as possible. Code review. Merge back into Master which will initiate a build into your lowest cloud env and automatically tag your repo with some versioning scheme for healthy traceability. In parallel, testers should be building a really robust regression net that can be thrown upon any cloud environment at the drop of a hat. Throw the net on the change and see if it’s good or not. If there is success then you can push the changes to a higher environment. If there is a failure then decide whether to revert or fix-forward. Iterate.

Everyone knows their job and their time is being used effectively in terms of the goal. Importantly, each version of the application is containerised once and once only. This has various benefits, but my favorite is the conceptual simplicity of the approach.

localstack-spring-s3-poc

https://github.com/njgibbon/localstack-spring-s3-poc

A quick and dirty demo on using LocalStack to perform AWS S3 operations through a Java Spring App using the Amazon SDK.

You are able to perform CRUD operations through the Amazon SDK but for simplicity I just went for a series or reads.

Please look through the README.md to avoid duplication :)

LocalStack S3 Browser View

Demo App Reading the Contents of an Object in a Bucket

Resources

Trunk-based dev: https://trunkbaseddevelopment.com

Demo: https://github.com/njgibbon/localstack-spring-s3-poc/blob/master/README.md — See Resources section.