The Open Operator Manifesto

We lead the Open Operator Collection, on a mission to elevate the art of dev–sec–ops with open–source operators that control enterprise applications. These values and guidelines ensure high–quality code, conversations and experiences for our community.

1. Source required

   An operator is software that takes control of an enterprise system, application or service. The operator source code is essential to verify expected behavior. We make operator source available so that everybody can understand exactly what happens on their systems.

2. Open source preferred

   We are an open source community to enable everyone to contribute to the shared problem of common workload operations. Our frameworks and tools are open source to enable the widest benefit of our work. We know some vendors cannot use open source, so our framework license allows them to create proprietary operators while preserving interoperability.

3. Security

   Application security is critical to enterprise integrity. The most common cause of vulnerability in enterprise architecture is human error. Software operators ensure best practice for every deployment and every change. A good operator applies defense-in-depth to every aspect of workload operations – from data encryption and application confinement to password selection and key handling. We review all operators for security. We treat operator code just like application code, with Common Vulnerabilities and Exposures, and we distribute fixes fast and automatically.

4. Substrate neutral

   An operator should not assume any particular infrastructure or Kubernetes implementation, but use common, portable primitives. Where specific application capabilities can be unlocked on a particular substrate, they should be optional.

5. Reuse

   A well‐behaved operator is general and not deployment-specific. The operator understands many ways to deploy the application – large or small scale, resilient or minimal – and it serves the diverse needs of multiple users equally. Reusability drives correctness and completeness, it grows the community of users and contributors, and it expands the configurations, scenarios and integrations supported by the operator.

6. Updates and Upgrades

   Software evolves, and deployments must update to benefit from those improvements. High‐quality updates inspire the confidence to apply them frequently, which is essential for security. Good operator updates are independent of application upgrades, because application upgrades must be deliberate choices. A good operator distribution system has mechanisms to ensure smooth upgrades across application generations.

7. Purposeful config

   Application software has many configurable capabilities, but most of those exist to support higher‐level goals or purposes. A good operator distinguishes between purpose and mechanism, offers high‐level purposeful config, and translates that to the many low‐level mechanism configs of the workload.

8. Scale

   Applications are often clustered for resilience or performance. A good operator will handle scale, guided by purposeful config and the workload nature, and respond to dynamic changes. A great operator will scale up and down equally well.

9. Actionable

   Every application has a set of actions that can be performed by administrators. A good operator declares them and facilitates reliable execution. Daily actions like backup, restore, reset, and restart should never require direct admin access to underlying systems, configuration files, tools or containers. Actions should be remote procedures driven by API or CLI, subject to permissions, and logged for audit and accountability.

10. Awareness

    A good operator evaluates and presents the state of its workload in human‐friendly terms. The operator understands the health, availability, and dependencies of the application, assesses those and presents them to the admin. Admins should never access the underlying systems or containers to assess the state of a workload, because the operator reports it continuously and automatically.

11. Leadership

    In distributed systems, some decisions must be taken for a whole cluster. Problems occur if different units make independent conflicting decisions. An operator should always know whether to make a decision or defer to another unit. Leader decisions should be available to all units in a reliable way. Leadership in distributed systems is a hard problem, and a well‐formed operator will follow proven algorithms for leader election to ensure cluster consistency.

12. Composition

    It is common to integrate multiple pieces of software on the same system. For example, an intrusion detection system may need direct access to the processes on a database server. The operator framework must provide clear mechanisms to enable diverse functions to coexist in a single execution environment such as a Kubernetes pod or a machine.

13. Topology

    Most of the work of enterprise software is integration. A good operator goes beyond the application lifecycle to the application graph, understanding integration with other applications, and controlling its workload appropriately.

14. Interoperable

    Enterprises require multi‐vendor deployments to work well. Operators should work with operators from other vendors and publishers. Collaboration and coordination are best done in a public forum to ensure the widest perspective.

15. Consistent

    Admins work with many operators in large systems of many components. A well‐designed operator will reuse common patterns of naming and behavior to simplify the learning curve and increase administrator effectiveness.

16. Substitution

    Many applications provide services that are standard or similar. Enterprises expect to choose the actual implementation in a particular deployment, or swap implementations later. Operators should not assume specific integration counterparts, allowing their substitution.

17. Model driven

    All applications must all work together for a successful deployment. A change in one application is often relevant for all the applications integrated with it. Operators should observe and respond to changes in a model that describes the whole deployment application topology and configuration.

18. Resourceful

    An operator should not assume a given resource allocation or scale. A user may deploy the application on a few small machines in one scenario, and many large machines in another. The model determines resources, not the operator.

19. Network Agnostic

    Different enterprises take different approaches to networking. An operator should learn what’s intended from the model, and not hard-code specific network details. There are good reasons to separate services on different networks, and operators should support segregated network architectures.

20. Cross platform

    Enterprises have applications on a wide range of operating systems like Windows and Linux, and many deployments integrate systems on diverse platforms. The operator framework should enable multi‐platform scenarios.

21. Architecture neutral

    Where the underlying application provider cares to be multi‐arch, the operator community should care too.

22. Tested

    Operators are privileged software dealing with critical functionality in sensitive environments. A good operator will have both unit and integration tests, which can be run by users to verify behaviour in their intended scenarios.

23. Trusted builds

    Operators are software, which is often compiled. The integrity of the build system, and the integrity of the revision control system that drives them, is central to the provenance of the operator. A trustworthy operator system must enable trusted builds of operators as much as workloads.

24. Signed

    The trust placed in an operator means that it is important to know who produced it, and that it has not been modified. A trustworthy operator distribution system must enable verification of the provenance of any given revision at any time.

25. Staged

    Software changes are inevitable. The more widely they can be inspected and tested, and the sooner issues can be uncovered, the better. A good operator will publish not only stable changes, but upcoming releases in beta or release candidate form, and possibly a development tip, for each major version. This enables widespread testing of changes and increases the quality of stable releases.

26. Managed

    An enterprise environment must plan changes at particular times. Operator distribution mechanisms should enable fine‐grained control of update propagation as well as enterprise control of versions.

As a community, these principles guide our work and make it relevant to a wider audience. The more we can improve our operators in line with these values, the more our community benefits from the entire collection of operators.