Infrastructure as Code

A seasoned operations engineer have most certainly developed a toolkit of scripts that can be used, with minor changes, to perform all his regular tasks of provisioning and managing the plethora of environments already seen and dealt with over the years. When it comes of configurations, all the admin consoles dealt with are known. He can log in and make the exact tweaks to application server configs that is just what is needed to address the facing issues. He has things down to a routine, knows exactly when the next application release is due, and knows when to expect the next update to the OS. He is the master of his domain. For Database related stuff, he exactly knows who to call and that DBA has mastered his end of the deal as well.

But as systems become virtualized and developers started practicing Continuous Integration (CI), things started to change. The number of environment and their instances to deal with has gone up by several degrees of magnitudes.

Developers now are pumping out updates and new versions through CI builds daily. In fact, multiple builds a day. All of them need to be tested and validated. That requires new environment instances to be spun-up fast. These builds also often come with configuration changes. Logging into consoles to make each one of these changes individually is no longer a viable option. Furthermore, the “need for speed” is critical. Developers’ builds are creating a backlog, as the environments to even just test them on are not available as needed. This is a problem.

Ponder the two terminologies below:

Cycle time – It is defined as the average time taken from the time a new requirement is approved, a change request is requested or a bug that needs to be fixed via a patch is identified, to the time it is delivered to production. Agile organizations want this time to meet the bare bones minimum. It is what limits their ability to release new features and fixes to customers. Some organizations have cycle-time down to minutes! While this is not possible for enterprise applications, the current cycle time of weeks or sometime even months is absolutely unacceptable.

Versioning Environments – The need to maintain multiple configurations and patch levels of environments that are now needed by development, on demand, requires Ops to change the way they handle change and maintain these environments. Any change ops make to an environment – whether it is applying a patch or making a configuration change, should be viewed as creating a new ‘version’ of the environment, not just tweaking a config setting via a console. The only way this can be managed properly is by applying all changes via scripts. These scripts, when executed, would create a new version of the environment they are executed on. This process streamlines and simplifies change management, allowing it to scale, while keeping Ops best practices intact.

The solution to both these needs, minimizing cycle time and versioning environments, can be addressed by capturing and managing your Infrastructure as code. Spinning up a new virtual environment or a new version of the environment then becomes a matter of executing a script that can create and provision an image or set of images – all the way from OS to the complete application stack installed and configured. Hours can become minutes.

Versioning these scripts, like versioned code, in an SCM system, allows for proper configuration management. Creating a new version of an environment now becomes checking out the right script(s) and making the necessary changes to the scripts – to patch the OS, change an App Server setting or installing a new version of the application, and then checking the scripts back in as a new version of the environment.

Automation frameworks

Two kinds of automation frameworks have come up for managing Infrastructure as Code.

  1. Application-Centric Frameworks: These are usually capable of managing App Servers and the applications running on them as code. Such frameworks are specialized with pre-cooked libraries for all the typical automation tasks for the technologies they support. They cannot perform low-level tasks like install an OS, but can fully automate App server and application level tasks. E.g., IBM RAF.
  2. Generic Frameworks: They are not specialized for any technology, and hence can be scripted to perform any task, all the way from installing an OS to patching an application. They require much more work upfront, but can handle any kind of task. E.g., Chef and Puppet.

Business at the speed of DevOps

Infrastructure as Code has become the cornerstone allowing the speed that DevOps demands and the management of multiple versions of multiple environments, to handle the CI builds being spun out by development. Without it, Ops becomes Agile Framework on Waterfall

Advertisements

2 thoughts on “Infrastructure as Code

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: