Configuration is bad but what about operational flexibility?

By kellabyte  //  Firehose  //  2 Comments

I wasn’t around during the days where services and applications had big heavy configuration files that configured things like messaging middleware, IoC containers, web frameworks, and many more. But I can definitely feel that there is a large sense of negativity around configuration driven frameworks and that the community has shifted the pendulum away from these approaches.

I think at the end of the day, programmers will usually always have a bias to doing things in their programming language oppose to outside. We see this shift happening in some databases and how all these frameworks have tried to eliminate as much configuration as possible.

Nobody likes a gigantic XML document of configuration that describes how a WCF service wires up or some messaging middleware routing is configured.

There’s a huge problem though when all of this is eliminated. Operational flexibility is missing.

A few days ago I wrote about how a tightly coupled situation increased operation complexity. That situation was multiplied in difficulty due to the lack of ability to dynamically re-configure these systems.

One option and a really good idea for services is to provide a command set that you can use to tell the service to do things you need like re-configure routing. This becomes really useful for operation teams against production systems.

In some cases the changes you make will need to be persisted so that if the service restarts it doesn’t revert back to the old behavior.

But haven’t we just made a really complicated glorified configuration file?

It seems our industry bounces from one extreme to another all the time but we never quite settle in a middle-ground which means we lose some value that can be extremely important.

If you are still dead against configuration files, at least provide the operational flexibility in some fashion.

I hate configuration files too but I value my system availability and operational flexibility much higher than my personal preferences and inconveniences.

  • Gene Hughson

    Well said. While there is work involved (and certainly pitfalls as well) in maintaining configuration-driven systems, the ability to heal a system without coding is critical.

  • Mark T

    The problem with making configuration changes directly on a production system is that it can lead to snowflakes. Also the system may be running in a state that hasn’t been thoroughly tested.

    If continuous delivery is being practised, it should be possible to make the change, commit it, run it through the CD pipeline (along with all the tests) and then deploy that change into production. This allows flexibility whilst still having confidence that the change being made isn’t going to break anything