About operator lifecycle manager

templates/about/base.html

@@ -22,6 +22,9 @@
             <li class="p-side-navigation__item">
               <a class="p-side-navigation__link{% if request.path == '/about' %} is-active{% endif %}" href="/about">OLM Overview</a>
             </li>
+            <li class="p-side-navigation__item">
+              <a class="p-side-navigation__link{% if request.path == '/about/operator-lifecycle-manager' %} is-active{% endif %}" href="/about/operator-lifecycle-manager">Operator Lifecycle Manager</a>
+            </li>
             <li class="p-side-navigation__item">
               <a class="p-side-navigation__link{% if request.path == '/about/ops-code-quality' %} is-active{% endif %}" href="/about/ops-code-quality">Delivering ops code quality</a>
             </li>

templates/about/operator-lifecycle-manager.html

@@ -0,0 +1,61 @@
+{% extends 'about/base.html' %}
+
+{% block title %}Juju is an enterprise Operator Lifecycle Manager{% endblock title %}
+
+{% block meta_copydoc %}https://docs.google.com/document/d/1B0adX3iTzNrF_RORQUWU6MaYn_E2wzvfJYUbolAY3Ok/edit{% endblock meta_copydoc %}
+
+{% block meta_description %}An operator is software which drives an application. The operator lifecycle manager (OLM) is a service which installs operators, updates them, configures them, and in the case of the Juju OLM, helps it to integrate with other operators.{% endblock %}
+
+{% block about_content %}
+<h1>What is an Operator Lifecycle Manager?</h1>
+<p>A service that manages the install, update, configuration and integration of operators on Kubernetes or traditional machines</p>
+<p>An operator is software which drives an application. The operator lifecycle manager (OLM) is a service which installs operators, updates them, configures them, and in the case of the Juju OLM, helps it to integrate with other operators.</p>
+<h2>Model-driven operations</h2>
+<p>One key differentiator of the Juju OLM is the way it organises large numbers of operators, potentially across many different clouds or clusters. Operators are in a sense extra pieces of software to manage, so having a structure and catalog of that software immediately provides a level of enterprise awareness and control of the operator estate.</p>
+<p>The Juju OLM provides <a href="/model-driven-operations">model-driven operations</a>. Sets of operators are organised into models, each model having the same set of access permissions and living on the same Kubernetes cluster or machine compute substrate such as a public cloud in the case of traditional applications. The ability to organise multi-cloud operations in these models, and to manage models globally, across many regions of many clouds or private infrastructure, through a single scale-out OLM, is a strength of Juju.</p>
+<p>Model-driven operations simplify integration between diverse operators, and reduce repetition and redundancy because they describe both sides of every integration with a single element. They also capture business intention, the decision to allocate resources to particular sets of applications. Business decisions become explicit with model-driven operations.</p>
+<p>The concept of ‘desired state’ is popular in Kubernetes. Model-driven operations elevate the notion of desired state, allowing administrators to describe their integration and resource allocation policies, and using shared operations code to achieve that intention rather than application-specific expertise.</p>
+<h2>Integration</h2>
+<p>While the focus of an operator lifecycle manager is usually the simple life cycle of a particular application, the model-driven nature of the Juju OLM provides an opportunity to manage the application graph in its entirety, reflecting patterns of integration between multiple applications.</p>
+<p>With the Juju OLM, applications can be integrated declaratively in the model. A line in the graph represents a line of integration, connecting specific functions of the applications. Operators ensure that their application configuration reflects the desired state of integration in the model.</p>
+<p>Integration can be made, and undone, dynamically. The Juju OLM delivers updates in the application graph to operators as a stream of events, and operators can use this mechanism to inform one another of changes in their status which might affect related applications in the graph.</p>
+<h2>Storage for operators</h2>
+<p>Many applications require storage to be allocated and managed carefully. The operator lifecycle manager coordinates this allocation based on the model, matching resources allocated to the model with application-specific requirements and configuration.</p>
+<p>The Juju OLM is able to manage storage for applications in bare metal, virtualised, cloud instances, and Kubernetes environments. Storage categories are described in the model, and particular applications can have specific classes of storage designated for particular functions. For example, it is possible with the Juju OLM to deploy a database with persistent data volumes on high-speed high-availability disks and application logging to slower, less reliable media.</p>
+<p>The OLM adapts to and coordinates with the substrate &mdash; in the case of Kubernetes it uses CSI capabilities, in the case of clouds, VMware and bare metal it uses the relevant cloud-specific APIs and storage architecture to enable administrators to allocate storage to the model as a whole and specific application functions in particular.</p>
+<p>The ability to provide consistent model-driven storage for both legacy applications and Kubernetes applications greatly simplifies administration across the enterprise.</p>
+<h2>Networking for operators</h2>
+<p>Applications provide services to each other and to end-users on the network. Security practices usually dictate that network services are separated on different networks for different applications, and in some cases, for different functions of the same application.</p>
+<p>In a typical enterprise environment there will be multiple segregated networks, and strict policies about which services should be accessible or provided to which network. It is important to be able to place particular application services on specific networks.</p>
+<p>The OLM is in a position to define and enforce network security policies.</p>
+<p>The Juju OLM models networks in both Kubernetes and traditional machine environments. Application endpoints can be bound to particular networks in the model, enabling the operators to comply with enterprise network policy in any particular deployment. Networks can be provided at both L2 and L3, enabling low-level telecommunications services to be provided through operators just as cleanly as typical IT services.</p>
+<h2>Installing operators</h2>
+<p>Since an operator is just a package, it can be provided locally. For example, you may be developing the operator yourself, and iterating locally, so you can provide the operator to the OLM manually. You may also have an operator which includes confidential code or data, and prefer not to store that in a public service.</p>
+<p>It is much more convenient, however, that most operators be shared in a trusted, public repository. We consume software from such repositories all the time. In Linux we have popular package distribution systems like APT, in the MacOS world we have brew, and in Windows we have Chocolatey and Winget. For Python code it is common to use PyPI, and Ruby has gems.</p>
+<p>An operator is software, and it is useful to have a package manager to install, update and remove it.</p>
+<p>You can think of the operator lifecycle manager as the ‘package manager’ for operators. The OLM handles finding, fetching, updating and removing operators from the system. The Juju OLM can retrieve operators from the Open Operator Collection at charmhub.io, and will also look for updates there.</p>
+<p>If the operator is being used on Kubernetes then it will be run in a container in its own pod, or as a sidecar of its workload application container. If it is being run on a machine (bare metal or VMware or cloud) then it is installed in a directory of that machine.</p>
+<p>The operator lifecycle manager will then invoke the operator to handle events associated with the lifecycle of the operator.</p>
+<h2>Updating operators</h2>
+<p>Since operators take responsibility for mission-critical systems, they are themselves critical systems, and need to be kept up to date to ensure that bugs and security issues are fully addressed.</p>
+<p>The OLM will check periodically to see if there is an update for installed operators. Updates are not applied automatically, but can be applied on demand by the administrator.</p>
+<p>Note that updating the operator does not necessarily update the application. Think of updating the operator as updating your configuration management scripts; they don’t do anything until you tell them to. In general, an update of the underlying application should be an explicit action by the administrator and not tightly coupled to an operator update.</p>
+<p>Updating an operator might well, however, update the configuration of the application. For example, imagine a security problem was discovered in an operator such that it omitted a firewall rule for its application. An update to the operator should immediately bring the system configuration into line with expectations, even if the application itself is not updated.</p>
+<p>With the Juju OLM it is possible to publish operators in channels, and consume them from channels, which allows particular models to use riskier or faster-moving versions of the operator. It is good practice to have some deployments using pre-stable versions of operators in order to assess incoming changes.</p>
+<h2>Removing operators</h2>
+<p>The process of decoupling integrated software for removal must be done carefully. In development and test environments it is straightforward to tear down and rebuild an entire environment, but in a long-lived production environment it will occasionally be necessary to retire one component while adding new components to the running services.</p>
+<p>The OLM can orchestrate the clean removal of operators from a system. In Juju this is achieved by removing the application from the model, which triggers a series of events in application units and in related applications to ensure an orderly shutdown and removal of the software.</p>
+<p>Policy, settings and the command-line used  will govern the consequences for storage associated with the removed application &mdash; it may be archived or it may be destroyed as well.</p>
+<h2>Configuration</h2>
+<p>Another benefit of an OLM is consistent configuration of operators from a wide range of vendors and communities.</p>
+<p>The Juju OLM offers configuration schemas and structured YAML config, defined by the operator publisher. The OLM is able to ensure that configuration changes conform to requirements, acting as a consistent guardrail against misconfiguration. Of course, the operator itself should sanity-check configuration to prevent superficially correct config from creating a problem in the service.</p>
+<p>The OLM also offers mechanisms to roll configuration changes out across a distributed system. For large, scale-out environments, it is valuable to avoid shotgun changes which cause ripples to turn into waves. Where a single change will expand across many systems, it is possible to steer the change deliberately and manage the impact precisely at all times.</p>
+<h2>Scaling</h2>
+<p>Scale is a critical ingredient in enterprise software, both for resilience and for capacity. Coordinating multiple integrated applications at dynamic scale is challenging. An OLM that provides a desired-state view of scale, as well as tracking current scale, enables more sophisticated operator design and implementation.</p>
+<p>Dynamic scale requires careful coordination between applications that integrate at a low level. For example, where the scale of one application should drive the scale of a connected application, or where changes in scale in an application require configuration changes in adjacent applications, a central model of application scale removes the need for custom operator-to-operator communications channels associated with scale adjustments.</p>
+<p>The Juju OLM explicitly models application scale, and provides mechanisms for integrated applications to be aware of changes in their own and related application scale.</p>
+<h2>Everyday operations actions</h2>
+<p>Any long-lived workload requires maintenance or administrative activities. Backup, restore, reset, checkpoint, benchmarking, and application-specific operations occur both on a schedule and as interrupts for the administrator.</p>
+<p>Well-crafted operators include these activities as pre-packaged code, just as they include code for lifecycle management.</p>
+<p>In the Juju OLM, everyday activities are called Actions and they are declared in operator metadata as parameterised methods which can be invoked through the Juju CLI or API. Actions run asynchronously by default, and can produce output files as well as output metadata.</p>
+<p>A well-designed and implemented operator ensures that administrators never need actual access to the containers or machines on which applications are deployed, because the full range of actions they may need to perform are expressed in this way.</p>{% endblock %}