This a revised version from an old essay about how companies or departments see automation for IT services.

Let’s just define tree essential levels of automation maturity stages with emphasis on how the service is provided and what tools are commonly used.

Level 1: ‘ad-hoc’

An IT organization starts providing its services with a full team of technical people (specialists). Automation at this level is usually “person based“: some specialists could create their script for helping them to carry on with the daily duties.

The key factor on this level is that the service still relays on people: it’s optional for the specialists to use automation as they’re responsible for the results.

In order for scale the service, the company must hire more technical staff, but specialists are scarce and expensive: they need years to acquire the right knowledge and this has its price tag. As alternative, companies usually try to train “junior” profiles or operators to deal with the workload, ending with extensive operation workbooks, complicated instructions… and incidents.

Level 2: ‘software development mode’

For scaling with the advantages of automation, a mental shift is needed: the scripts are no longer “helpers tools”; they must be considered as the primary service providers.

It means that the organization must rearrange: specialists develop the automation components (scripts, launchers or even user consoles), and operators launch the jobs at request. Specialists also deals with exceptional requests, optimization, migrations or any other advanced operation.

The difference for the specialists is delegation: they’re no longer required to run the scripts on request: they can delegate the daily use to operators, freeing them for doing higher value actions.

All software development good practices apply here: use a source code management for all scripts, use a database for storing “data” (configuration), follow a “Software Development Life Cycle” with at least tree stages (testing environment, “UAT” and a stable production), do testing, trace maintenance/feature requests, etc.

Level 3: ‘the cloud’

There’s another level for IT automation: the self-service model that is present all across cloud providers.

Now that the organization has a well established way to offer and evolve IT services in automatic fashion, the next step is to build a self-service console (and optionally an API and/or CLI) so the clients can launch requests on their own.

A key point for this level is the user centered point of view: the team must forget the technical scripting and stuff and build just “a product” (what the users really wants). No matter if your product is some kind of IaaS, PaaS or SaaS, the user must be unaware of the underlying scripting or technology used to provide him the desired result.

Two important components at this level are:

• The configuration management must be really well done: operators can accept to enter the same information on every script execution (for example, the target host name or database where some action is done), but it’s unacceptable for an user to enter the same value that he had already entered or that was previously provided by another request.

• It must include some kind of work-flow engine that allows the team to orchestrate scripting calls and catch any exception or error during the process, returning a meaningful message to the user. On the previous level, operators could follow an execution plan but on a self-service mode the process must run without human intervention.

Tooling

Now about tools.

The first level doesn’t requires any particular one: a simple scripting environment or a programming language is enough. It’s up to the technical staff to use a more elaborate tool, but the basic principle remains the same: the target user base is technical people.

Most Infrastructure as Code tools apply for the second level. They all provide some kind of configuration management (usually plain text files) and some times a source code version for scripting (recipes, etc.).

Finally, level tree tools usually are very complex and expensive, like VMWare’s vRealize and IBM’s Cloud Orchestrator. Both provide a more user oriented service catalog, request forms, and a fairly complete work-flow engine.

Just an opinion

I usually choose Bash scripting for simple tasks, or Perl if it’s needed to deal with more complex processing (specially for log parsing or reports).

My preferred “tool” for the second level is Red Hat’s Ansible suite. It promotes the use of a SCM for scripting, it manages configuration as inventories and “extra vars”, and supports “execution environments”. With the addition of Ansible Tower it also provides a web user console with role based security, a basic work-flow engine, a scheduler, execution (jobs) templates, and more.

Most of the tools for the third level that I’ve seen were in-house made (internal) tools. Some years ago, I tried VMWare’s VRealize suite; and I have a good opinion about it. However, I’m still missing a good Open Source alternative.