The real magic is here - charms in Juju

In this post we'll focus on the most crucial thing of Juju's models - charms. To make the long story short - charms are software components containing instructions necessary for deploying and configuring applications. You can think about them as packages containing both installer and scripts designed to make a thing work automatically. 

Important thing is the fact, that scaling in Juju happens having a charm in mind. For example - if you have provisioned a single machine running a database and you scale it, you'll have it deployed to N machines(depending on your demands). This, however, won't affect other charms dependent on this specific one.


A charm may have a relation. From the modelling point of view, adding a relation creates a virtual link between two or more charms. In fact when you add a relation, Juju will arrange a communication protocol for linked charms to allow them to exchange necessary information. You, as a model author, can just sit and relax.

When obtaining a charm for the store, you can ensure what are the possible relations for it

This is what makes Juju so powerful - once relations are configured, most things just happen seamlessly. 

Status of a model while a charm is being deployed


Scaling is the second very important feature, which is what makes Juju so attractive. All it's about is to tell a controller to scale a charm up(or have a script, which will do it for you). The way how it is handled in Juju depends on the charm - some charms require external load balancer to actually distribute traffic, some have build-int load balancing and need only a command to grow.

When scaling applications, you can either co-locate them on a one machine or spawn multiple small machines and handle each one separately. Either way you don't care about what happens behind the scenes - Juju will orchestrate everything and make sure it works.

Status of a model when scaling from a single MariaDB instance to 4 different ones. Note that 3 instances are co-located.


In this post we played a little with charms, which are the very foundations of Juju. We're aware of features like scaling and relations and what are the ideas behind them. In the last post we'll talk a bit about managing our controller - having multiple models, importing them and setting constraints.


Clouds, controllers and models - first steps with Juju in Azure

In the previous post we created an environment in Azure using Juju, which is ready to be modeled. We're really close to make it work, but before we make another step, I'd like to make sure you're familiar with some basic terms, what should help you in the next episodes. Let's get started!


As I said previously, Juju comes with a seamless support regarding all major clouds like AWS, Google Cloud or Azure. It's also possible to use it with e.g. private clouds like OpenStack - the possibilities are unlimited. When we're talking about a 'cloud' here, we're thinking about a whole environment managed by Juju's controllers.

To make things even cooler, Juju gives you a possibility to select a region where you'd like to get started. Of course it has some predefined settings, but you're not forced to choose "the-one-and-the-only" region. What is more, both available clouds and regions are not hardcoded - it's possible to fetch updated data when needed.


When you've chosen your environment, you need something for controlling it. That's the purpose of controllers - nodes in your infrastructure, which are responsible for managing it. The important thing is, that a controller is a machine itself - it's both an element of Juju's structure and a computer, which needs resources. No matter how many machines you spawn later, a controller will always be your machine-0.

A schema of a basic structure used in Juju


Models are virtual environments attached to a controller. By default a controller has two models - admin and default. In fact 'admin' model is designed for some internal stuff and shouldn't be used. 

A simple model of a Wordpress instance and a MySQL database on two machines

What is more, models and controllers can be switched anytime. You can have multiple configurations prepared and easily switch between them when needed. The best thing is that models can be constrained - this is a complex topic however and we'll cover it in the future posts.


In this short blog post we learned the most basic terms in Juju. We know what are the main parts of our system and we're aware of their connections. In the next post we'll dig deeper into different components and try to prepare a simple model, which we'll try to reuse.