On Fri, Mar 27, 2015 at 8:58 AM, Mark Shuttleworth <m...@ubuntu.com> wrote: > In my travels now I am glad to say I see a shift in the way people > engage with us about Juju. It used to be "why would you want to compete > with Puppet?" but now folks understand that we do not want to compete > with Puppet, we want to come up a level and enable people to collaborate > and reuse their puppet / chef / bash / python across different clouds > and environments. > > That focus on collaboration and reuse is what makes Juju special. In the > long run we will integrate Juju into places like HEAT so you get the > benefit of charms, together with the underlying cloud information about > performance, so that things like autoscaling are magical, but in the > short term it's easy to think the projects compete. But folks are > starting to understand that now, so I don't get asked "why do you not > just do HEAT?". > > I also think that it will emerge that there are many levels of > orchestration; Juju will be the BEST for the lowest level of > infrastructure orchestration, but people will use Juju to deploy things > like PAAS which themselves offer a kind of orchestration. So end-users > might use a PAAS, which is like a model or API or orchestration system, > and underneath that, administrators will use Juju for the base level. We > won't try to push Juju into every layer; just like we have kept MAAS and > Juju separate with different interests and different responsibilities, > so now the Chef guys are happy to use MAAS, which is good for us both.
Yay to all of this! I'm presenting a poster on juju at PyCon in a couple weeks and this is exactly the focus of it. > Now, of course, those companies also do a lot of OTHER things :) so I > can't say they will all move solely to Juju because they naturally will > not. But smart folks are seeing what you see - the model is amazing. And > if we are able to get the next round of model pieces in place - status, > network, disk - then we'll be able to do some really incredible rapid > deployment and service evolution things. :) > > My biggest concern at the moment is that I think it's too hard to add > interfaces to existing charms. I think about adding say a Nagios > interface to an existing charm - that should be really easy, but I think > we haven't optimised the whole charm development process very well, so I > will host the lead charmers at my house next week for a mini sprint so > they can show me what I'm missing and we can discuss how to make it much > better. I'm so glad you are doing this! In some ways making charm authoring easier/better is the lowest-hanging fruit for accelerating juju adoption. So this sort of effort has a big impact. > > Also, I think we need to really socialise the status work, because it's > too easy for charms to fail mysteriously, and that makes Juju look bad. > So automated testing of charms is going to get even more important. +1 -eric -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
