The main reason why you may wish to do this is if you’re using a cloud resource which isn’t serverless and so it could get expensive for every developer to have their own instance of it always running. Good examples of this are Elasticsearch Service, Elasticache Redis and RDS.
My general answer is that this setup should be avoided if possible. The main reason is that developers no longer have isolated environments and could more easily interfere with each other. Also, controlling the configuration of the shared resource via IaC becomes more difficult, as developers can’t easily make changes to a shared instance without affecting others. And because it’s not part of their standard stack of IaC resources, developers may tend to feel less ownership of it and things such as manual configuration changes via the AWS console become more likely.
But the only really easy ways to avoid these issues are to: (a) not care about the bill; or (b) not choose such services in your architecture in the first place! This second point may seem facetious but I highly weight a service’s deployability as a selection criterion.
If neither of these would work for your team, the next best option is to find a mechanism for partitioning the shared resource instance to minimise the probability of developers interfering with each other. So for Elasticsearch, you could have each developer use their own unique prefix on index names. For RDS, do similar with database names within the shared instance.
This solution may require extra overhead for your application code in order to deal with a limitation that only affects the dev environment. It may also require creation of manual scripts that new developers need to run once to create their “partition”. It also doesn’t address the IaC concerns with the shared resource but it should at least allow developers to work relatively independently.
Do you have any hybrid architectures with both serverless and non-serverless cloud resources? How are you managing these in your cloud dev environments?
Indie Cloud Consultant helping small teams learn and build with serverless.
Learn more how I can help you here.
Join daily email list
I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.