In this series of blog posts I am discussing aspects of Enterprise Application Configuration and how we have come across and resolved issues in real-life mission critical systems.
When I talk about Enterprise Applications, I generally refer to applications that are (a) mission critical and (b) distributed across multiple machines. Sometimes (c) geographically dispersed across different data centres also applies.
In this post I’m going to look at the configuration lifecycle.
We’ve all been there. A fix or update is needed. “Just hack this text into the web.config and restart the website, it’ll all be OK.”
(only for things to be distinctly not OK at some point later when this change gets regressed by the next deployment)
The problem here is that configuration needs to have some kind of deployment lifecycle, allowing configured values that are intended to be updated outside the application deployment lifecycle to be modified, but in a manner that gives you some control. In this context the “modify-on-the-fly” approach needs to be consigned to history.
When I talk of configuration data that varies outside of the application lifecycle, think of things like shipping rates in an eCommerce site. If the shipping rates change you shouldn’t have to redeploy your entire site. Similarly, it’s a bit much to go writing database tables for configuration such as shipping data because the data is essentially static. You could have a single JSON, YAML or XML file with this information in it, and simply update the document when required.
What you need is for your web nodes to detect that there has been a configuration update and refresh their configuration as required. Seamlessly. Controlled.
At 345 Systems we’ve been working with large-scale enterprise systems with exactly this type of scenario. This is why we’ve developed the cloco Enterprise Application Configuration software, which is a flexible Configuration-as-a-Service API + tooling, allowing developers to build configuration updateability into their applications and support processes.
We think that developers need to think closely about configuration data at design time, specifically to separate the configuration settings that are truly deploy-once (such as a connection string, although even that is debatable) from the settings that are intended to be updated regularly, even if infrequently.
We think that the tooling for creating, deploying, reading, validating and updating this configuration data should make it easy for developers and easy for administrators to put in place a configuration lifecycle that improves their application and business agility.
We invite you to read the overview of our product, cloco, and consider how this might solve configuration problems that you encounter in your applications. We’d also like you to let us know if there are any aspects of the application configuration lifecycle that we haven’t thought about, where we could enhance cloco to be even better.
