Have tried asking 3rd party about key differences between Juju and Puppet/Chef. 3rd parties are not too familiar with Juju and could not say. They simply stated the others have a lot of momentum, and it would be hard to overcome their lead.
Would those closest to Juju be willing to highlight the advantages of this software, and why it will overtake Puppet/Chef in the config management arena?
Mark, this is a great question, and was the first one I asked when somebody told me about Juju. Here's some of the big differences.
Juju encapsulates services - a charm defines all the ways the service needs to expose or consume config data to/from other services. How a charm does that is the charm's business. It can use any tool from shell scripts to Chef in solo mode, to do that.
Juju orchestrates provisioning - juju keeps track of the resources it has available to it, and can add or remove them as needed. Currently these resources are AWS EC2 machines, OpenStack clouds (like HP Cloud), Microsoft Azure, Joyent, bare metal machines via MAAS, and an LXC/KVM local provider.
Juju makes sharing easy - anyone can contribute a charm to the Juju Charm Store; these charms are vetted and peer reviewed by the Juju community.
Here are some other comparisons people have made from across the web:
(Disclaimer - I'm the founder of Puppet and CEO of Puppet Labs)
I don't know juju terribly well, but from what I can tell, they somewhat sit at different layers. Puppet is great at managing the behaviors and capabilities of machines themselves, whereas juju seems primarily dedicated to talking about sets of machines and largely punts how to make the machines behave any specific way to external tools like Puppet or shell scripts.
Our strategy with Puppet is to build the best stack from the ground up, whereas juju appears to be a specific layer of the stack and leaving other layers to other tools. Thus, while you can solve the whole problem with Puppet (albeit sometimes with a bit more work than you might like), you'll need to integrate juju with other tools to get much done.
Really, juju seems like an on-premise version of CloudFormation from Amazon, albeit without the graph and such. So, usable with Puppet etc., but not a replacement for it.
Here's another take on how Juju fits with other automation tools:
I am responsible for Cloud Strategy at Canonical, the company behind Ubuntu and Juju. Juju is not a competitor of Puppet or Chef. Juju can install Puppet or Chef and from within a Charm, Juju's encapsulation of a service, you can call your existing Puppet modules or Chef receipts.
So what is Juju? Juju allows you to instantly deploy, integrate and scale your IT stack/services/applications. Instant IT gains without the pains. Either via command line or the GUI.
So Juju is closer to PaaS then to Devops tool since you can build your cloud (Juju is Canonical's default OpenStack installer), the infrastructure that goes on top of it (web/app/db servers, Hadoop, MongoDB, etc.) but most remarkingly Juju allows applications to be deployed and immediately integrated (add-relation between Wordpress and MySQL will automatically setup Wordpress tables and data inside MySQL).
Also app servers (java, php, node.js, scala, etc.) can work together with version control hence automatic deployment and scaling of your apps is possible. So unlike PaaS, you are not limited to a specific software stack but still get the instant deployment, integration and scaling advantages. Think of it as a flexible PaaS or FlexiPaaS that instantly deploys, integrates and scales your software services without being limited or being locked-in.
Source - Warning: login required.
In the simplest terms, juju encapsulates service discovery, a key value store, and configuration management. Puppet/chef etc are pure config management.
Juju is event based and uses a central "bootstrap node" to keep track of and orchestrate events. Puppet and chef can be made to appear event based, however it's typically just running the relevant job on a schedule.
Afaik, you can't run juju in a distributed or agentless state and this is possible with most configuration management systems.
For the most part puppet etc are domain specific languages, whereas juju is a system, not a language.
