The Open Operator Manifesto

Better operators through open community standards

Our goal is to improve devsecops with open source operators for widely used software. These shared values ensure high quality code and conversations.

1. Source required

   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 common app operations. Our frameworks and tools are open source, but our framework license does allow vendors to create interoperable operators with their own license.

3. Community-driven

   An operator distills real-world application experience into shared code. No one person can know all the ways an app will be used. Open community discussions and code are the best way to improve operator performance, usability, quality and completeness.

4. Security

   An operator should apply defense-in-depth to every aspect of operations — from data encryption and app confinement to password selection and key handling. We review all operators for security, and we publish fixes fast.

5. Multi-cloud optimisation

   An operator should work on every cloud or Kubernetes, and should also automatically optimise for its environment and take advantage of local, differentiated capabilities.

6. Reusability

   Reuse improves quality and grows the community. An operator should offer many ways to deploy the application — large or small scale, resilient or minimal, persistent or ephemeral, standalone or integrated with as many other apps as possible.

7. Patches

   Operators should facilitate security patching, to help administrators maintain a healthy and compliant deployment. High-quality updates are essential for security.

8. Upgradability

   Operators should manage upgrades. An operator should ensure maximum availability throughout the upgrade and provide a way to roll back to prior state.

9. High-level config

   Operators should abstract complex application configuration. An operator should offer only high-level config to capture admin intent and reduce the burden of application specific domain expertise required to run the app.

10. Scalability

    Applications are often clustered for resilience or performance. An operator should handle dynamic changes, optimise for admin intent, and scale up or down equally well.

11. Everyday actions included

    Daily actions like backup, restore, reset, and restart should never require direct admin access to underlying systems or containers. Actions should be driven by API or CLI, subject to permissions, and logged for audit and accountability.

12. Status

    Admins should never require direct access to underlying systems or containers to know the status of a workload. An operator should assess and represent the health, availability, and dependencies of the app.

13. Leadership

    In distributed systems, problems occur if different units of the same app make conflicting decisions. An operator should provide leadership and communicate leader decisions to all units in a reliable way with proven consistency.

14. Subordinate software

    An operator should provide for related functions to coexist in its execution environment, whether that is a Kubernetes pod or a machine.

15. Application graph

    Most of the work in enterprise software operations is integration. An operator should go beyond the application lifecycle to the application graph, and enable integration with as many other applications as possible to support as many scenarios as possible.

16. Interoperability

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

17. Consistency

    It is easier to use new applications if they follow common patterns. An operator should use common conventions to simplify the learning and adoption curve.

18. Substitution

    Enterprises expect to choose the actual implementation of services in a deployment. Operators should not assume specific integration counterparts, to allow substitution with compatible alternatives.

19. Model-driven

    Applications must work together to be successful. Operators should respond to changes in a shared model that describes the whole application graph and config.

20. Capacity agnostic

    Admins may deploy the application on a few small machines, or many large machines. An operator should not assume capacity or scale, but learn it from the model.

21. Network Agnostic

    Different scenarios require different networking for the same application. An operator should support segregated network architecture as described in the model.

22. Cross platform

    Enterprises have applications on both Windows and Linux, and many deployments integrate platforms. The operator framework should enable multi-platform scenarios.

23. Multi-arch

    An operator should work on all supported architectures of the application.

24. Tested

    Operators are privileged software dealing with critical apps in sensitive environments. An operator should have both unit and integration tests that gate all changes.

25. Trusted builds

    An operator should be built in a trusted environment, just like the app it drives, to guarantee provenance and integrity.

26. Signed

    Operators are privileged software in which users place great trust. An operator should be signed to know who produced it, and prove that it has not been modified.

27. Beta testing

    An operator should publish beta and release candidate versions to enable widespread testing and increase the quality of stable releases.

28. Managed

    An enterprise environment must plan changes. Operators should enable fine-grained control of updates and enterprise control of application versions.

Operators that embrace these principles, practices and values are better for a wider audience. We elevate the art of application management with universal, open operators that reflect the deepest insights from the broadest community in the widest contexts.