There is an increasing trend for opinionated tools and APIs. The designers have a clear idea on the “correct” way to solve a problem, building on established good practice. They make it easy to follow their guidelines. By design the tools/APIs may be limited in certain areas or make it difficult to stray from the intended usage. Examples are Apache Maven, Ruby on Rails and Yeoman.
Some of this may be attributed to the increasing use of Behavioural Driven Development. Starting with the intended goal in mind and building incrementally towards the desired outcome. The end result can be an elegant experience for the end user.
Re-usable DevOps components should be similarly opinionated. There is a balance between providing the conventions for an “appropriate” installation, and the flexibility to make them re-usable across all projects. Rather than simply providing the various configuration files to configure a particular piece of software, it is simpler for the end user to provide a set of configurable properties. Constraining all the possible different “configurations” to an intentional subset. This makes managing a large complex environment simpler – providing appropriate levels of abstraction to hide the implementation details of a particular piece of the infrastructure. Too many configuration options will make it difficult to maintain. Too few makes it too inflexible to be useful.
Taking a Behaviour Driven Infrastructure approach can lead to better abstractions and simpler configuration. For more complex configurations, it can provide the user a suitable starting point.
By way of example, consider configuring HAProxy. HAProxy is a fast and reliable Open Source solution for high availability, load balancing, and proxying for TCP and HTTP-based applications. I won’t go into the details of HAProxy and it’s configuration here, but HAProxy has nearly 700 different configuration parameters leading to a huge number of possible configurations.
A common use case for HAProxy is load balancing HTTP traffic for a single application site. In such a situation there are three basic scenarios to consider:
Rather than providing variables to configure each parameter individually, which places the burden of knowledge on the user and creates a large amount of work to capture and maintain, we can provide two simple configuration parameters:
Depending upon the configuration scheme chosen, there may be additional parameters we need:
With this small set of configuration options we can produce 3 quite different configurations to deliver the desired behaviour. There are obviously other configuration options, such as the version of HAProxy that would be required for a full solution but we have been able to condense the huge number of individual configuration options into a handful of options to produce a coherent configuration
By starting with the end in mind, using opinionated DevOps we can develop simpler systems.
Tim is an expert BDD and automation consultant. He plays a key role in building our frameworks.