How infrastructure as code benefits and eases provisioning

Following the script

Treating infrastructure configurations as code is a major benefit of the approach. It means that you're writing the code to provision infrastructure on demand, which then allows an organization to merely execute code and automation to build infrastructure from scratch. This approach, which is sometimes described as configuration as code, delivers an important advantage: flexibility. An administrator can run a script instead of racking a physical server. Since this script is code, it's simple text -- and easily modified.

One way engineers can take advantage of infrastructure as code benefits is to provision services without worrying about the platform on which those services will run. Similar to the cloud model, it allows organizations to define services via a declarative nature rather than an iterative one.

Engineers can use infrastructure as code to provision services without worrying about the platform on which those services will run.

An engineer who needs a new web service, for example, no longer needs to spend countless hours on Google to learn how to install each kind of web server. Instead, the engineer can declare that a web service is needed, provide some parameters, and the code will decide where to place the service and how to configure it.

You could build your own infrastructure as code solution, but most use tools such as Puppet, Chef, Ansible or SaltStack. Each of these tools has its own way of defining infrastructure, and each allows an administrator to define a service without worrying about all of the if-then logic necessary when deploying to heterogeneous environments.

For example, the creation of an Apache web service in Puppet might look something like this:

class apache2 {
    package {'apache2':
            ensure => present,
    }

    service {'apache2':
            ensure => "running",
            enable => "true",
            require => Package["apache2"],
    }
}

In Chef, it would look something like this:

name "webserver"
run_list(
    "recipe[apache2]",
)
default_attributes(
    "apache" => {
    "listen" => ["*:80", "*:443"]
    }
)

You can see there's no code checking whether a service already exists (if statement), nor are there Apache-specific configuration values. All of that logic has been abstracted away in the tooling. Using configuration management tools allows administrators to define declaratively what they want the infrastructure to look like. The tooling makes it happen.

Say, for example, an administrator doesn't want to limit herself to deploying Apache and needs to build some kind of dynamic script. She can use configuration management tools or a script of her choosing. The concept of infrastructure as code is generic and isn't tied to a particular tool. She could write a simple script, such as the one below. Once the workflow is defined, she's then free to incorporate this logic into a configuration management tool or a script of her choosing. This is an example script in PowerShell, but the same logic could be applied to any language or tool:

## Parameters to pass to the script at run-time
param($EnvironmentName)

## Source of server names mapped to environments
$environmentServers = @{
    Production = 'SRV1','SRV2'
    Test = 'SRV3','SRV4'
}

## Discover the servers available
$targetedServers = $environmentServers[$EnvironmentName]

## Small function to determine operating system
function Get-OperatingSystem {
    param($ServerName)

    ## Code to determine operating system here and to output either Windows or Linux
}

foreach ($server in $targetedServers) {
    if ((Get-OperatingSystem -ServerName $server) -eq 'Linux') {
        ## Deploy Apache
    } elseif ((Get-OperatingSystem -ServerName $server) -eq 'Windows') {
        ## Deploy IIS
    }
}

Infrastructure as code benefits from logic

By using code, you can define all of the logic and rules ahead of time to determine what kind of web server to deploy to various servers. By just calling this script using a single line of code, (see example below) you can intelligently and automatically deploy any kind of web server to any environment:

.\Deploy-WebServer.ps1 -EnvironmentName Production

By designing our configuration in such a way to be idempotent, you also don't need to worry about the state of environments (such as production or test.) Simply run the script, and it follows the logic you've built.

In this example, we essentially built the infrastructure as code ourselves. But this kind of task comes pre-built with configuration management tooling, making this process even easier.

Developers aren't limited just to software anymore. Infrastructure developers are on the rise, and the demand will be high for anyone who can understand how to develop the logic and rules associated with infrastructure deployment and management. By understanding the concept, talented engineers will see that infrastructure as code benefits an organization and that they can adapt it in many useful ways.