Imperative Automation Application, use cases, and limits
Introduction
Imperative automation has been used forever, it is the most basic, easier and straightforward automation methodology. Imperative Automation is putting all the known steps to perform a task in order, one after the other, so at the end of the run you achieve your desired output.
Imperative Automation is based on simple, flexible tools but that are complex to use; and believe me, Imperative Automation complexity grows exponentially, since any intelligence (i.e: error handling, retries) must be implemented by the person working on the automation code; and as we all know, sometimes that kind of code is write-only.
Imperative Automation strengths and best use cases
If we think about Imperative Automation's best characteristic, is its flexibility; you are not constrained by a specific use case, tooling, platform, or even language to implement it. You can write Imperative Automation in pretty much any language you are comfortable with that can issue the commands required and your target platform supports.
Another powerful argument for using Imperative Automation is when the project's scope is not enormous or if it's a one-shot thing. There are moments when it just does not makes sense to set up something like a complete terraform with ansible deployment to test some software that you are not even sure covers your use case; or installing a couple of dozen dependencies to compile something for your workstation.
Declarative Automation tools most likely ignore legacy applications and platforms; for example, not so long-ago Digital Ocean did not support Terraform or Kubernetes.
Also, there are cases where something cannot be expressed as an end state, and you cannot create an end state for a QA process that states, "get this piece of software error-free."
Finally, another good use case for Imperative Automation is where complete control over the software and sometimes secrecy is a must. One and maybe the simplest example of this is the military, where you cannot rely on a 3rd party to have access or control over how you perform some processes. Other are mission-critical infrastructures that, many times over, are a mix of highly tested legacy systems integrated into newer ones that must not break on an update triggered by a 3rd party.
Imperative Automation drawbacks
As we mentioned before; maintaining a big piece of Imperative Automation code is a considerable effort, especially when you get closer to 1000-ish lines of code.
Usually, Imperative Automation has a linear logic of execution, and even when you can build some intelligence into it, any small change to the logic has the potential to break the automation completely, don't ask me how I know.
It has been my experience that Imperative Automation likes to surprise you; small changes that broke something wait to manifest themselves until the worst time possible. Unforeseen problems also pop up because testing Imperative Automation is complex and very time-consuming, and sometimes you need to do more things, overconfidence bites you in the rear, but that's not Imperative's Automation fault.
Another experience of mine was receiving a big piece of Imperative Automation that I have never worked on, expecting me to "make a small change"; this is one of the worst scenarios possible. Probably not documented, not even the logic of what is supposed to do; the only way forward in these cases is to reverse-engineer it and fail and fail and fail until it does not fail anymore.
Conclusion
Imperative automation has its applications where it's the perfect technical solution, but nowadays those cases are very specific ones.
- We can say that Imperative Automation is best when:
- There is no software already created that solves your problem.
- You need less than 1000-ish lines of code to achieve what you want.
- The expected complexity growth is low.
- Declarative Automation does not support the target platform.
- It is a one-time task.
- Having absolute control over the tooling is required.
- Some essential features are not supported by any Declarative Automation tool.
- It is an in-house tool, well-documented or well-developed, and well-known by the organization.
- It is a legacy tool key for the business.
In our next blog article, we will discuss the hottest technology, Declarative Automation, and draw our conclusion on the subject.
Make sure you follow us not to miss it!