The software operator design pattern: May the force be with you – Part 3

by Michael C. Jaeger on 12 June 2022

The software operator is a design pattern. A design pattern describes the approach to cover the operational tasks of an application’s implementation. The first post in this series introduced the concept of a design pattern in general. The second post covers the software operator design pattern in particular.

In the second part, we also explained that a design pattern usually covers a discussion about consequences, advantages or disadvantages.  After all, a “pattern” refers to an approach that has been applied multiple times. As a consequence, this experience should be written down to help software developers  make informed decisions about which design to apply.

Design forces impact the eventual solution design and may be lead to an evaluation of multiple paths until the final solution is reached (photo credit: Marko Blažević)

This third installment in our series will discuss the “so called” design forces which motivate the pattern. A discussion of design forces in general can be found in early books about software patterns. Examples include Design Patterns and elements of reusable software and the POSA series (Pattern Oriented Software Architecture).

What is a design force?

In software development, design forces are characteristics of a use case which eventually impact a solution’s design. A very simple example is the bounded execution time in a use case for sorting data. Some sorting approaches, which would result in overly long runtimes, would be ruled out. It’s obvious that algorithms do not refer to a design; a design is about the structural arrangement of elements and their interaction. But this example shows that forces can refer to non-functional requirements.

An implementation of a design pattern can have many facets – just like a Rubics cube shot by Dev Asangbam

Forces that impact software operator design

The concept of forces in a design pattern refers to characteristics of concrete use cases and how these s favor a particular design. Software operator patterns are usually  applied in distributed systems, remote execution, cloud native deployments, server software, involving scalability and high user load – to name a few. Let’s consider some of these examples in more detail:

• Remote execution: Decades ago, servers used to have a display with mouse and keyboards attached for people to work on the operational tasks. Today, operating applications is a remote task.
• Flexible Operations:  Server applications in growing businesses, regardless if they are customer-facing or not, should be able to adapt to changing demands. Applications must scale up but also down to save resources. Changes in the environment lead to changes in the configuration and any solution needs to be easy to adapt. A software operator must support this flexibility and must not add significant restrictions to the operational capabilities of the application.
• Application Composition: Server applications are usually composed applications. Simple applications, like those being used for productivity on personal computers, do not impose much demand on operations. It’s rather server applications, which are composed of several elements (web servers, proxy servers, caches, data stores, message brokers) which create a particular challenge for operators. Managing multiple application parts at once creates complexity and hassle.

These three points are the main forces for software operator design pattern: distributed and  remote execution, flexible operations and a composed setup. There are more forces of course and if other relevant ones should be mentioned it could be cyber security and reliability – because for the deployment of applications, the work of many depends on the proper operations and thus reliability and secure operations are equally important.

Look out for part 4

Having the forces pointed out, this series will delve into the advantages of the software operator design pattern.

Further reading

Learn more about Juju and the Juju SDK – our implementation of the software operator design pattern: https://juju.is/docs/sdk