Sharing a cloud resource between multiple developers

I received a question after my email on Tuesday about cloud environments asking if there is ever a time when I would want to share a cloud resource between multiple developers in the dev account.

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?

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.

    View Emails Archive

    ☎️ Serverless Clarity Call

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>