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.


EventStore on Azure and Ubuntu - it's a piece of cake! #4

Finally - the last but not least post about setting your own EventStore instance using Ubuntu on Azure. We've already prepared the majority of work needed here, so it shouldn't be difficult to adjust is just a bit to use DNS instead of hardcoded IPs.


Currently our configuration looks like this:

RunProjections: None
ClusterSize: 3
DiscoverViaDns: False

Clearly the first change is to get rid of the DiscoverViaDns property. The reason why we're going to remove it is the fact, that it's set to true by default. However, it appears that we need two more properties: ClusterDns and ClusterGossipPort. Additionally we'll remove the GossipSeed property as it also won't work here anymore. Let's get to work!

Network, DNS and Azure

When we created Ubuntu VMs in Azure we're given a single instance of a virtual network. You can think about it as a logical representation of your network in Azure - you manage IPs, DNS and other settings without installing physical devices. It gives you isolation and security - if you want to, you can forbid both inbound and outbound traffic. What we're interested in right now is its DNS capability. Currently you have two options:

  • use a DNS provided by Azure
  • use your own DNS 

Unfortunately using the former won't work here - we have to add records manually, what is not allowed when using Azure DNS. Obtaining and configuring a DNS server is beyond the scope of this post - if you're interested take a look here. The good thing is that it's still possible within Azure and additional tools are required. Once you have your DNS, the configuration should look similar to:

RunProjections: None
ClusterSize: 3
IntTcpPort: 1111
ExtTcpPort: 1112
IntHttpPort: 2113
ExtHttpPort: 2114
ClusterGossipPort: 2113

DNS entries

The tricky thing here is to set correct entries in your DNS server. What you have to do here is to add an A entry pointing to your private IPs inside a network. Note that there's no concerns in doing this - it's a common practice. The one issue here is that it describes a little how your local network looks like - while accessing domain from an Azure network will point to the correct machine, when one tries to access it from an external network, he will be redirected to the private IP being the same as the one used in an entry.


This is it - we've went through installing, configuring and managing EventStore using Ubuntu and Azure. I strongly encourage you to discover other OSS solution, which could be run using such configuration and play with them, it becomes more and more fun.