Our goal is to improve devsecops with open source operators for widely used software. These shared values ensure high quality code and conversations.
We make operator source available so that everybody can understand exactly what happens on their systems.
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.
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.
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.
An operator should work on every cloud or Kubernetes, and should also automatically optimise for its environment and take advantage of local, differentiated capabilities.
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.
Operators should facilitate security patching, to help administrators maintain a healthy and compliant deployment. High-quality updates are essential for security.
Operators should manage upgrades. An operator should ensure maximum availability throughout the upgrade and provide a way to roll back to prior state.
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.
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.
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.
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.
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.
An operator should provide for related functions to coexist in its execution environment, whether that is a Kubernetes pod or a machine.
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.
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.
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.
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.
Applications must work together to be successful. Operators should respond to changes in a shared model that describes the whole application graph and config.
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.
Different scenarios require different networking for the same application. An operator should support segregated network architecture as described in the model.
Enterprises have applications on both Windows and Linux, and many deployments integrate platforms. The ops library should enable multi-platform scenarios.
An operator should work on all supported architectures of the application.
Operators are privileged software dealing with critical apps in sensitive environments. An operator should have both unit and integration tests that gate all changes.
An operator should be built in a trusted environment, just like the app it drives, to guarantee provenance and integrity.
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.
An operator should publish beta and release candidate versions to enable widespread testing and increase the quality of stable releases.
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.
