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!