The previous blog post talked about the composability of applications. The key element for composing applications is defining the relations between application elements. And supporting relations is one of the advantages of the Charmed Operator Framework – including its runtime, the Charmed Operator Lifecycle Manager.
The shipping container
The metaphor of the intermodal container or shipping container was mentioned in the previous blog post. It is a standardized transport element that’s able to be moved and stored across a logistics chain. And this is a popular metaphor for the standardised way of packaging, transferring, and running software, especially in DevOps automation. However, it lacks one aspect of software containers: When the shipping container has arrived at the destination, the goods are usually unloaded and the container is reused for the next transport.
However, the software container will never get unloaded. Rather, it will keep its payload and continue to be part of the application. Apt real-world metaphors for this setup exist, and are not limited to a pure shipping container. There are containerised electricity generators, containerised housings, containerised desalination systems, containerised field kitchens, or even containerised batteries. These applications stay within the container and leverage the transport inter-modality at the same time – a much better analogy than the pure shipping container. Admittedly, these examples are not as popular in the real world as software containers in the software world.
In the world of shipping containers, not many care for the brand or type of the container. The relevant part is the payload, the goods. Customers choose to buy the goods from suppliers, and the use of containers in the logistics world is usually hidden from consumers, customers, and suppliers. This is also similar in the software world, as users of containerised applications usually do not care about the container technology. The focus of users lies in using the application.
Applications and containers
But in the software world, payload and container are bound together and stay together. So an application or software provider does indeed care about the container technology to make sure that available containers are useful to users. And since the supplier creates the software container with its payload, preparing the relations for composability with metadata must be done correctly when preparing the software container itself.
Application containers – the right place for composition
In order to support relations, the Charmed Operator Framework provides the toolbox to prepare the software container to support composing applications. Users employ the Charmed Operator Lifecycle Manager to compose applications by declaring relations between them. Using the metaphor of a field kitchen packaged in a shipping container, we could say that the Charmed Operator Framework standardises electric power inlets, water pipes, heating and air conditioning, and so forth.
Relations in the charmed operator framework
Transferred into the world of software containers, the Charmed Operator Framework defines how to configure the application, how to integrate the application when it’s used in a composed application context, how to handle relevant events, and much more.
All of these elements are packaged into a Charmed Operator, which is an additional artifact for the application. A Charmed Operator is created for each application. (Read more in this article explaining framework constructs, and get an overview of how Charmed Operators cover relations.) An example of the composition of applications is Charmed Kubeflow, which provides application elements with Charmed Operators so that scientists can stand up and integrate the Kubeflow applications they need for a variety of environments – for example, a personal laptop, a workstation, or a cluster.