Juju is a universal ‘operator lifecycle manager’ (OLM). Operators are a next-generation automation approach, succeeding configuration management, that has been popularized in the context of Kubernetes.
Operators in Kubernetes are containers that drive other containers, and the ‘operator pattern’ is the idea that it is easier to manage a high-level piece of software, the operator, than all the low-level pieces with all their low-level details. So the operator pattern is all about software that drives software.
The lifecycle manager in an operator framework provides a set of services to operators. Beyond basic lifecycle (install, update, configure, remove) the Juju OLM provides integration services to enable operators to be combined through declarative, automated integration.
Juju is a universal OLM because it supports operators both for cloud-native apps — Docker images on Kubernetes — and for traditional apps on machines which would previously be automated with configuration management systems. Juju takes the operator pattern beyond K8s and makes it a universal capability, for any software in any environment — across public clouds, private clouds, and bare metal.
The ability to use operators on classical machines as well as containers allows operators to be used for infrastructure-as-code. Software-defined storage, private cloud infrastructure, and scale-out data lakes can all be automated much more efficiently with operators than with traditional config management.
At the application layer, Juju supports traditional applications on Linux and WIndows, as well as more modern containerised applications. This allows both legacy estate and newer containerised estate to be unified in a single operating regime.
The operator pattern encapsulates software operations in a reusable package. This has the effect of shifting complexity in operations code development to an expert forum, for reuse by everybody else. This is the same pattern that we see with application software, or the Linux kernel. Most people who use Linux don’t know how the kernel works, but they get the benefit. Operators are this, for operations.
Reusable packages of operations code get wider scrutiny which helps identify security issues faster. They attract a wider range of contributors and with that, a wider range of skills. Security is a many-layered challenge, and the breadth of participation in operator development raises the bar for all users of those operators.
Since all deployment and configuration of the application is handled by the operator, manual mistakes are fewer and easier to discover. Policy can be enforced consistently, regardless of the cloud or infrastructure being used.
Reuse drives quality in all code, not just operations code. Traditional config management code was almost never reused, because it is very hard coded to specific scenarios. While someone might copy a snippet here or there, they would rarely turn that into published, shared libraries. By contract, in the Juju operator development community, reuse and sharing are the norm.
It takes time and experience to improve operations code quality. The use of structured languages, test harnesses, and open source contribute to the high level of quality in operator code.
The use of an OLM ensures a consistent approach to deployment, scaling, configuration, integration, updates and removal. The ability to unify this experience for both traditional and Kubernetes infrastructure is particularly valuable in larger organisations that have a material pre-Kubernetes estate.
Reuse of any codebase significantly reduces cost. This is particularly true if it is possible to reuse code across many organisations. In the case of Juju driven operators, the community expectation is perfect reuse, across any organisation, and any cloud. Operators are developed and tested to achieve that goal.
In Juju, we call the package of operator software a ‘charm’. It includes metadata about the application it drives and the environments in which it can be used. For example, it might say ‘I drive MySQL on Kubernetes’ or it might say ‘I drive MySQL on Windows’. On Kubernetes, that charm is installed in a container. On traditional machine environments, like bare metal or VMware or a public cloud instance, the charm is installed on the machine in a particular directory.
The operator code handles the lifecycle of the application — install, update, configure, upgrade, removal. It is possible to have variations of the same operator that handle the same application on different kinds of environments, for example, on Windows machines, or on Linux machines, or on Kubernetes.
Since the operator does not handle provisioning itself, it is cloud-neutral and hence enables multi-cloud operations. You can think of the operator as ‘perfectly portable operations code’ which can be shared between teams, companies and communities.
Operators can be developed and used locally, but it is more convenient to use a central shared repository for operators from a range of communities and vendors. Charmhub.io is the preferred operator repository and the Juju OLM will search for standard operators there.
In the Juju OLM, the operator also handles integration between different operators, even from different vendors, and potentially across different clouds.
The charm metadata describes integration points, which allow declarative lines of integration between endpoints on applications.
It is generally possible to integrate applications that are running in completely different environments. For example, one application might be on private bare metal, the other might be on a public cloud Kubernetes cluster. This allows for multi-cloud integration and also integration between new Kubernetes applications and legacy estate.
The operator code itself can be written in any language, but in our community we recommend Python and the Python Operator Framework. An operator is an event handler. The operator reacts to updates from administrators, from the underlying infrastructure, and from other operators, and adjusts the application configuration accordingly.
The Python Operator Framework includes an event loop which greatly simplifies operator code and enables reuse and sharing in the community.
The Juju OLM takes a model-driven approach to operator lifecycle management. Instead of treating each operator as a distinct entity, it groups them into models which share a substrate (cloud or Kubernetes cluster) and admin permissions. Admins describe their intentions in the model, and operators do the work of bringing those intentions to fruition.
Machines, storage classes and networks are described at the level of the model. Each operator in the model can then be allocated or bound to those resources dynamically. So we can decide exactly how much CPU and storage to offer a particular application, and where on the network it should present its services.
Models capture business intention very clearly, so they are a better tool for high level operations than configuration management systems, which record only the low-level consequences of those decisions.
Juju is focused on application management, not configuration file management. The model groups a set of such applications, each of which is associated with a charm operator package.
The application might be deployed on the model substrate by the operator, or it could also be SAAS, or a proxy charm which represents a physical or software appliance accessible on the network which the charm can control remotely.
In each model, a set of applications are described in a graph representing lines of integration between endpoints from their charm metadata. Each application has an associated scale, which maps to the number of instances of that application which will be clustered together.
A key outcome from the Juju OLMs ability to model integration is that complex scenarios are handled through operator composition. It is much more effective to compose reusable elements which are designed to “do one thing well”, than it is to create a custom and unique body of code that reflects a unique and complex situation.
Integration is generally done between applications in the same model. However, it is also possible to integrate applications in two different models with the permission of admins on both sides. This allows one group to offer a service to another group, a form of ‘homegrown SAAS’.
The central component of the operator lifecycle manager is the controller, which can be highly available, and provides APIs for web GUI dashboards, CLI interfaces, and services to agents which drive the actual operators.
The Juju CLI, controller, and agent are all golang binaries. The operators themselves are invoked to handle specific lifecycle and integration events associated with their particular application unit.
JAAS.ai is a cloud-hosted SAAS OLM offering. JAAS (“Juju as a service”) is also available on premise to create a single unified enterprise multi-cloud OLM capability with audit, access controls and a unified view of operators on both public and private estate, on Kubernetes and on machines.