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 — part 2

This article was last updated 1 year ago.


This blog post continues with the previous blog post about design patterns and the software operator pattern. In this part, this post takes a closer look at the description of the software operator pattern.

What is a design pattern?

Over the years, the software development and programming community developed a common understanding of design patterns. A design pattern is a general solution designed to solve a repeatedly occurring problem when writing — or better, designing — software. This implies that if a design is new and has not been proven to work in production software, it cannot be a pattern. A pattern is an abstract concept covering multiple implemented solutions following that abstract concept. If there are no solutions already in place, such a pattern does not exist.

Both are called pattern, but only the right one shows the concept of an element repeated over and over again. The left image shows just a design.

For the software operator pattern as published by the kubernetes community, the part about existing implementations is covered, as the website clearly lists a number of frameworks and projects implementing this pattern. And – as pointed out in the first part of this blog post series – Canonical provides an implementation of this pattern as well. Interestingly enough, this implementation has been created before the publication of the operator pattern in 2017. In fact, initial steps for the Canonical implementation of the software operator pattern date back much earlier than 2013. At that time, the implementation was not named software operator framework, but Juju and Charms. Back then, operators were named Charms, while the middleware running the operators was Juju, running Charmed Operators and managing the available local, public and multi-cloud environments. 

But coming back to describing a pattern instead of only describing an interesting design, there is more to say: the motivation to talk about patterns is to let the readers, software developers or software architects understand the experience of adopting this design, its benefits and also disadvantages.

How to describe a design pattern

After decades of research about design patterns, a common structure for describing them has emerged. The majority follows a common structure as used in many of the books about design patterns or as explained on Wikipedia. A pattern description covers the following basic elements:

  • A problem description.
  • Constraints or forces that usually occur and impact the solution design.
  • A structural description.
  • A description of how the elements interact with each other.

In addition, since the design pattern is a proven solution, the documentation also covers the advantages and disadvantages that have resulted from the use. In order to justify the nature of being a pattern, a description naturally refers to meaningful implementations – in the best case these implementations are successful examples.


Yin and Yang – difficult to see at first sight: Like many things in life, design patterns come with advantages and disadvantages. It is important to consider both. (Photo by Leonardo Marçal from Pexels)

The software operator design pattern

Albeit the above-mentioned points are well known, there is no industry standard so far about how to describe a design pattern. For the software operator pattern, the Kubernetes community has provided the most popular description so far. This description does not provide all the points to completely describe a design pattern (cf. the previous blog post). However, the CNCF provides a more elaborate description of this pattern in this white paper. And this description contains more useful information and comes much closer to the common elements of describing a design pattern. It does not follow the structure mentioned above though, but it is still possible that future contributions to this pattern will cover also the following points:

  • Forces in the problem which the pattern solves.
  • Advantages and disadvantages.
  • Related patterns that could refer to the “Object Manager” pattern.

But lacking these elements did not stop the community from implementing the software operator pattern, and one implementation could be found right here on the webpages nearby: juju.

In conclusion for the second blog post about the software operator pattern, the software operator pattern may not have been described in the classic way. However, given all the available implementations, it clearly represents a pattern. As outlook, it will be relevant to discuss advantages and disadvantages of this pattern.PS. Looking for related patterns points to interesting other uses of the word operator:

PS. Looking for related patterns points to interesting other uses of the word operator:


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