Part Two | Practice makes Perfect

Testing, testing, testing, and more testing. Lets get this show on the road!

If you missed the introductory post to the series, check it out here, and you can find part one here.

3-24 hours

Tools are a critical piece of a DevOps solution and, by this stage, you should have a short list of them that seem to be suitable for both the selected server and your enterprise at a whole. Now's the time to dig in a little deeper to see which will be worth a more time-intensive proof-of-concept.

If you were shopping for cars, this would be the equivalent of a test drive around the block. If that's too bumpy of a drive, or you just really hate driving stick shift, then it's simply not worth taking the car home for the entire weekend.

Some tool vendors offer a self-guided tutorial that you can use after a download, whereas others will have salespeople give a live web demonstration. Both types of assessments should take about the same time (1-2 hours), and both should accomplish the same goal: not necessarily finding which tool will be "the one", but finding which tools will definitely not.

When doing a self-guided tutorial, make sure not to conflate the assessment with the next stage, the proof of concept. The assessment should be focused on finding an overall solution, not the server selected in the first stage.

To make this step easier, here's a comprehensive list of the top Infrastructure as Code Tools as of 2016.

16-40 hours

If the assessment was a test drive around the block, then the proof of concept is loading up the car with your family and pets, and then taking a road trip. At this stage, it's not just about finding the right tool, but discovering and defining the processes you'll use around the tool.

Because this will interact with the various servers that are in this role (and it's important to demonstrate actual value to production, or as close as possible), there will be slight risk involved. The tools will need to be installed, firewall ports may need to be opened, permissions and service accounts may need to be created, and so on. However, this slight risk comes with a fair reward: it'll give a feel for what is actually required to start automating your infrastructure and it server configuration.

To mitigate some of this risk, the proof-of-concept may be split into two phases: pre-production and production. Only upon completion of the first phase would the proof-of-concept be allowed to continue to the second.

An organizational change is as much one of hearts and minds as it is the tooling and processes. This stage will also give you a feel as to the resistance and hesitation to change, as well as any perceptual leaps that need to be made.

Thus, it's equally important to involve and interact with the actual people who configure the infrastructure: testers, business analysts, network engineers, developers, etc. Just as the risk to automation can be mitigated with a multiphase proof-of-concept, so can overcoming the resistance to change: only upon completion of one phase of the proof-of-concept would the solution be introduced to another person or team.

The Intro

Part One

Take me to Part Three!

Check out Inedo's Infrastructure as Code Tool

Otter is a modern infrastructure automation tool, both visually and functionally, that utilizes Infrastructure as Code to help teams and enterprises with server management & orchestration automation.

Don't wait! Read the entire incremental approach now!

Download the full guide Incremental: Infrastructure as Code for FREE.