The software operator design pattern — part 2

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.

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:

• Constraints of the problems.
• 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. 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 …