What is Juju?

Juju is a state-of-the-art, open source modelling tool for operating software
in the cloud. Juju allows you to deploy, configure, manage, maintain, and
scale cloud applications quickly and efficiently on public clouds, as well as
on physical servers, OpenStack, and containers. You can use Juju from the
command line or through its beautiful GUI.

What is application modelling?

In modern environments, applications are rarely deployed in isolation. Even
simple applications may require several other applications in order to
function - like a database and a web server for example. For modeling a more
complex system, e.g. OpenStack, many more applications need to be installed,
configured and connected to each other. Juju's application modelling provides
tools to express the intent of how to deploy such applications and to
subsequently scale and manage them.

At the lowest level, traditional configuration management tools like Chef and
Puppet, or even general scripting languages such as Python or bash, automate
the configuration of machines to a particular specification. With Juju, you
create a model of the relationships between applications that make up your
solution and you have a mapping of the parts of that model to machines. Juju
then applies the necessary configuration management scripts to each machine
in the model.

Application-specific knowledge such as dependencies, scale-out practices,
operational events like backups and updates, and integration options with
other pieces of software are encapsulated in Juju's 'charms'. This knowledge
can then be shared between team members, reused everywhere from laptops to
virtual machines and cloud, and shared with other organisations.

The charm defines everything you all collaboratively know about deploying that
particular application brilliantly. All you have to do is use any available
charm (or write your own), and the corresponding application will be deployed
in seconds, on any cloud or server or virtual machine.

Can I use Juju with Puppet or Chef or Ansible?

Yes! Puppet, Chef, and Ansible are great tools for writing configuration
files. Juju works a layer above that by focusing on the long term operations
required to keep that software running over time, regardless of the machine on
which it runs. So the Juju charm for an application includes (amongst other
things) all the logic for writing configuration files for that
application - that logic itself can be written in whatever language or tool
the author of the charm prefers.

It is common for people to start creating a charm by bringing together
Puppet or Chef or other scripts which they currently use to automate the
writing of the necessary configuration files. If the charm is going to be
writing and updating configuration for the application, and there are already
tools to abstract that configuration file nicely in your preferred language,
then use that in the charm!

Even better, two different charms from different teams that use different
tools will still happily work together to deploy a solution. In a large
organisation, it is common for different teams choose different tools; Juju
allows teams to pick whatever works for them and their expertise in their
application, but still reuse whatever they want from other teams.

Different charms can use entirely different configuration management tools.

The main change in moving configuration management scripts into a charm is
that one wants to focus only on a single application for each charm. If your
application is made up of many independent services, you will want to split
out each logical application into a different charm to increase the quality
and re-use of that charm.

What about Docker?

Yes, Docker is a popular delivery mechanism and you can create Juju charms
that use Docker to run your application. The choice of internal tooling is
entirely up to the author of the charm. If Docker is the easiest way to
fetch and run the application you are charming, then go ahead and use that.

Juju is about connecting different applications - from different teams,
in a way that is independent of the particular choices that were best
for those teams, and which can be reused by different organisations on
different clouds.

Why are charms event-driven?

The goal of Juju is the reuse of common operational code in widely different
environments. For example, you want to have a single operational codebase that
drives your database install, whether the particular deployment is for test or
development, whether it is in the cloud or on a virtual machine cluster. You
also want to use the same database operational code when that database is
being deployed as part of wildly different application models. Sometimes you
will be monitoring the database with Nagios, sometimes with Boundary,
sometimes with Tivoli.

For this reason, the same charm contains operational code for all of the
possible things one might want to do. When a user links the database service
up to the Nagios service, an event is triggered which executes the necessary
integration steps automatically.

Taking an event-driven approach allows the charms to respond dynamically to
the particular needs of a particular deployment. That makes them more widely
useful, more likely to be reused, and ultimately of better quality.

What are Juju bundles?

A bundle is a collection of charms and their relationships, designed to give
you an entire working deployment in one easy to use collection.

Modern applications are typically composed of many applications - databases,
front-ends, big data stores, logging systems, key value stores…
service-oriented architecture has become the norm. Each application will be
defined by a single charm. To describe the whole application you need to
describe the set of charms and their relationships - what is connected to
what - and we use a bundle for that.

For instance, a content-management system bundle could specify a database and
a content management server, together with key-value stores and front-end
load-balancing systems. Each of those applications are described by a charm; the
bundle describes the set of charms, their configuration, and the relationships
between them. This allows teams to share not only the core primitive for each
application, but also enables sharing higher-level models of several
applications. It allows you to replicate complex application models in a
cloud just by dropping the same bundle onto your Juju GUI.

Bundles can also be deployed in-memory, which allows your developers to spin
up workloads on their laptops to simulate an environment similar to a real
production deployment.

Bundles can be shared publicly or privately. New bundles are added to the
public collection every week. And you can now bootstrap Juju, launch the GUI
and deploy a bundle with a single command. That means you can go from zero to
a full cloud deployment in seconds with the right bundle.

What about Windows or other Linux operating systems?

Yes, charms can be written to deploy Windows applications. And those can be
deployed right alongside Linux applications (albeit in different machines!) in
the same large-scale application model. If you need to integrate
Active Directory on Windows with Hadoop on Linux, this is the way to do it.

The Juju client can run on Linux, Windows, or macOS. And of course, once you
have the Juju GUI up, all you need is a web browser to manage your environment
and deploy more software, or scale up your existing applications.

Can I use Juju to move applications across clouds?

You can use Juju to recreate application architectures on a wide number of
clouds and platforms. In other words, if you have deployed a set of
applications on one cloud, you can recreate all the same applications with the
same relationships and the same configuration, on any other cloud or
“substrate” that Juju supports. If you are migrating from cloud to cloud,
this solves at least part of your problem, which is the operational lock-in to
that cloud. However, you will still need to copy the data across from cloud to
cloud manually.

What language are charms written in?

Charms can be written in any language or configuration management scripting
system. Chef and Puppet are common, more complex charms tend to use Python.
Charms have been written in Ruby, PHP, and many charms are a collection of
simple bash scripts.

Your choice of language would be influenced first by what’s already been
done - if there is an existing charm for the application you need and you just
want to add a feature, it’s probably best to contribute to that existing
charm. Also, if there is not yet a reasonable charm for your application, but you
have existing scripts yourself - for Puppet or Chef, or in Bash or Python -
then use those as the starting point of your new charm.
A charm is also a collection of scripts that handle different kinds of events.
Those scripts do not all have to be in the same language. If there is an
existing charm, mostly in Ruby, but it does not handle a connection to your
favourite monitoring system, you could add the scripts that provide the
integration you need in the language of your choice.

What charms are currently available?

Charms are available for hundreds of common and popular cloud-oriented
applications such as MySQL, MongoDB, and others, with new ones being added
every day. Check out the public charm store for an up to the minute list of
charms:
Juju Charm Store

Are charms open source? Under what license?

Charms can be released under whatever license the author prefers, there are
charms under just about every kind of license out there today. In many cases,
charms follow the license of the applications that they deploy, but this is
not a requirement. There are open source charms that deploy proprietary
software, for example, and the reverse would be possible as well.

Juju itself imposes no requirements on the license of the charm. Check out the
details in the charm store.
We do encourage the charming community to keep their charms open source in
order to stimulate the sharing of best practices and better code, and most
charmers have followed that guidance, picking a license that works for them.

Can I write my own charms? How?

Absolutely. A charm is just a collection of scripts and metadata. You can get
started quickly by copying existing charms - respecting their license if they
are copyleft!

Use the language of your choice. It’s normal to get something
quick-and-dirty working in bash, then switch to a more sophisticated language
as the charm takes shape or becomes more complex. Charms are code -
operational code - so you want to think of them that way. Use revision control
from the start, collaborate with colleagues, and consider including test
suites so you can automate quality control for deployments very easily. There
are extra Juju charm tools to make it easier to test
charms, and templates that get you started quickly.

If you want, you can also share your charm with the world and gain feedback
and contributions from others! In our experience, the more widely a charm is
used the more useful it becomes. Different teams bring different expertise -
security, performance, scale, and all of those things make for improvements in
the charm that are very hard for a single team to achieve.

What are the best workloads to try with Juju?

Juju excels with scale-out workloads like big data, PAAS, cloud infrastructure
such as OpenStack, or container management systems. Pick your favourite cloud
and launch a Juju server. From the integrated GUI, you can drop one of the
bundles from the charm store into the blank canvas.

Hadoop ®
Try one of the simple HDFS bundles or deploy a more complex
sentiment-analysis application to scan twitter streams for brands you are
interested in.

Cloud Foundry ™
Spin up a multi-service PAAS on whichever cloud you like!

Docker
Try Kubernetes, the Docker management system from Google, on any cloud
supported by Juju.

OpenStack ™
Deploy your own private cloud on bare metal servers. If you want to
evaluate OpenStack, you can use Juju to spin it up on VMware too.

How does Juju use containers?

Juju can use both Docker-style application containers and LXD-style system
containers. Charms can use Docker to deliver, start, and stop the workload
they are deploying. Juju administrators can use system containers just like
virtual machines but without the overhead of virtualisation. For example,
to deploy three different charms onto three separate system containers on
“machine:0”:

And if any of those charms use Docker then you would have Docker running the
app inside an LXC system container! For extremely dense deployment on clouds
or on laptops, containers offer much greater utilisation of the system
capacity than traditional virtual machines.

Where can I get enterprise-grade support for Juju and charms?

Canonical, the company behind Ubuntu, provides commercial professional support
for Juju.

Landscape, our enterprise systems management tool, is included in all of our
support packages. Check out Ubuntu Advantage, Canonical’s support programme,
and choose the level of service you need: