What DevOps tools does Juju help you to avoid?

Juju is a powerful technology. One of its biggest strengths is its ability to simplify the day-to-day lives of an operations team.

Here are some initial thoughts about the tools that you no longer need to wrangle because Juju takes care of things for you. Any other suggestions? Can you help to expand and fill out the matrix?

Task Tools used without Juju
Provisioning Terraform, cloud APIs, cloud provider consoles, kubectl
Instance customisation cloud-init.io
Installation Puppet, Chef, SaltStack, Ansible, Helm, …
Configuration Puppet, Chef, SaltStack, Ansible, Helm, …
Upgrades todo
Networking configuration todo
Storage configuration todo
1 Like

Still, the weak spot is the limited support for other distros than Ubuntu.

I’m struggling massively with centos and I can’t imagine what pain other distros face.

It have to be said and it blocks huge communities from adopting.


Absolutely. RHEL/CentOS is huge and Juju should be able to play politely in that environment.

The work that you’ve done with cloud-init is deeply appreciated.

This probably isn’t good for marketing, but if I’m being honest, the biggest baddest tool that Juju eliminates for me is Kubernetes and/or Docker swarm.

Me and my partner strongly believe that Kubernetes is over-engineered and over complicated for almost any use-case. Docker Swarm was our way to prevent the need for Kubernetes as it could handle almost everything easier ( except for the fact that nobody will write tools such as storage management solutions for it ).

Juju, though, replaces both Kubernetes and Swarm. It solves real-life problems like hosting databases and more complicated scalable applications by allowing you to add logic to operations such as start, stop, upgrade, etc., and it does this without trying to make you make your app stateless.

PS: And if you have to deploy Kubernetes, like, because your boss told you to, Juju is probably the best way to do it.

1 Like

That’s a very fair position. I think that there are lots of people who feel that Kubernetes is a misstep for the industry. It’s great that Juju is an option for people like that!

One of the things I’ve been stressing to people as I’ve talked to Juju about them is that Juju is very adaptable. It adapts to lots of workflows, rather than imposing one on operations teams.


I have a slight addiction with IaaS and as a result I’ve become a heavy Ansible user just because it’s platform agnostic on tasks ranging from provisioning Virtual Infrastructure all the way through to updates/upgrades.

However Juju trumps all when doing the real heavy lifting like standing up and managing complete infrastructure frameworks like Openstack, Hadoop and K8s. I personally do not have the patience or skill to deal with that level of complexity so Juju will always have a place for that kind of thing over Ansible or Terraform or the likes there of.


Very well put in you post.

A crisp observation is this:

In my view, two fundamental strengths of ansible (which we can learn from) are:

  1. It’s really platform agnostic = reaches large user bases.
  2. It’s lightweight agent = can be used on computers with limited access to fancy software.

Juju miss out on these points I argue. Let’s look at it:

1: Juju supports Ubuntu. Even if it’s possible to get the juju agent to run on other distros,
the charm ecosystem has almost nothing to offer. If you use 'charm create - t ’ it will never create a bulk charm that deploys on centos for example. This is because both charm-helpers and layer-basic are broken with anything that does not use ‘apt’ as package manager. Also, juju rotates around the ‘ubuntu’ user which becomes awkward when running on a centos system. I have to prep my models for centos with injection of a ‘ubuntu’ user which also needs to be consistent on UID/GID.

What if juju came to run smooth on at least any Linux distro and we made an effort to get the most core charms be truly agnostic. The “snap” package system could be helpful here but more generally, a general/agnostic support of package managers would be what’s missing… Examples are opkg, npm, snap, yum, etc Yeah, and introduce the ‘juju’ user that has a user-home dir which is not at /home is probably also critical. I could even argue it’s not posix compliant (Ubuntu is not a person and should probably not be living in /home). I case where this matters is when systems have home directories mounted over nfs. juju ssh myunit/0 will stop working and you effectively lose your ability to login.

2: Lightweight juju?
I will admit I’m not sure how the juju agent is consuming resources. But I would guess it’s rough.
Even if I’m wrong (which I hope) I want to see if it can be used to deploy stuff on IOT devices. Starting with Rpi, NVIDIA Jetson, etc. I would like to be able to deploy ROS2 robots with juju. I would also want to be able to run juju on openWRT switches and LEDE which uses opkg package managers. Linux embedded systems are desperate for a orchestration tool.

Does anyone know of a juju agent that runs on Rpi?


Damn! @erik-lonroth your clarity and vision is something to stop, sit down and listen to. :clap:

1 Like

I thought that the juju cloud-init for centos created an ubuntu user and group as the tool uses it for things like ssh and scp.

We do need to do a better job around charm support for other operating systems.

It isn’t as lightweight as I’d like it to be. Right now it feels a bit heavy with multiple agents running. Most of the time they aren’t doing much. I have plans to unify the machine and unit agents for normal machines, so we’d go to a single juju agent. We’d avoid the issue of multiple processes, and it should be more lightweight.

1 Like

It is. That’s also part of a two side problem :

  1. The user is named ubuntu, which makes little sense on other distros and causes confusion.
  2. The ubuntu user has its home directory in /home which is badly aligned with systems that for example have ldap or nfs home directories or autofs.

Introducing the ‘juju’ user with a home directory in let’s say under: /usr/local/juju-home would resolve those issues.