The software operator design pattern: advantages – part 4

by Michael C. Jaeger on 29 June 2022

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 application of this pattern leads to a good solution and – perhaps more importantly – when it does not. So far, we have covered the following topics in this blog post series:

The blog series is aligned with the general framework for discussing software design patterns: The books “Design Patterns and elements of reusable software” and the POSA series (Pattern Oriented Software Architecture) have shaped this framework, including the design structure, the behavior of elements, the design forces, the advantages and disadvantages.

The software operator design pattern

This fourth blog in our series covers the advantages of the software operator design pattern. The forces, presented in part 4, are a useful starting point to look at the advantages of the software operator design pattern. Let’s explore how software operators facilitate remote execution, flexibility and application composition.

Remote execution advantage

Installing a single application locally is straightforward in most cases. There are app stores and package managers for that. However, installing applications on remote servers is a more tedious task, which becomes more complicated as the number of applications increases. First of all, the login to these machines must be prepared and maintained. But manually maintaining logins does not scale very well. In fact, what is desired is an entity that controls the required provisioning of the machine and performs the required steps. The software operator design pattern, as a dedicated entity, can cover the execution of operational tasks and the remote login, at the same time.

Monitor and keyboards for servers as captured by Brett Sayles are rare and certainly not at every server anymore.

Flexibility by design

During the life of an application, operational care will be required. Server applications cannot be installed once and then forgotten (it’s not fire and forget). Rather, operating applications have changing operational needs. These include capacity changes, regular updates or maintenance tasks, such as clearing caches or temporary files.

When considering the design forces, the ability to be flexible with changes while maintaining reliability is very important. The operator pattern automates operational tasks with source code, executing tasks as a program. This is a preferred approach. On the one hand, it makes operational tasks testable and more stable. On the other hand, tasks that are executed repeatedly will always perform with the set standard of reliability – as opposed to manual executions. A purposefully developed software operator will incorporate the experience of human operators and implement a reliable way to run operations.

Application composition

Applications today are usually composed of several elements. This results in two design choices that are covered by the software operator. The first one is uniformity. They make operations more consistent and thus less error prone. The second is integration. Software operators can be extended with integration functionality and turn several application elements into a composition.

Look out for part 5 in this series about the design pattern

These are the main advantages covering the design forces of the software operator pattern. It is important to consider that advantages also come at a cost, which is the subject of the fifth part of our series of blog posts.

The software operator design pattern: advantages – part 4