What's the difference between Juju and Puppet/Chef?

Question

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?

Solution 1

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:

• https://web.archive.org/web/20140404014848/https://community.csc.com/community/cio-engage/blog/2013/08/25/beyond-chef-and-puppet-ubuntu-juju
• How does Juju "co-exist" with Chef, taking the automation process "one step further"?

Solution 2

(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.

Solution 3

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.

Solution 4

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.

View more solutions

Comments

[SpamapS]

Not sure if punting is the right word here.. thats like saying packages punt building the software to autotools/scons/setup.py. If packages tried to do every step of every build, we'd have no packages!

[poolie]

Puppet deals with describing resources, provisioning VMs, and sharing modules too. Can you explain how Juju does it differently or better, or solves a different problem?

[SpamapS]

Was not aware of puppet cloud provisioner at the time of that answer. Puppet modules were not name spaced the last time I checked, and thus present sharing problems that may require a user to modify the code of a puppet module to make use of it.

[poolie]

There are namespaces in puppet. I haven't used Puppet much, but my understanding is that problems mostly occur when two modules are actually trying to manage the same logical thing. Does Juju have some systematic way to prevent that?

[SpamapS]

The namespaces in puppet have undergone recent changes to make it easier to share a working stand-alone puppet module. In the past one needed the equivalent of global variables to communicate between two modules. Juju doesn't deal in any way shape or form with configuration of the instance, it is just a facilitator for orchestration, so no, it will not prevent two charms battling over a single file.

[Denis Weerasiri]

Hi @SpamapS , This is regarding your second point (aka Juju orchestrates provisioning). In puppet we can define relationships using "require", "notify" etc. Can't we simply use this constructs to orchestration provisioning? Or Juju provides a different level of orchestration semantics?

[SpamapS]

Denis, those are constructs within a single machine. Juju orchestrates things across multiple machines.