(MODAClouds) Juju

Overview

Juju is a Canonical sponsored open-source project, that describes itself as a solution for service orchestration [Juju-3], by taking care of tasks from deployment, through configuration and up-to custom tasks such as backups. Moreover it focuses mainly on cloud-based environments, although it currently supports only EC2-compatible API's [Juju-1] [Juju-4].

Juju's concepts are quite straight-forward:

service

It is a logical construct, and can be seen as an application layer or tier, such as the MySQL cluster, or a set of application servers handling the logic, etc. [Juju-5]

unit

It represents a software component, a single instance of potential multiple ones, that fulfill the tasks of a particular service. For example it is one MySQL database instance part of potentially a cluster thereof, or a single web-server that receives a portion of the load. [Juju-5]

relation

Relations can be established between two services --- actually between all the units of one service, and all the units of the other one --- and is used to denote functional dependency. The matching of relation partners is done based on interfaces which one service requires, and the other provides. For example an application server might need a database, thus a database relation is formed between the two. Moreover the same service might be in relation with multiple other service types, like in our case the application might also need a cache and a messaging middleware. [Juju-5]

charm

All service units are deployed, configured and establish relations, as prescribed in a set of files, that comprise a charm. [Juju-6]

hook

The actual active components of a charm are the hooks, nothing more than executables, potentially written in any programming language, which are called by Juju at different stages of the service's lifecycle. [Juju-6]

environment

Everything that Juju manages is in the context of an environment, which equates to a cloud provider and credentials [Juju-4]. Thus it allows the same cloud provider to be used in different environments by having a separate set of credentials (access and secret keys). Technically this requires an EC2-compatible and S3-compatible deployment, or it can be a testing environment based on LXC.

Compared with Chef or Puppet, Juju is more focused on the application life-cycle, offering more automation out-of-the-box, such as the relations between different services, and being more flexible by allowing it's hooks to be written in virtually any programming language, as compared with Ruby-only for the former solutions. [Juju-6]

Juju's architecture and philosophy is quite simple, it starts one VM for management purposes which then provisions and delegates actions to the other VM's where the service units run on; then to ensure the persistence of the state it uses an S3-like store to commit snapshots of the running service units, their configurations and relations, and the running VM's.

Characteristics

Limitations

Although sufficiently flexible for our purposes, Juju does have some dissadvantages:

• currently it supports only EC2-compatible API's [Juju-1] [Juju-4], although there is an option to run a simulated version based on LXC on a single machine;
• it also requires a S3-compatible permanent storage facility [Juju-4], that is used to store the state of the cluster;
• it supports only deploying one service on each VM [Juju-1] (thus a 1:1 mapping), although there are workarounds and plans to alleviate this limitation;
• the management VM is currently a single-point-of-failure, although the cluster state is committed at regular intervals in a S3-compatible store;
• it is tightly tied to the Ubuntu Linux distribution [Juju-9]; however Ubuntu is currently the most popular distribution, and the default choice for most developer and infrastructure providers;

Notes

To a certain extent it can be seen as a very lightweight PaaS, that is very much similar with solutions like Amazon Elastic Beanstalk, Cloudify, and others. On the other hand it is not focusing on developer aspects of the application, but on operational ones.

A nice feature of Juju, is that at the time of instantiation of a particular service the operator is able to customize its behavior by providing a set of parameters that alter the behaviour of the charm's hooks --- obviously these parameters must be implemented by the hooks themselves. Building on that, and again if the hooks support, the operator is able to change some of these parameters and then all the service's units react by reconfiguring themselves accordingly. [Juju-7]

Juju goes even further and allows the related services to influence one another, like exchanging endpoints or access credentials, by allowing configurations scoped at the relation level, which when changed, trigger hooks for each of the other partner service's units. [Juju-6]

Related to the backing infrastructure, as stated, it requires an EC2- and S3-compatible environment. And although it is dependent on Ubuntu as the Linux distribution [Juju-9], it can work on plain non-customized variants, thus it could work even for those providers that don't allow customized images. As expected the operator is also able to specify the exact VM type, and if the provider supports it, the image or availability zone, either for the entire environment or a particular service. [Juju-8]

On the downside, Juju doesn't automatically destroy the VM's as they are kept to allow the operator to inspect their state. Fortunately however Juju is able to deploy a different type of unit on an available VM.

ModaClouds integration

As previously stated we could see Juju as a very thin PaaS, thus we could use it to deploy the more conservative applications, that have more elaborate requirements, for which even a PaaS like CloudFoundry would be too limiting.

The strong point for Juju in our case, is that it provides a very flexible and dynamic service reconfiguration and interaction. Thus it would enable us to more easily implement the dynamic scalability and reconfiguration features.

Even if we don't intend to reuse Juju due to its close ties with EC2-compatible providers and Ubuntu, we could re-use their charms, especially the hooks, because they already implement all the needed functionality to configure the managed service.

References