Design patterns and the software operator — part 1

by Michael C. Jaeger on 31 March 2022

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 computer vendors and many users just required simple programs implementing calculations or little tools. As we know, this has changed quite a lot over the past decades. Technology became more complex and vendors started providing interfaces for the applications (APIs) of the users. As computers got more capable, the APIs grew over the years. Libraries, frameworks and APIs went from being mainly made and distributed by vendors to being provided by 3rd parties.


A classic example of a computer (terminal) for which users wrote their own programs

From software to patterns

As writing software turned into a more and more complex engineering effort, ideas emerged to make writing software easier and more stable: it was the idea of identifying solution patterns when implementing commonly experienced problems. Actually, many problems in programming are raised over and over again. As a consequence, communities emerged to discuss such patterns in their meetings, workshops and conferences. Descriptions about design patterns were published as conference proceedings.

One early community from that time is the Hillside group (https://hillside.net/) named after the hotel where initial community meetings took place. Popular design patterns are well known even today such as the observer, the factory or the builder patterns. They were coined by the first books about design patterns, such as the Design Patterns: Elements of Reusable Object-Oriented Software or the books series Pattern Oriented Software architecture.

The software operator design pattern

It turned out that design patterns were useful for many software developers. Today, many of these patterns are already part of APIs, frameworks and libraries. But still, it is very useful for every software developer to be aware about these, because writing software never runs out of problems and challenges.Consequently, for operating kubernetes workloads, the kubernetes community has published the software operator pattern. It defines an entity that controls a workload during its operating life cycle. The motivation is to have source code to operate workloads reliably and securely for all its instances.

Charmed Operators – an implementation of the software operator pattern


The Canonical implementation of the software operator pattern is OSS and, of course, welcomes interested parties.

A design pattern is just a repeated design, a pattern and can be implemented in many ways using different technology platforms or different programming languages. The Charmed Operator Framework implements the software operator pattern. Every operator based on this implementation is called Charmed Operator. Not only is the framework fully open source, but also the management middleware for operators named Juju is developed as an OSS project as well. Recently, a lot of documentation has been added, so you are welcome to take the first step with this framework.

The upcoming part 2 of this series will discuss in more detail: what a software pattern description shall cover and how the software operator pattern is described. Have fun reading!


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 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 […]

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 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 […]

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 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 […]