The software operator design pattern: disadvantages – part 5

The software operator is a design pattern – it is a proven design that has been applied in many situations, implemented by several frameworks. As such, we can discuss its different consequences.  This is important, because software developers and IT architects need to know when a design is a good choice, and when it’s time to avoid it. Previous blog posts have discussed the design pattern in various ways:

This part covers the disadvantages of this design approach and contributes to the larger discussion about operator design patterns.

Disadvantages are a warning, not a failure

It’s important to understand that disadvantages are a warning. The disadvantages of a design approach may be irrelevant to some use cases. For others, they can result in huge efforts to compensate. The disadvantages will not necessarily be relevant in every implementation of the software operator design pattern. On the contrary, if the disadvantages of the pattern are well known, IT operators and software developers can learn how to avoid them. Looking at the disadvantages helps everyone apply the operator design pattern more effectively.

Bruce Warrington has captured a warning. It’s not certain whether it will be relevant for you.

Software operators require an investment

Without software operators, operational tasks would be executed manually, step by step, in the execution environment or in management infrastructure like kubectl, a command line interface for Kubernetes clusters. In fact, in one of my presentations about software operators someone recently asked, “Did I get it right that you propose something which I could (easily) achieve by calling kubectl?” While the question suggested that software operators are not useful, because each of the steps could be executed with other tools, it actually points out the trick. 

Yes, it’s about executing a number of commands on certain tooling and APIs to complete a task. If a task is repeated over and over again, or if it’s complex and error-prone, it makes sense to automate it. 

If the task is not complicated, automation may not make sense. Because, in turn, more software means more maintenance requirements. Furthermore, the publication of the software requires proper communication and presentation.  So, whether or not automation makes sense depends on the situation. 

Reuse of software includes reuse of bugs

It;s good to have operational tasks covered by source code in order to repeat these tasks over and over again. However, for the case that this implementation contains a mistake, it affects not just one single operation case, but potentially all the users of this software operator at the same time.

We all know that building perfect and 100% error-free systems is impossible. The economy of scale for software operators can make operations more efficient, but it can impose higher demands on operation safety – just as other products that benefit from the economy of scale. At the same time, no one would recommend, for example, to use  security libraries.

Testing and community: important ways to mitigate these disadvantages

Software operators are tested, not only with unit tests but also with integration tests. A CI-enabled software development project significantly improves reliability. In addition, an open development as OSS involving the community provides transparency and invites operator experts to jointly improve the implementation. Last but not least, developing software operators as OSS is also a great way to split the development effort on many shoulders.

Randy Fath has shot an example of building things more effectively together.

When does using software operators make sense?

These points make clear that applying software operators comes at a cost. The blog posts in this series clearly show that  certain design forces justify the effort of implementing software operators. 

You may not need them if you don’t expect remote operations. Likewise, they may not be necessary if your application will be updated but not changed (operationally speaking) during its lifetime. In these cases, using plain package management tools like snaps might be a better alternative.

Stay tuned

We will continue this series with a discussion of further aspects of this design pattern.

More Information