Today I got a bit closer to a meaningful definition of automation, as it applies to the software development process. I’ve been turning this concept over in my head for a while, which is partly related to the dreaded question of licensing.

Why Should Licensing an Automation Product Be Related to the Number of Users?

A few weeks ago, I was chatting a bit in the SQL Server Community Slack Channel. One community member was frustrated with running into situations with per-user licensing for monitoring and automation products.

This isn’t the first time I’ve heard grumbling about per-user licensing, of course: with any licensing model, you’re going to hear grumbling about it, that’s just how licensing goes.

But I think per-user licensing can make a lot of sense when it comes to automation products, because of the nature of automation. I work for Redgate, which does per-user licensing. I also often do demos of how our tools integrate with Microsoft’s Azure DevOps Services (formerly VSTS / or TFS-in-the-cloud), which does licensing based on user numbers.

But not everyone thinks this makes sense.

That’s because they see automation as:

• Something that one person sets up on a server, which that person may occasionally tweak; and…
• A script or orchestrated set of scripts and products that replace the work that people (maybe more people than the person who set it up) would do manually

This definition isn’t dumb or naive at all. This is classically what automation has been in IT for many years: I’ve got a problem. I create a script. The script helps save me and my team some time and I only ever look at it again if it stops working.

Based on that definition, it would seem most natural way to be charged for automation tools would be based on something like the number of times the tools are run, the number of servers/cores they are run on, etc.

The Nature of Automation Has Changed Dramatically in Recent Years

Like I said, I’ve been having a hard time putting a definition of what automation means now into words. Then I saw a link to this job description for a Sr. Resilience Engineering Advocate at Netflix.

There are a lot of interesting things about the job description, but one sentence that leapt off the page to me was that the team values:

Automation as a team player versus automation as a replacement for humans

Netflix Cloud and Platform Engineering SRE Team

This is a huge part of the evolving definition of automation. Automation is now:

• Something that a team configures, interacts with, and improves on a daily basis
• A script or orchestrated set of scripts and products that are an integral part of the productivity of the team

The big reason that per-user licensing makes logical sense to me when it comes to tools that are designed to be a key part of the software development life cycle is that the tools are meant to be experimented with freely. The tools will work best if they’re able to be tinkered with and adapted over time, to suit the needs of the team at that point. Licensing based on cores or CPU cycles or usage naturally reduces experimentation if it is going to drive up cost.

Also, the tools are meant to be team players: they are meant to be available to have every team member interact with them. Automation in the SDLC for database changes doesn’t mean that every time a change is committed, the change rockets toward production without a human being ever needing to think about it again. Instead, automation is a player in a process that can absolutely include rigorous review (both automated and human-powered), testing, and even approval gates when needed.

Automation Looks Different in Different Teams

One observation: team size matters. If you’re one person in a small shop and you’re setting up automation to reduce the amount of manual work that you personally have to do, this high-faultin’ definition of automation as a “team player” probably isn’t going to resonate with you. You’re much more likely to continue to see automation in the classically defined sense.

But, on the other hand, you don’t have to have a team nearly as large as Netflix to start seeing the advantages of thinking about automation differently. It just takes a few people working together collaboratively and thinking about how to more consistently and reliably deliver values to customers to start changing the way automation exists in the workplace.