> Terraform is there specifically to solve the Aws infrastructure complexity.
I don't know if anyone here remembers the Ant build system, but writing your own Terraform spaghetti strongly resembles the days of Ant, before Maven came along. Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
I have to disagree a little here, if you're already in AWS, then an investment in fixing your terraform structure is not just worth the money, but gives you a better understanding of the infrastructure architecture, you also retain ownership of your deployments. What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website. You're now depending on, and maybe even paying for, an external company for devops support to do something you already know how to do.
It seems to be in the long term, that time is definitely not better spent elsewhere.
> What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website.
These are all valid points. This is a fundamental issue with relying on non-open 3rd party solutions and (leaky) abstractions. The best solution here would be some standard that the hyperscalers implement themselves, but this is of course incredibly unlikely.
> some standard that the hyperscalers implement themselves
I'm kind of amazed that they haven't already. It would be such a good selling point for Azure, or GCP, etc. "We have a UI like Heroku or Vercel. Compare that to our confusing competitors!"
> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
This hits home so much!
I remember last year when I asked our Cloud Ops to add an additional EC2 instance and adjust sizes on two others. It took twelve work hours and resulted in +3k -2k changed lines "because they had no way of doing it now without merging seven hundred other changes.
Its an anti-pattern that negates some of the advantages of the cloud and re-introduces issues people had when things were still handled by the old internal IT infra department. I‘ve seen it a lot.
That smells like some really nasty problem in your company. If the change was really what you said it was, it might take some time and terraform code (i.e. nested submodules with hardcoded values that needs to support parameters all the way down) but it should not be a diff of that size.
I guess in an ideal world, a service like this would be a layer on top of Terraform. Changes in the admin page would be applied using Terraform, and update the config in your own Git repository. I think this would be much easier to sell, even if they choose to make it "write only" to avoid potential complexity of managing user defined configs.
They could get customers initially by promising a simple start to get "on the cloud", but would keep customers due to support, scaling, monitoring, ci/cd and maintenance. Cheap startups could use it as a one-time tool, but I think a lot would see the added value they bring.
I don't know if anyone here remembers the Ant build system, but writing your own Terraform spaghetti strongly resembles the days of Ant, before Maven came along. Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.