Your submission was sent successfully! Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close

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

This article was last updated 1 year ago.


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

Talk to us today

Interested in running Ubuntu in your organisation?

Newsletter signup

Get the latest Ubuntu news and updates in your inbox.

By submitting this form, I confirm that I have read and agree to Canonical's Privacy Policy.

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...

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...

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 and implemented by several frameworks. Its...