Let’s remember the time in the 2000s when companies introduced their cloud computing offerings at a large scale. New services were put into the popular IaaS, PaaS, and SaaS categories. New kinds of storage and messaging technologies were promoted. Also, novel approaches were discussed, such as designing applications for horizontal scalability and eventual consistency. People were excited when Netflix – at that time, a business popular for selling and renting DVDs – began to migrate their business of streaming videos onto the AWS platform in 2008.
If Netflix could run their business on AWS with their massive amount of video data, the thinking went, then cloud computing would be useful for many other businesses as well.
The intermodal container
Back then, there was concern about the ability to migrate cloud applications between platforms as the industry feared a lock-in to particular cloud vendors. Projects started to work on solutions that would mitigate vendor lock-in. But it took years for these solutions to make cloud applications vendor-independent from the platforms they are hosted on.
To explain the need for – and value of – these solutions, the community settled on the metaphor of shipping containers. Shipping containers existed for more than a century, however, worldwide standardisation was initially missing. In the 1950s, standardisation kicked in, and it freed huge efficiency gains across the entire logistics chain: trailers, cranes, cars of trains, and ships were capable of transporting the standardised “intermodal” container. Accordingly, transporting “dry goods” greatly accelerated, and shipping costs massively decreased.
Making applications intermodal – Kubernetes
The same idea of standardisation could apply to cloud computing for providing applications.
The thinking was that applications should be sufficiently standardised in terms of installing, running, or migrating them between different platforms or between public clouds and installation on the premises of an organisation (private cloud). With standardisation, applications also became ”intermodal” and could be automated.
Popular technologies in this field, such as the Kubernetes project, came to light some years later. And along with Kubernetes, we have a plethora of additional technologies available today, such as Docker and Linux containers. In conjunction with readily-available registries hosting pre-packaged applications, downloading and installing is easy and straightforward.
The application? The applications!
The next big step comes with cloud applications that are composed of several elementary applications.
Usually, applications do not consist of a single binary that is executed with a single command, like when a user double-clicks an application on the desktop environment to start it. Rather, cloud applications can have a Web frontend (maybe for a Web UI or a REST interface), a business logic part, a database, and maybe other functions such as user authentication and authorization, logging, and monitoring or messaging.
All of these elementary applications together can form a new composed application. And today, the bulk of the effort is spent forming this composition: integrating different applications and services in order to create a new offering.
Application composability
The Gartner hype cycle lists the composable applications as a trend almost at the peak right now – indicating readiness for adoption soon. But what is required for application composability?
Today, many applications are downloaded in their raw form, and composition is done ad hoc. The composition of individual application elements is usually implemented for a single case of a composed application. For example, exchanging a relational database in such a composition with another one requires changes in the source code, scripts, or declaration files implementing the composition. While much of the existing first composition implementation could be possibly reused, the result will just cover a second specific composition.
The obvious next step is to provide reusable application elements that are ready for composition, because this would improve the degree of automation.
Compose with Juju – the charmed operator framework
Now Charmed Operators come into play. The Charmed Operator Framework covers the very central concept of relations. Relations connect standardized mounting points for application elements. Like containers, which have the standardized mount points at every corner, relations connect standardized interface points where the application service is being exposed. A tool that processes and manages the relations facilitates the composition of applications – instead of writing code.
The relations concept when providing reusable application elements makes applications more “inter-modal”. In addition, nice graphical views of the relations are available in Juju in the dashboard as well – for example:
Further reading
- Juju Introduction: https://juju.is/#what-is-juju
- Basic Juju concepts: https://juju.is/docs/olm/quick-reference
- Juju Relations: https://juju.is/docs/sdk/relations
