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 execution. This is where the software operator comes in. Software operators are a design pattern, a proven and acknowledged approach by the software community. Software operators lift automation to a new level. They don’t only automate the deployment of application workloads, they also encode the expertise required to manage and operate them. In other words, they offer a secure and reliable way to operate applications. 

But suppose you start the development of your operator. Fundamental questions will naturally arise: Which points would you need to cover? What makes a good operator? What should you start working on first?

Go open source with your software operator

We believe open source development is the best way to create operators. Open source does not only refer to publishing the source code but also to the open and distributed development of software. The goal of operators is not to cover a single application use case but the needs of relevant use cases in various domains. Therefore, open source development offers the best approach to bring experts with different backgrounds together to build a reliable and secure operator. In addition, open source provides transparency, which is the most efficient way of detecting vulnerabilities and providing secure software.

Canonical has developed Juju and the Charmed Operator SDK to develop and run operators in an open-source way. Operators written to run on Juju are called Charmed Operators, or Charms for short. Developers can publish their operators on our app store: Charmhub.

Our publication guidelines can help you prepare your operator implementation for public launch. While written specifically for Charms and Charmhub, they provide best practices for anyone engaging in open-source operator development. 

Make your project approachable

The publication guidelines cover two main parts. First, every open-source project needs to attract users and contributions. General best practices exist for preparing an approachable and popular open-source project. Our publication guidelines emphasise the most relevant points:

• A clean code base covering a consistent code style and an appropriate project tree structure. Both are necessary for mature development and increase the approachability of the project.
• Documentation explains how to use the operator, test the implementation and contribute to the project.
• Contact e-mails, mailing list addresses and relevant URLs guide users on where to find relevant information or contact the right persons.
• Links to forums and chats are essential to let users quickly get in touch with the project community and ask questions or make suggestions.
• Ensuring trademark and licence compliance of 3rd party content respects external interests. It eliminates doubts about legal issues for interested users.

These general points apply to most open-source projects. But there are also specific things about operators to consider.

Automate testing and releasing

Different operators operate, Keith-Haring-style – An AI-generated image using OpenAI tools, attributed to the author of this post.

Software operators are a special kind of software compared to libraries, smartphone applications, GUI frameworks, or web applications. Therefore, setting the proper foundation from the beginning is very important. Consider these two things:

1.  Software operators need to consider the release cycles of the covered application, not just their own. Moreover, providing timely releases is essential for security software that runs productively on organisations’ servers. Therefore, automating the build and release process is crucial for an operator. If build and release processes are not automated, everything will slow down significantly, starting from testing new releases in different environments.
2.  Interested users or developers need to invest time and effort in testing operators. Depending on the application, testing requires not only the setup of a private or public cloud, but also the installation of additional software. For example, if the application and its operator are an extension for OpenStack, a test installation is required first. Therefore, to avoid deep frustrations, it’s more critical that the operator works reliably from the beginning. For this reason, both unit and integration tests are necessary from the moment development starts.

If these points are not covered, providing a secure and reliable operator will be challenging in the long run. For more details, read the publication guidelines in our docs for the Charmed Operator SDK.

Further reading

Read our introduction to Juju and Charmed Operators

• Browse our collection of Charmed Operators on Charmhub.io
• Learn about Juju Charmed Operator Lifecycle Manager
• Learn about the Juju Charmed Operator SDK
• Watch  videos  to get started with Juju and Charmed Operators 
• Watch the webinar about making charmed operator ready for publication: