Integrating software from different vendors or communities is expensive. In most organisations, integration code is the bulk of the legacy operations code which slows down innovation and makes upgrades more difficult.
Two organisations that have both chosen MySQL and Wordpress should not have to write the same integration code independently just to get both of those applications up and integrated smoothly. And yet, with configuration management tools such as Ansible, that is exactly what those organisations have to do.
The universe of applications is relatively small — most organisations will be running MySQL, many will also have Wordpress. Organisations often choose the same software, and in many cases, they choose the same combinations of software. It makes sense to reuse the integration code which glues them together.
With Juju as an operator lifecycle manager, those organisations can share not only the code to operate the two workloads, but also the code to integrate them.
The ability to integrate operators allows for operator composition. Very complex scenarios can be addressed by combining simpler reusable operators. Instead of writing a large amount of custom integration code, organisations can compose operators into application graphs which address the requirement.
Operator composition is essential for reuse, which in turn improves the quality of software. The more scenarios an operator can be useful for, the more it will be reused, and the more it is reused the more it will be driven to be full-featured and bug-free. Open source operators benefit from the principle that ‘many eyes make bugs shallow’.
The UNIX philosophy that software should ‘do one thing and do it well’ applies to operators. Each operator should handle one piece of software, and it should aspire to represent all the ways that software can be used. The operator should express integration possibilities as cleanly and comprehensively as possible so that it can be combined into as many scenarios as possible.
A community process is extremely effective at surfacing the range of possibilities and requirements for operator composition, so the Open Operator Collection serves as a single venue for discussions between operator designers and their users. Since composition is the key ingredient of efficiency, it is more valuable to have those conversations in a central location than to fragment the discussion across many forums.
Typically, the entire scenario is captured in a single application graph in a single model. It is possible, however, for a large scenario to be split across several different models.
This may occur when different people are responsible for different subsystems. Administration permissions align to models, so having portions of the scenario in separate models allows for different permissions to be assigned to those separate portions. For example, in a machine learning operation, there may be one group who specialize in the data lake and another group which specialize in machine learning. Putting the operators for those two portions of the scenario into different models gives each team control and focus in their area of expertise.
The ability to offer applications for integration by other teams enables companies to provide SAAS internally. Any team can offer applications from their models to other teams as SAAS.
Cross-model integration works even if the two models are on entirely different clouds. This enables rich multi-cloud scenarios and multi-cloud operations, with services placed on whichever cloud is most appropriate based on services, policies, data locality and regulation.
Each model in Juju has a single substrate. All of the operators in that model run on that substrate. For example, a model may be a machine model on Azure or a Kubernetes model on AWS. If it is necessary to combine software from two different clouds, or to combine machine and containerized software, then the application graph would span multiple models reflecting the different substrates involved. In this way, a single scenario can span multiple public and private clouds, and span both machine-based and container-based applications.
Applications in different models can be integrated if the administrators in both models agree. The admins on both sides need to say they are happy for admins on the other side to integrate with their application.
Third-party SAAS can be integrated too, with an operator which drives the SAAS lifecycle instead of installing or running the application locally.
The Juju operator lifecycle manager introduces declarative integration for operators. The operator itself is packaged in a charm. The metadata for each charm declares a set of typed integration points. For example, ‘webgui’, ‘db’, ‘logs’ might all be the names of integration points on an operator.
The integration points have a direction, think of it as ‘inbound or outbound’. When two operators have integration points of the same type but opposite direction, then they match and can be integrated.
What matters is the type and direction of the integration points, not the name. Names for the integration points on an operator must be unique to identify the point explicitly, and are usually chosen to help understand how the integration point should be used. Multiple integration points on the same operator may have the same type and even the same direction, but they must have different names.
There is no requirement for globally unique names, however. So, if two operators from different vendors have integration points of the same name, they still might not be integrable. It is important to check the type and direction of the integration points to know if they can be integrated.
Use the ‘relate’ command to integrate two operators.
juju relate mysql wordpress
In the simple case, if there is only one pair of matching integration points for those two operator charms, then this command will work. If there are multiple possible ways to relate the two operators, with multiple pairs of matching integration points, then you will need to name the points explicitly.
juju relate mysql wordpress:db
We call the integration line a relation and it may be joined or broken at any time — in other words, operators can be integrated and then the integration can be undone.
The Juju operator lifecycle manager will deliver a series of events to both operators in an integration. Operators become aware of their integration counterparts through these events. If the relation is broken, a series of events will be delivered to both operators to inform them of the change.
The Juju OLM allows each operator to publish information which can be read by the operators on the other side of the relation. For example, the MySQL operator might offer up the information needed by Wordpress to form the connection string — username, password, IP address, port, server certificate, database name.
We call this ‘relation-data’ and it can only be read by the operators on the other side of the specific relation in question. An operator can only see the relation data for its own relations, not for other relations on operators it is integrated with.