Why do you use Juju?

Hi, everyone! This is Dora, the new Technical Writer for the Juju Team :juju:. Trying to figure out the Juju message for newcomers. As current users, what would you say: What is one reason why you use Juju?


I use juju because it provides programmaric control over deployment, configuration and day two operations/maintenance of my infrastructure. This, using a single tool/framework rather than many. Its REAL infrastructure as code, not some 1990 config-management like ansible or whatever.

I also use juju actions to automate complicated admin tasks, which otherwise would be error prone and/or risky to perform manually.

I also use juju grant of juju models with colleagues - which is alot easier and secure than pass around ip-addresses, passwords, pictures and docs about complicated systems. This adds efficiency and is a great collaboration feature.


Super informative. Thanks a lot, Erik!

1 Like

For me, I sensed Juju was different from other tools that came before (As Erik said, 90’s config management of the old linux sys admin days)… the ability to encapsulate your application and “relate” it to other encapsulated apps… is to me very analagous to cellular biology. Different fauna and flora coexisting, feeding and working in unison… where as in the olden days (and in some orgs even today…) you have a lot of ad-hoc scripting taking place… but less cohesion from one team silo to another… Juju charms let me focus my work so that I can encapsulate it in a container or VM, open up the metadata it needs to either share or exchange… and the reactive programming state diagram is very akin to the sorts of inner workings of a single cells components…

so I use juju because it feels more like the way one would want to write something that will survive… even if I switch cloud providers or switch other pieces of my stack… the core charms I can pick up and take to wherever that other cloud is.

When I work with people, they start to ask me how this differs from Docker and the beauty is… “It’s just linux” in the local LXD containers… whereas with other container technology you have to almost learn everything over again… networking, storage mounting… K8s has it’s place… but it’s not the be all end all … especially when we start to talk about bare metal deployments or deployments which require real-time OSs…


What @emcp said.

Also, it came to my mind that I can maintain and develop my infrastructure EXACTLY as I would for a normal - modern - software development project. E.g. code, review, CI/CD, unit-tests, integration tests, releases etc. None of the other tools I know of lend themselves to this paradigm. The extreme benefit from this, is that your developers and infrastructure engineers will speak exactly the same language and can agree on both methods and principles around software developing “generally”. This is contrary to now, where there is almost two different kind of disciplines “devs” vs “ops”. This goes away with juju and you get a discipline that is all about software development (not some lame configuration management). This is “Infrastructure as Code” for real. Reject the folks telling you ansible is code just because they commit to github.