Thanks for the feedback. I'm new to the platform, and certainly appreciate the interaction.

I think I described SI a bit better in another reply, and you can certainly check their website for a better description than I can give here.

I'll try to high level our particular issues to give you a sense of why this is important to us.

Traditionally, we've managed our customers via TF. I made a big push years back to try and standardize how we delivered infrastructure to our customers. We started pushing module libraries, abstract variables via yaml, and leveraged terra grunt to try and be as dry as possible. We followed along best practices to try and minimize state files for reduced blast radius etc.

What became apparent was that despite how much we tried to standardize there was always something that didn't fit between customers. So quickly each customer became a snowflake. It would have its own special version of some module or some specialized logic to match their workflow. Then over time as the modules evolved, so the questions start to come up:

- Do we go back and update every customer with the new version of the module? - Does the new module have different provider/submodule/tf version requirements? - Did the customer make some other changes to infra that aren't captured?

Making minor changes could end up taking way longer than necessary. Making large changes could be a nightmare.

In working with SI the mindset has shifted. Rather than manage the hypothetical (ie what's written in TF), let's manage the actual. Trying to reconcile in code why a container has 2cpus instead of 4, find the issue and fix it. If want to upgrade something, find it and upgrade it.

I can go into greater depth if you care or have questions, but this at a high level explains this post a bit more.