Automation

Automation is a very loaded term. First thing to do is define it. Then work to deliver what is defined. There are requirements that must be met before you can automate anything. Those requirements are the following:

• Use Case Definitions
• Standardization
• API availability
• CRUD
• Least privilege(security)

Lets dive into each of these defining them and exploring what they really mean.

Lets define automation first.

Automation is programmatic process that requires no human hands-on intervention.

Now lets cover the things that are necessary in order to implement automation. Those items mentioned above.

Use Case Definitions

In order to automate, understanding who the user is, what the user wants to accomplish, where the user is in relation to the automation, why the automation will be initiated and lastly the how of it is necessary. Generally the user is quite often another process. That other process may only require a subset of what the total automation has to offer at any given invocation.

As a result the use cases should include the the who, what, where, why and how of it all. Be specific and understand the error conditions of each use case and what should happen as a result of an error. Beyond that what should happen as a result of success. What is returned? What is logged? What is stored?

Defining the use cases will help in determining if what is being asked has been standardized yet. Lets go into that now because honestly, if it hasn’t been standardized there is no real point in attempting to automate yet.

Standardization

Automation cannot be applied readily to things that have not been standardized. Sure, a particular action may be scripted, but that is not really automation is it?

If everything being done is bespoke or unique to itself then it is not a candidate for automation. Prime targets of automation are things that are repeatedly done over and over in the same exact fashion with potentially new arguments being provided. For instance, user account creation. The same things must happen every time, but the username and some other details may be provided for each execution may be different. What happens on success is widely understood as is what should happen given an error occurs.

Generally, once something has been standardized, its requirements, actions and results both positive and negative are well understood. This usually comes as a result of the activity being performed over and over again. Once that is happening, the activity gets a standardized interface. Thats next.

API availability

In order to meet the goal of being programmatic (mentioned in the definition of automation) the tooling involved must have an available API (Application Programming Interface) that allows for its use via a program or script. This API likely must at minimum implement what is commonly know as CRUD, or Create, Read, Update, Delete. In automating something, an interface is being created for the purpose of performing an activity repeatedly in the same fashion.

There are lots of choices to be made at this point. For instance, programming language. Will the interface be RESTful? Will it be delivered via a container? A plugin perhaps? A complete binary fork of the original tooling with the addition of the new automation API? Those considerations are beyond the scope of this post. Instead lets focus on CRUD.

CRUD-Create-Read-Update-Delete

Any API being used to implement automation activities that drive processes to standardized methodologies needs to implement CRUD. CRUD represents the lifecycle of any given activity in its most basic form. Each piece of CRUD can and likely will have variations of actions underneath the covers. There may even be defaults built in for each activity that may be overridden if desired. Or it may be beneficial to have no default and force configuration prior to use of the API implementing CRUD.

Things to consider for each can follow a rather standard set of things. For instance, to use a CREATE in the API being implemented the interface must understand what is to be created, how to create it, what success looks like, what failure looks like, what to return to the user in either case, and what to do with its output entirely. Same sort of thing goes for the rest.

Least Privilege

Lastly you want to implement automation using the least amount of privilege necessary and perform each action with the level of security within the bounds of what is acceptable risk for the organization and the activity being automated.

This may employ encryption and elevated user privileges among other things. Use an abundance of caution. Consider how the interface to this automation may be misused if it becomes available to the wrong party with potentially elevated privileges.

Conclusion

There is a lot that can be discussed around automation. AI has become a hot topic in the space. No-Ops, Git-Ops, Chat-Ops, etc.. These are all methods to interact with underlying automation that needs to have addressed at LEAST the above requirements. Automation gets delivered in all sorts of ways, RPM, DEB, Docker, Ansible, Shell. As with anything in tech, what matters is that the requirements are met, and that the product delivers on those requirements in such a way that it is usable, functional, extensible, and lastly manageable for its life cycle. Automation is fun! Don’t look at it as a threat, look at it as an opportunity to make our systems earn their keep and free time up to do more interesting things in the future. Potentially even creating more automation. :)