4 ms·
I think the problems are mostly around configuration that is so complex and redundant that we need programmatic abstractions to deal with it—we need something l
by weberc2 7y ago
I think the problems are mostly around configuration that is so complex and redundant that we need programmatic abstractions to deal with it—we need something like a general purpose programming language to DRY up and simplify that configuration, but the powers that be are clinging desperately to YAML (despite encoding a shitty, half-baked AST on top of it a la CloudFormation or “generating” YAML with text templates a la Helm) as the human/configuration interface presumably because the “it’s as easy as YAML!” is such a good marketing schtick.
A certain amount of configuration complexity will always be there, but there’s still a lot of incidental complexity that could be cut away if we just generated these config a with a general purpose language.
- imtringued 7y agoThere are worse things than YAML. Dealing with hundreds of snow flake configuration formats that do not follow common sense rules cost me more time than working around mistakes in YAML. There are obviously some really, really stupid ideas like generating YAML with text templates but the problem isn't with YAML. It's the tool that generated the YAML file.
- chucky_z 7y agoHCL2 feels like the farthest ahead right now, if you don't want to deal with straight up python or ruby.
- greyskull 7y agoIn case you haven't seen AWS' answer: https://github.com/aws/aws-cdk https://github.com/aws/aws-cdk