Juju: Re-Framing the Discussion

Tags: Cloud Native , Juju

This article was last updated 5 years ago.


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.

Ubuntu cloud

Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.

Newsletter signup

Get the latest Ubuntu news and updates in your inbox.

By submitting this form, I confirm that I have read and agree to Canonical's Privacy Policy.

Related posts

Application migration: best practices for success

Large enterprises usually have more than 1,000 systems running. Even smaller organisations may have hundreds of applications in their public cloud spaces or...

Participate in the Kubernetes and Cloud Native Operations Survey 2023

Canonical has conducted surveys about Kubernetes and Cloud Native Operations in the past two years. As a member of the Cloud Native Computing Foundation...

Join us at Operator Day, hosted by Canonical at Kubecon NA 2022

The 5th Operator Day is coming up. It will take place at KubeCon North America 2022. This edition will center on cases where software operators have been...