Your submission was sent successfully! Close

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

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Michael C. Jaeger
on 12 June 2022

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

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:

Related posts

Michael C. Jaeger
16 September 2022

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

Cloud and server Article

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

Michael C. Jaeger
5 September 2022

Best practices to publish open-source software operators

Charms Article

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

Michael C. Jaeger
30 June 2022

The software operator design pattern: disadvantages – part 5

Charms Article

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