This is the second part of my thoughts on good operational software. For part one, go back one post to here.
Second, is separating out configuration management from software development. Like logging, this one is easy on the surface; it’s pretty trivial to separate out the main configuration parameters into a configuration file rather than hard coding everything. The most interesting thing about this, however, is that it exposes dependencies in an explicit way. For example, if an application is dependent on a database connection, then there must be configuration related to that database – the host, port, database name, user, and (hopefully encrypted or obscured) the password. Continue reading Good Operational Software – Part 2→
As the Operations lead, I find myself pondering what the difference between good software and good operational software. The software development team here at NSIDC is a sharp group, they know good software when they see it. Further, many of them know software that is not good operational when they see it. But, as a technical group, I don’t think we’ve all nailed down what set of features we can use as a benchmark for “this makes the software operational.” As far as I can tell, these things vary depending on the project, and, like Science Fiction, “good operational software is best described by pointing at it.”
That being said, by way of getting some ideas out there, there are three things that I have noticed I consistently point at and say, “that makes this software operational.” Continue reading Good Operational Software – Part 1→
Thoughts are stripped of their texture to form words that they might be colored by the mind of another.
