Juju: Re-Framing the Discussion

by Randall Ross on 4 August 2015

A while back, just before Dockercon 2015, the friendly folks behind Ubuntu, Juju, LXD, and a whole bunch of other goodness hosted a special event that was all about service modelling, orchestration, and making all the container-y Docker-y stuff work well with in the DevOps world.

We assembled a panel of industry luminaries, including our very own Ben Saller. For those of you who don’t know Ben, he’s one of the original creators of Juju and an all-around great guy.

At one point in the panel discussion, the moderator asked (I’m paraphrasing) whether the Twitter’s and Google’s of the world are a “special breed” with respect to the scale of containerization or whether that’s become a more common design pattern for the “rest of us”, i.e. the smaller companies… Though indirect, the question implied that the rest of the world was now ready for scale and the solutions that provide it.

Here’s what Ben had to say in response:

I don’t think it’s the scale that you’re operating at, it’s the properties that you demand of the infrastructure.

Everybody wants the self healing. Everybody wants the dynamic recovery, the load balancing.

The problem becomes an economic function for many people, whether or not they can run eight machines to have some kind of bespoke Platform-as-a-Service (PaaS) to do the one piece of software they have. It’s not worth it in some sense unless that piece of software is mission-critical to carry a lot of infrastructure. And, it’s very difficult to specialize a team to gain the knowledge to do that for a small organization.

So, when we talk about things like Kubernetes or the kinds of software that we have with Juju and the other things what we’re really trying to do is exactly what you were talking about: Make those best practices available by capturing the automation stylings of the larger players and presenting them in a cost-effective way.

And I think that everyone is interested in that. Absolutely.

Sometimes, the problem being solved isn’t well formed. It has been framed in a manner that makes us blind to the path forward. (I think much of the tech industry does this on purpose, but that’s the topic of a whole other article.) This concept resonates with me as someone who studied engineering. In my university days, engineering professors were particularly clever at creating assignment problems that were solvable only if framed correctly. Approach a problem the wrong way, and you’d be up all night dating an intractable problem with no solution in sight.

Ben obviously gets this. Watch the video and see for yourself. He’s the guy with the beard 😉

So, before you jump on a tool to solve a problem, frame your problem carefully and with precision, then pick a tool to help you.

Yes, that tool could be Juju.