tag:blogger.com,1999:blog-15136575.post2125139449813877883..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: The Configuration Complexity ClockMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-15136575.post-63784024023387505042020-12-15T01:15:35.472+00:002020-12-15T01:15:35.472+00:00Oh no, it me :( :( Oh no, it me :( :( geeklindahttps://www.blogger.com/profile/16917852879964673515noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-33895899707878103232020-08-28T16:56:20.730+01:002020-08-28T16:56:20.730+01:00I think there's a way out: Use sqlite for stor...I think there's a way out: Use sqlite for storing configurable values. It's a self-contained file format, it has a way to dump to a reviewable, versionable text representation for tracking, it's fast enough to access online so you can modify things during runtime, it's got a lot of tooling support, it uses a real language, it's extensible, there are specific rules for how to migrate data and if you adhere to the generally advised notion of never directly accessing data through tables and only using views, straightforward migrations of the configurations are possible.<br /><br />If there's a significant drawback it's that the types are a bit too flexible, but not much worse than many other text formats.Dan Nugenthttps://www.blogger.com/profile/17024579990613770367noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-23041004234563793512020-07-16T21:13:00.116+01:002020-07-16T21:13:00.116+01:00Just want to say, its the year 2020 now and I am s...Just want to say, its the year 2020 now and I am still using this document almost 3 times a year to show this same pattern. This is one of those things that hasn't yet changed.Xeno PuTtSshttps://www.blogger.com/profile/00934389605618434836noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-54475210522420603182020-04-30T20:46:05.771+01:002020-04-30T20:46:05.771+01:00Reminds me of Ivan Sutherland's Wheel of Reinc...Reminds me of Ivan Sutherland's Wheel of Reincarnation: http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdfScott Cooperhttps://www.blogger.com/profile/10621655805082979910noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-49324638470570467372017-05-10T14:41:22.972+01:002017-05-10T14:41:22.972+01:00You left out the step where the config values are ...You left out the step where the config values are put into a database. The boss likes Lotus Notes despite the fact it isn't relational and isn't really a database, so that's where config values go. Nine months later he's gone and the team takes the opportunity to move the data to Oracle, except the two people who quit because they hate Oracle. Nine months later Oracle raises prices so the dB gets migrated to SQL Server. Another developer quits because he hates Microsoft.pthttps://www.blogger.com/profile/03776425973161864367noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-62761588041198709542017-05-10T05:09:23.299+01:002017-05-10T05:09:23.299+01:00Awesome post !! definitely could relate to it to s...Awesome post !! definitely could relate to it to some of the projects i had been working on now. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-89385589983558144842017-04-28T02:04:19.903+01:002017-04-28T02:04:19.903+01:00This struck nerve with me. I have been in technol...This struck nerve with me. I have been in technology for over 35 years and I have to say that I have seen this clock cycle, time after time after time. Though I really had never seen it illustrated like this. When ever I am thinking about a new system, the line between configuration and code generally gets a lot of thought. This is really good food for thought!RMKnightStarhttps://www.blogger.com/profile/05266324397464608866noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-33418340298177220062017-04-25T21:01:18.726+01:002017-04-25T21:01:18.726+01:00On UNIX systems, configuration is often done in th...On UNIX systems, configuration is often done in the form of a script that is technically capable of arbitrary programming complexity but whose base case <i>looks</i> declarative.<br /><br />For instance, on one of my FreeBSD servers, /etc/rc.conf starts out with the following lines:<br /><br />hostname="laliari.logiclrd.cx"<br /><br />defaultrouter="184.71.82.245"<br />ifconfig_vtnet0="inet 10.0.0.1 netmask 255.128.0.0"<br />ifconfig_vtnet1="inet 184.71.82.246 netmask 255.255.255.252"<br /><br />gateway_enable="YES"<br />natd_enable="YES"<br />natd_interface="vtnet1"<br />natd_flags=`/root/make_natd_flags/make_natd_flags`<br /><br />(I'd have used a PRE tag for that but blogger.com doesn't allow it!)<br /><br />Everything there looks pretty straightforward -- name equals value, repeat as necessary -- except, whoa, what's going on in that last line? I am actually running an external program to generate the flags to pass to natd.<br /><br />This type of configuration, leveraging a common, system-wide scripting facility, means your users can do simple configuration without ever knowing the system isn't purely declarative, and more complicated configuration can use arbitrary programming techniques. In this example, make_natd_flags is actually a small C application, but it could be absolutely any command-line, or could even be implemented in shell script right inside the rc.conf file.<br /><br />This mode of configuration has been the de facto standard for a <i>very</i> long time, and doesn't seem to be progressing around the clock. Where would you say the clock is stopped for this type of configuration? I find I can't really assign it a position on the clock; it seems to combine most of the advantages of most of the "times" you've described, without suffering unduly from the downsides. The only real problem I see with it is that a user who is terribly inexperienced, or who suffers greatly when it comes to attention to detail, is at greater risk of producing a configuration file with syntax errors, even if the syntax is as simple as 'name="value"'...Jonathan Gilberthttps://www.blogger.com/profile/12533760807956258274noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-80001969407951960792016-03-03T10:40:06.835+00:002016-03-03T10:40:06.835+00:00The example seems to be assuming a single deployme...The example seems to be assuming a single deployment - one binary running in one place, and the configured variables vary over *time* but not over *space*.<br /><br />However, if the packaged binary runs in many places, some values vary depending on where it is deployed: at a minimum things like what datacenter, what user, what backends to connect to, what paths to read from, as well as anything else that varies by user. <br /><br />While "temporal" variations can easily be hardcoded if you have a short release cycle, "spatial" variations are not so easily hardcoded: you end up maintaining a source branch for each active variant.<br /><br />And then what do you do if the spatial variations are enormous: a huge amount of information that differs between deployment? <br /><br />Then you might consider hard-coding the spatially varying part separate from main application which does not vary: write a separate piece of code that generates a structured data format with all the config information, which the main application slurps in. <br /><br />I suggest having three marks on the clock for such data: <br />12: nothing varies spatially, everything in main code<br />3: separate a few flags varying spatially (--input_path=/somewhere)<br />6: structured data format for a larger number of spatially-varying parameters (protobuf, INI, JSON, XML). <br />9: DSL, to generate the structured data. Skip this if at all possible!<br />12: Full-fledged programming language to generated the structured data.<br /><br />For the things that vary temporally (having the same value in all deployments), now you have a choice of whether to hard-code it in the main application, or move it in to the config data, based on whether it changes more or less frequently than the release frequency of the main application.Graham Poulterhttps://www.blogger.com/profile/16072516650932490004noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-36281548160085741362016-02-07T05:51:51.920+00:002016-02-07T05:51:51.920+00:00Perhaps if you use Common Lisp, the circle collaps...Perhaps if you use Common Lisp, the circle collapses to a point.<br />Christopher Hooverhttps://www.blogger.com/profile/05479636752592300779noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-65704545488866451212015-10-18T12:18:20.437+01:002015-10-18T12:18:20.437+01:00Great post and I recognise this pattern. These day...Great post and I recognise this pattern. These days I use Octopus deploy as part of a one-click deployment pipeline and it does help minimise the pain when you need to either update config or have hard coded values in your app. Anonymoushttps://www.blogger.com/profile/00651108358845555553noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-63890026514830665892014-09-23T18:42:13.497+01:002014-09-23T18:42:13.497+01:00I love it. This is very similar to a pattern I'...I love it. This is very similar to a pattern I've been thinking about for a while -- call it the Configuration Complexity Pendulum.<br /><br />Year 0: Everything is done in code. <br /><br />Year 1: Clever Programmer A realizes that he's writing the same code over and over. He parameterizes the code and moves the parameters into a configuration model. <br /><br />Year 2: Requirements become more complex. Configuration model becomes more complex, and starts incorporating conditionals, exceptions, triggers... <br /><br />Year 3: Clever Programmer B realizes that the XML has become a programming language in its own right -- a terrible one that takes 20 lines to say IF A THEN B. She starts writing an API or a DSL...<br /><br />And thus, we swing back and forth between code and config, forever.Steve Mhttps://www.blogger.com/profile/06626205218290678525noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-28521037179528435262013-06-24T22:40:58.726+01:002013-06-24T22:40:58.726+01:00Nice. Its probably the best to develop some nice d...Nice. Its probably the best to develop some nice devops solution in order to make deployment trivial and hard code things.<br /><br />You need easy deployments anyway.majkinetorhttps://www.blogger.com/profile/09268214549525093107noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-14457488544762986742013-01-01T14:18:59.090+00:002013-01-01T14:18:59.090+00:00Great post! Racing around the clock because you fe...Great post! Racing around the clock because you fear recompiling and redeploying, making this easy from the beginning, makes most of this problem go away. HolyTshirThttps://www.blogger.com/profile/17940288175611154760noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-86867359836848348622012-08-02T11:26:38.119+01:002012-08-02T11:26:38.119+01:00Mike - great post. I think it's dangerous to ...Mike - great post. I think it's dangerous to change config values on the fly. People can get it wrong and will bring down the app. So hardcode the values if you like or put it in a config file or whatever else - just make sure that you treat the change as any code change and run your full suite of tests before you deploy it. If your build and deploy process is solid it is no extra overhead to retest and deploy.Marc Zimanhttps://www.blogger.com/profile/01281306154660757294noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-33947201922346722732012-07-05T14:26:32.251+01:002012-07-05T14:26:32.251+01:00Awesome post :-), it supposed to be called "T...Awesome post :-), it supposed to be called "THE DOOM CLOCK" ;-)Bartosz Adamczewskihttps://www.blogger.com/profile/10017444373869046159noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-10120778809894387002012-05-08T08:54:30.531+01:002012-05-08T08:54:30.531+01:00Great post Mike- oddly I saw it as a link in Googl...Great post Mike- oddly I saw it as a link in Google+ from Mark Seemann. Then I thought Code Rant- that sounds familiar. I then woke up. :-)Richard ODhttps://www.blogger.com/profile/13855706515612188950noreply@blogger.com