Traditional software development for monolithic applications has always required additional operational tasks to be performed and is never as simple as build, ship, forget. Every organization (or even each individual application) will have unique tasks that are required to run the software, such as initialization and bootstrap logic, bespoke middleware configuration on a server, or even setting the correct default time zone on a server. In the past, these tasks were performed by one or many scripts that were either found on the servers themselves or hosted externally and placed on the server for execution. These scripts often perform critical tasks that are required by the application so that it can function correctly.

One of the major problems with this is that it makes these scripts intrinsically bound to both the application and the server on which the application is running. For example, say you have a Java-based application deployed on a Linux server and a .NET-based application deployed on a Windows server. Both of these applications would require some initialization once they'd been deployed to the server and, despite how similar their initialization is, the script would be completely different and would have to exist on both servers.

To achieve greater reusability of our automation scripts, we can externalize them into generic configuration directives that are run by a configuration management broker. We'll take a look at this in the next section.