The Fallacy of “Configuration-less” Systems
This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!
The risk of untracked infrastructure #
The idea of a cloud service provider is amazing for many reasons. On-demand server instances was just the start - in the last few years, there’s been an explosion in easy-to-use services that manage tasks which were once difficult.
To run a PostgreSQL database, you used to provision a server, then set up and run your DB. For large amounts of non-DB data, you’d configure and run HDFS on a Hadoop cluster. And to capture streaming data, you would run a Kafka cluster.
Now there are many easier options that, at the end of the day, are way more cost-effective. Spin up an AWS RDS instance for your DB, use Azure Blob Storage for big data, and set up a Google PubSub topic for streams.
Nearly every example of these systems has a “Hello World!” example which will get you up and running in just a minute or two. Unfortunately, this lures many in to a false sense of security. The logic usually goes like so: “We would use some sort of configuration management, but we don’t really have a configuration because we used the setup wizard/UI.” There’s an underlying assumption that a simple setup implies a repeatable setup.
This has led to what I call the Fallacy of “Confguration-less” Systems. It is a mindset that ensues when a junior engineer or non-technical manager believes the services they are using to be so simple, that no automation - or worse, documentation - is required.
Worst Case #
Let’s look at a real-life case of where belief in a “configuration-less” system led to lost business time.
A developer used a UI-based deployment system for Docker to set up a simple application for a collaboration with another department. A non-technical manager wanted to make a change, and figured he would “just use the UI to figure it out.” He accidentally deleted the entire application. The developer re-created it, but with a one-letter difference in a parameter that wrecked the integration.
A net two business days were lost trying to find the problem.
Best Case #
Now let’s look at how this story may have been different with a bit of configuration management.
When creating the application, the developer spends an extra hour copying an automated deployment pattern and documenting the deployment as code. When the manager wants to make a change, he either puts a story on the Kanban board, or opens a pull request himself. If, somehow, the application does get deleted (most UI functionality should be locked-down if using configuration management), then re-running the automated deployment puts the app up exactly as before in minutes.
Getting the Configuration Mindset #
If that story did not scare you, either you are already managing your configurations appropriately, or you will only be convinced when it actually happens to you (in which case, best of luck, there’s nothing I can do to help you). If it did scare you, here are some steps to help ease yourself into this new world:
- Remember, “configuration-less” is more “less configuration”, not “no configuration" - no platform, service, or system out there is truly configuration-less
- Start simple - no need to automate everything at once. If you manage configurations via UI, begin by taking screencaps, or recording a video whenever you make changes.
- Begin learning common tools - there are many configuration management tools out there, but Ansible is a good place to start. It’s base functionality can cover most cases, but can also be extended if needed. Also, Gitlab’s CI/CD pipelines are marvelous if you just need a bit of shell scripting. Stay consistent - you will feel slowed-down at first, try to remember that the payoff will come later, either for you or for another developer.
Good luck, and may your configurations always be consistent!
Feel free to connect with me!
- www.linkedin.com/in/jeremiah-coleman-product
- https://twitter.com/nerds_s
- jeremiah.coleman@daasnerds.com
- https://github.com/colemanja91