What sorts of best practices are you using to mana...
# general
s
What sorts of best practices are you using to manage long-lived resources (e.g. RDS, VPC, ElasticSearch, etc) in ephemeral team development environments?
If I am developing a REST API with API Gateway, Lambda and DynamoDB, it's fairly straightforward to spin up individual resources for each developer when they execute
sst start
by setting the stage name to the developers username. For example, from my
package.json
file:
"scripts": {
"start": "sst start --stage $(whoami)"
}
t
^ you don't need to pass in whoami anymore fyi
It'll generate a unique stage on first run and ask you to confirm or change it
a
I did that before until @thdxr added the helper.
😂
s
ahh, that's right!
@Adrián Mouly I saw your post a while back around how you decide to define a resource or not
using SSM/ARN's, and I believe @Ross Coundon was using environment variables to a similar effect
a
Yeah.
s
I think some shared resources make a ton of sense (e.g. a VPC everyone uses for development)
a
I’m sing SSM to store the ID of the VPC and the Secgroup.
Yeah, exactly. We create those only once.
s
but it's not so clear to me that it's a good idea to share something like ElasticSearch or RDS
In the case of RDS, I used a local DB 🙁
a
For RDS I was tyring to use VPN, but I’m still in the process.
ES also doing the same as VPC/SG.
We create it only once, and then reference it from SSM.
o
Yah, for me it comes down to cost and complexity of setup through CDK. If either of those are high, then sharing via SSM makes sense. We share a cognito pool in dev, and some external SaaS APIs
s
I guess I'm wondering about instances where usage of the shared resource might overlap, like two developers creating/updated ES indexes in the same ES domain. For example, I might create a list of movies to search while a team member updates/deletes the same list of movies.
o
Yeah ideally shared resources almost never change their configuration - if they do then its definitely an issue
s
@Adrián Mouly How do members of your team use the shared ES resource in a way that doesn't interfere with one another's work?
a
Good question…. we actually didn’t do too much with ES at the moment, we have a single guy who is the “expert” and I think he did some configurations connecting to the ES service … not from code 😞 But well, the ES instance is created from code, nothing else.
d
If you have more than 3 people working on anything, you’ll spend way more money debugging random issues vs just paying for separate environments
So unless it’s impossible (with certain SAAS), have different tenants/services for everyone
s
I'm introducing SST to an organization with 40+ engineers and I'm trying to figure out the best way to advocate for development in the cloud (they currently lean heavy on docker and local emulation) Spinning up 40+ ES domains (or RDS instances, etc) might be a tough sell
It's an easy sell with services that scale to zero (DDB, API Gateway, Lambda, etc), but seems to require a different approach with services that do not operate that way
d
I think it is … but only about 20 devs in my team. But we are also trying to move away from stuff that requires a VPC.
You can always have indexes/databases per dev, it’s just a drag and more complexity.
s
Hmm, interesting. I hadn't thought of specific indexes per dev (I'm fairly new to ElasticSearch)
But I agree with you, I prefer clean and simple
just trying to explore the pros/cons and various options. I know someone will say "Just use Localstack", then I have way more problems 🙂
d
Yeah, but rolling out something new to 40+ people, the last thing leadership should worry about is minuscule cost per month per develop, when devs will burn through thousands via their time trying to work towards cost optimisation 🙂
It’s always the same though, let’s save no matter how much it costs 😉 So smart to think about it and working through options.
s
Yeah, tricky to navigate situations like this. People can react negatively to change, especially if it requires a paradigm shift in thinking about how we develop software. Doubly so if it saves $ (or sometimes, even just a few ¢)