Configuration is riskier than code

Description

Over 10 years ago, Puppet Labs and others espoused the idea of “configuration as code,” setting a course that crossed DevOps, the API-ification of systems, the cloud, and serverless. Today, you can write a few lines of config and invoke thousands of CPUs, doing hundreds of operations, deploying entire clusters of systems—a huge force multiplier for IT operations.

This force multiplier comes at a cost, and that cost is risk and impact. Never before has it been so easy to turn off an entire content delivery network (CDN) with a single command. While numbers vary, studies show that a majority of incidents in IT operations are caused by configuration changes. Configuration is code, but lacks the same rigor that code receives. Configuration formats like YAML and JSON do not have the same quality of syntax checkers and debuggers that languages like C++, Go, and Ruby have. Often, the only time you know that a configuration is semantically correct is after it’s running in production.

Jamie Wilkinson examines this problem with universal Turing machine (UTM) theory, so you can see why configuration should be treated exactly as code, but also why that’s more difficult. You’ll explore what other practices—like progressive rollouts and minimization of the “control surface”—you can apply to manage the increased risk associated with configuration.