Next on my list of big changes I have seen over the last 5 years in IT is a tremendous growth in what I call meta-configuration.
Not too long ago, configuring an IT system/application was a matter of changing settings in a small handful of configuration files.
Today, the complexity of the application deployment environments is such that there are typically way too many config items to manage them in the traditional way of having a build/install tool write out the config settings as the application is being stood up.
Instead, we now have a slew of new tools in the web-dev stack whose job in life is to manage all the configs for us. Salt is one example.
The fun part about this is that these tools, themselves have configs that need to be managed:-) Some infinite regress ensues that is highly reminiscent of Escher.
This is only the pointy-end of it though. Getting your app deployed and running. The other part of it is the often large and often complex set of bits-and-bobs you need to have in place in order to cut code these days. This has also become so complex that meta-config tools abound. E.g. tools that config your javascript dev enviroment by running lumps of javascript that write out javascript...That sort of thing.
As soon as you move from apps that write out declarative config files to apps that write out .... other apps ... you have crossed a major rubicon.
It is a line that perplexes me. There are times I think it is dreadful. There are times I think it is amazing and powerful.
Dick Sites of DEC once said "I would rather write programs to write programs, than write programs.".
One one hand, this is clearly meta-programming with all the power that can come with that. But boy, can it lead to a tangled mess if not used carefully.
Be careful out there.
No comments:
Post a Comment