The software operator design pattern: disadvantages – part 5

by Michael C. Jaeger on 30 June 2022

The software operator is a design pattern – it is a proven design that has been applied in many situations and implemented by several frameworks. Its widespread adoption in the industry has allowed us to study its consequences, both good and bad. This is important because software developers and IT architects need to know when a design is a good choice, and when it’s better to avoid it. Previous blog posts in this series 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 will not necessarily be relevant in every implementation of the software operator design pattern. But when they are relevant and left unaddressed, they can result in a lot of extra effort. 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. You don’t need to invest time and resources automating tasks that are easily performed manually.

Reuse of software includes reuse of bugs

It’s good to have operational tasks automated by source code to avoid repeating these tasks over and over again. However, when the source code 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 economies of scale for software operators can make operations more efficient, but they can impose higher demands on operation safety – just as other products that benefit from economies of scale. At the same time, one would recommend, for example, additional care when using security libraries.

Testing and community: important ways to mitigate these disadvantages

So far, we have discussed the two largest disadvantages of software operators: they require an investment and you need to ensure they are as close to error-free as possible. Luckily, there’s an effective way to address 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, open, open-source software (OSS) development, 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?

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

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

Related posts

Join us at Operator Day, hosted by Canonical at Kubecon NA 2022

The 5th Operator Day is coming up. It will take place at KubeCon North America 2022. This edition will center on cases where software operators have been applied successfully. Join us to hear about our experience in building software operators using Juju, an open-source operator lifecycle manager. Operators implemented for Juju are called […]

Best practices to publish open-source software operators

Running or operating applications requires several tasks throughout their lifecycle: scaling instances, checking the health, integrating with other applications, running backups, and applying updates – to name a few examples. It’s a time and labour-intensive process. To automate these tasks, developers can implement scripts for repeated e […]

The software operator design pattern: advantages – part 4

The software operator is a design pattern. Its design is based on successful applications where this approach was found useful. In other words, it’s a proven approach that can be recommended to others. But like all approaches, it’s important to understand their positive and negative impact. Software developers need to understand when the […]