Skip to main content

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 us. A member of our team will be in touch shortly. Close

An error occurred while submitting your form. Please try again or file a bug report. Close

  1. Blog
  2. Article

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.

Further reading

Related posts


David Beamonte
26 June 2025

Cut data center energy costs with bare metal automation

Cloud and server Article

Data centers don’t have to be power-hungry monsters. With smart automation using tools like MAAS, you can reduce energy waste and operational costs, and make your infrastructure greener, without sacrificing performance or flexibility. ...


Isobel Kate Maxwell
24 April 2025

The hitchhiker’s guide to infrastructure modernization

Cloud and server Article

One of my favourite authors, Douglas Adams, once said that “we are stuck with technology when what we really want is just stuff that works.” Whilst Adams is right about a lot of things, he got this one wrong – at least when it comes to infrastructure. As our Infra Masters 2025 event demonstrated, infrastructure ...


Canonical
28 March 2025

KubeCon Europe 2025: Containers & Connections with Ubuntu

container Article

It’s hard to believe that the first KubeCon took place nearly 10 years ago. Back then, Kubernetes was still in its early days, and the world was only just beginning to understand the power of container orchestration. Fast-forward to today, and Kubernetes is a fundamental part of cloud-native development, taught in universities as a key ...