The software operator design pattern — part 2

by Michael Jaeger on 31 March 2022

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.

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 that usually occur 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 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 contribution to this pattern will cover also the following points:

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. One example is the operator design pattern introduced by Xie et al. It describes an operator for operations on image data. The term operator is derived from the term operand which is applied to a signal. The micro operator design pattern by Tseng et al. refers to an operator in the telecommunications domain (a “telco operator”), another slightly different meaning of the term operator …

Related posts

Design patterns and the software operator — part 1

In the early days of software development, computers were sold with compilers and interpreters. Users wrote mostly their own small programs instead of buying software. During that time, most didn’t even consider downloading software as only a few were connected to mailboxes or the UUCP network. Most of the software was provided by the com […]

Operator Day hosted by Canonical at Kubecon EU 2022

May 16th 2022, virtual eventWeek of KubeCon + CloudNativeCon EU 2022 What is Operator Day? Software operators are crucial elements in the Kubernetes landscape. They implement operational tasks covering everyday application management. They help human operators, administrators to run their applications efficiently and effectively. On Opera […]

Getting started with Juju and Charmed Operators: three awesome videos

Getting started with software can be confusing – depending on the complexity of the software, of course. Despite the extensive documentation available for Charmed Operator SDK and Juju some just prefer to watch video material to start with. So, let’s take the opportunity to have a look at available tutorials and presentations available on […]