I was recently out at a Christmas function and had people ask what I do. Now I’m sure others have had this problem before, but how do we describe Juju? What I’m wanting to get some form of concensus on is the ten word answer, and the 30 second answer. This is mostly because I find myself stumbling somewhat to provide a short simple answer to what is actually quite a complicated system and idea.
This post is more to solicit ideas and to refine the words.
Juju
cloud agnostic applictaion modelling
configuration and operations for distributed cloud application
Charms
Open source operations - not all charms are open source
Encapsulated configuration and operations?
I feel that in order to be able to tell Juju’s story well, we need good answers for these.
I tend to describe Juju to the non-tech folks that ask what I do is something like
You know the websites out there running on racks of servers,
Juju is tooling to help easily manage your servers when they
get up into the 10, 100s, and thousands.
If they’re more tech savvy and aware of things like the various public clouds/etc I’ll get a bit more interesting.
Juju is tooling to help deploy, configure, and operate your various stacks
of software over time no matter where you run them, on premises or in any
of the big public clouds.
These are kind of the pair of highest level ones I start with. As @seffyroff notes, you can get more and more into the weeds after that depending on the audience.
As someone that has had to explain and pitch Juju to colleagues and other technical folks, I find that the best approach has been to compare it to other configuration management and orchestration tools which they already grok. This is helpful to quickly communicate both which problems Juju solves and which are out of scope.
I would love to see “Juju vs. Other Software” on jujucharms.com and in the docs similar to HashiCorps approach:
I would describe it as a “packaging system for systems” targeting installations spanning over many independent servers and even clouds. It allows you to “install” large systems, such as openStack, Kubernetes without the need to know exactly how they work from the beginning. Very much as any other packaging system for applications.
