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.
- Responsible benchmarking
- Understanding hardware still matters in the cloud
- The “network partitions are rare” fallacy
- Messaging and event sourcing
- Further reducing memory allocations and use of string functions in Haywire
- HTTP response caching in Haywire
- Atomic sector writes and misdirected writes
- How memory mapped files, filesystems and cloud storage works
- Hello haywire
- Active Anti-Entropy
- Lightning Memory-Mapped Database
- Write amplification
- Amortizing de-duplication at read time instead of write time
- LevelDB was designed for mobile devices
- AMQP and wire format interopability
- Convergent Replicated Data Types
- Configuration is bad but what about operational flexibility?
- An alternative to Paxos, the RAFT consensus algorithm
- Version tolerance and accidental operation complexity
- Hardware configurations can introduce tight coupling and increase failure foot print
- November 2013
- October 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- January 2013
- October 2012
- September 2012
- August 2012
- May 2012
- April 2012
- February 2012
- January 2012
- December 2011
- September 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010