27 lines
2.5 KiB
Markdown
27 lines
2.5 KiB
Markdown
well said @the.wrong.tim
|
|
|
|
i agree with most of what you said as well @Francis, i personally would like all manual gates to go (at least for our test/stg environments)
|
|
|
|
i think i'm pretty qualified to say this, having recently changed the aws_networking ( did you know i destroyed and remade all the igw routes in every bedrock env? ), the otel collector,
|
|
in my view we share very little in terms of actual utilities and modules, both between environments and components, just compare one of the original aws bedrock envs (prod/dmc) with the more recent ones i've been putting together to standardise the GSF (prod/endeavour).
|
|
pretty much none of our environments are the same, stuff is missing, named differently, whatever.
|
|
sometimes this is good because it means the blast radius of a change is small, if you change the otel_collector maybe only 2 envs are actually using it that you have to check on.
|
|
in practice even when you think you're changing a shared module, you're not actually, the pipeline is just running a bunch of independent tf.
|
|
|
|
i think this is just `the way it is` with terraform, it's generally easier to copypasta something and change a few variables than it is to make a configurable reusable module that works for different use cases.
|
|
this can be fine, it means everything is super loosely coupled, but the tradeoff is that everything has to be managed independently. there's a proliferation of data blocks grabbing stuff by ID or name wherever is convenient
|
|
|
|
> contributor of the code has to either fix the breakages or liaise with consumers of the code to fix breakages
|
|
|
|
i think this fact combined with the very loose coupling terraform encourages has two chilling effects
|
|
|
|
- writing and maintaining any kind of shared util or module in the monorepo is super unpleasant because you can break everybody's stuff without knowing how
|
|
- refactoring anything is also a nightmare
|
|
- changed the name of something by adding a resource prefix? some ancient environment's data block now can't find its resource and it's **your** problem to fix it
|
|
|
|
this has basically led to a lack of sharing between components, standardisation, quality of life improvements... kinda antithetical to the whole idea of the monorepo (different discussion maybe, i digress...)
|
|
|
|
but in GSF we have shared modules that rigidly standardise every deployment so they get all the latest features and monitoring
|
|
it's just that we don't necessarily want to get those updates forcibly deployed the second they are released
|
|
|