What's the point?

juju
1

Hello fine people… I’ve just walked through Ghent in the snow back to my hotel cause some of us need to earn a living…

Whilst walking I was thinking to myself… Whats the point?

Not in a depressing shrug of the shoulders way, but more in a “I’ve just left the event and if I was a puppet, ansible, chef user, why would I bother looking at Juju?”

Mark gave a very interesting Keynote explaining how it’s taken a few attempts to get Juju to where it is today and internally the focus is on Openstack/K8S stuff. Which is fair enough and makes perfect sense.

So when I arrived this morning there were a few things on the stands, nothing I saw was juju related, but I didn’t look very hard, so maybe I missed something. The stand is entirely branded Ubuntu, the poloshirts are Ubuntu.

Mark then gives a talk about Juju, there is no connection there. I’m assuming that in turning up to Cfgmgmtcamp there is a general plan/hope to get people using the platform.

So if an Ansible user walks up and asks, what are the differentiators? I dunno, maybe the guys know, but why isn’t there something there for people to take away to help them realise that Juju can help them? Either by wrapping or replacing their extra code.

Similarly, as an application developer, whats in it for me, why should I use Juju to deal with the deployment? I know my answers but if you’re new to the platform they are hard to discover.

Currently there is an amazing platform, a great charm store, a great GUI to show this stuff working and some amazing stuff coming through the pipeline in terms of K8S charms etc. But currently from a messaging point of view there is a gulf in terms of messaging. Sure I know you’d all rather show off the Ubuntu logo “because everyone knows it” but surely its better to get 5 people to remember Juju than 50 people remember Ubuntu was at a Config Management Camp? Redhat had an Ansible table, branded something like Ansible by Redhat.

I remember ApacheCon in Miami, there was a great stand with Juju on it, just lack of traffic, but in reality thats probably not the right place. But since then Juju seems to have gone away to be replaced by Ubuntu, and thats pretty sad.

There’s a lot of charms in the charm store, and soon to be more in the K8S store, that without maintainers will become stale, stale charms will mean no users. Canonical can’t be on the hook to maintain all the charms, that doesn’t scale. So what can we do to get more maintainers onboard?

Other questions crossed my mind, that we’ve done with the Hadoop charms over the last few months. Has anyone bothered to ask Puppet/Ansible users what it would take to get them to test/use Juju, what do they see that puts them off?

If K8S Charms become a reality and you have an active Helm community, what would it take to get some of them to migrate to K8S charms, how can you sell K8S charms to Helm users etc?

So going back to my initial question, What’s the point? If the stand isn’t going to push the product, why bother? The time and effort would be better spent doing direct evangelism or not at all.

It feels like Juju is stuck in a place where the dev teams all run full bore, but the messaging and marketing is very confused as to what message to push, or if there’s any message at all. Maybe thats not an issue, maybe it is. Couldn’t help but mull it over on the way home.

Without a community driven from the outside in, what’s the point?

4 Likes
2

Tom, you make a lot of good points and ask a few good questions. I wanted to jump in and say I hear you and am going to get a reply out but it might take me a little bit to get it up here. As you can imagine, it’s not a simple/easy set of preprogrammed responses. Thanks

1 Like
3

Hey Rick!

It’s really not a grumble, although the title makes it seems as such. More of an open ended question.

I’m in no hurry for a reponse, no do I really expect one, just throwing some thoughts out there! :slight_smile:

4

Hah, oh I can promise you’ll get one. I always have opinions to get out there. :stuck_out_tongue:

5

this and this when used together usually get the point across well :slight_smile:

1 Like
6

Okay @jamesbeedy … you’ve been in this game longer than I have.

If you’re stood at a booth and someone walks up and says… “oh yeah? We use Ansible for all our Ops automation”

Or if you’re talking to a Helm user, what do you tell them that convinces them to test Juju K8S charms?

What is the 30 second elevator pitch you give them to convince them to give Juju a try? No screenshots. Something you can either convey in a conversation or on a printed flyer or take away.

7

  1. Instantiate firmly what Juju is and is not. Clear the air that Juju is not some contrived cfgmgmt tool. This gets Juju out of the space of being compared to the chef/puppet/ansible, the sky is the limit once you get this point across (why I start with it first).

  2. Prove point one by bringing up attributes of Juju that don’t exist in the cfgmgmt tooling that save the largest amount of ops (these should be things where every company is spending cycles where juju inherently takes the workload).
    * How cumbersome user and ssh key mgmt is with puppet, Juju alleviates the need for a company to spend cycles recreating the wheel in house here.
    * The service discovery engine inherent to Juju alleviates a company from having to build their own in house service discovery team/infrastructure.
    * Python based reactive framework for building into the ecosystem and creating your own automation stacks.
    * Multi/Cross cloud
    * Cloud native bindings
    We could keep going here.

  3. Consistency. Everybody knows what an operational mad house things can quickly become with multiple teams running workloads on across multiple different substrates with different tooling and different methods. Juju takes an easy win here.
    I wish I had a descriptor for our network infrastructure at the datacenter before the migration, it was absolute hell. Each different layer of network was provisioned on a different switch manufacture and each switch had a different OS, and different transceivers etc etc. We just finished a project where we moved all fabrics 1, 10, 40, 100 to use the same hardware, operating system, same cfgmgmt tooling, and same peripherals. This change was transcendent to the infrastructure operations needed to keep our network stack going. We can now scale out another cabinet by just putting the switch in the cab, image it, run the ansible playbook - takes about 5 minutes to init each new switch and be on with our day. The same thing happens when one introduces consistency at any level of the stack, things just get easier, operationally. Using Juju, anyone can benefit similarly from reducing their operational workload by employing higher levels of consistency throughout their technology stack.

  4. Upstream Solutions
    Sometimes it helps to just run through the upstream solutions and how Juju presents them to the global community.

  • CDK
  • Openstack
  • ELK
  • BigData
  1. Kubernetes Charms
    With the onset of 100x new kubernetes tech it’s refreshing to know that Juju has the K8s workload space covered too.

The over/under here is to get the point across that Juju is a cloud agnostic orchestration system with cloud native bindings that lets you focus on solving real engineering challenges instead of cycling development hours on recreating the wheel in house (when Juju accomplishes said thing better with primitives inherent to the system).

Typed that out fast, but hopefully it gives some insight as to how I approach the conversation.

1 Like
8

Thanks James thats a great summary.

Some of it I want to boil down, some I have some further questions…

Juju is not some contrived cfgmgmt tool. This gets Juju out of the space of being compared to the chef/puppet/ansible

Okay first up. I’ve used puppet on and off over the years so I kinda know what you’re getting at here. But the first question a Chef/Puppet user will be, how is it not a configmgt tool?

I know we’ve laboured this point over the years, so I’m dumbing the conversation down a little, but if someone is stood in front of you and says, “how is it not a cfgmgmt tool?”, whats the two sentence answer?

Point 2 I fully get. 100% true.

Point 3 is great, if we could boil that down into a nugget to take away I think it would be really useful.

Point 4 CDK, Openstack, Big data to a point I get, but it brings me back onto some of the original post.

How do you get developers and open source communities to want to commit charms, be it K8S style or traditional? From a non SysOps point of view, how do you sell it as a worthwhile cause?

I’m a developer who commits charms back, so the question is reasonably rhetorical, but from an evangelism point of view, I’m trying to figure out how to get more open source communities involved in maintaining the charms.

Regarding your last paragraph, I tried to dig out a screencap of Mark’s talk the other day where I could swear he’d moved the Juju stack from Orchestration to Modelling and stuck other stuff in Orchestration… but the stream wasn’t online when he showed it… so I can’t :slight_smile: But thats another point. Is it modelling, is it orchestration, is it both, is it neither? Does it do baremetal, does it do K8S? Does it do too much?

Cheers

Tom

9

Or if you’re talking to a Helm user, what do you tell them that convinces them to test Juju K8S charms?

This is a question I have aswell. I really like using Juju to setup my stuff but I’m having a hard time thinking of reasons why I should deploy my k8s workloads with Juju charms instead of a Helm chart. In my opinion it takes a lot more effort to setup/write the Juju k8s charms. Is the extra value of the Juju k8s charms mainly for services that are running outside of the k8s cluster?

1 Like
10

My answer: You can use your choice of cfgmgmt tooling inside or outside the context of Juju. There are bindings (charm layers and charmhelpers libs) that enable ease of use for those use cases where you need take advantage of those tools.

It’s an orchestration/modeling system!

It is difficult to summarize Juju in a single sentence, I certainly agree with you on that.

Juju can model any software, on any substrate. All the while alleviating the medial
and expensive ops! If only this made sense to people in the context of the operational things discussed above. Possibly its connecting the two things that is missing, 1) the operational overhaul it is to do run these systems, 2) how modeling using Juju alleviates the medial workloads and lets you avoid provisioning costly systems for ssh key provisioning and service discovery etc etc - by taking advantage of Juju inherent first hand primitives.

11

This is because translating a k8s deployment configuration to a k8s charm is not common knowledge, and not exactly straight forward either. Although once you put a few cycles into it you can easily see how to translate one to the other.

Perfect example. Think of all the come ups you get by relying on the primitives provided by Juju in lieu of accounting for them via in house ops.
To name just a few:

  • Storage mgmt
  • Access control
  • Interoperability with the rest of the juju stack (I can manage my k8s workloads right alongside the rest, in a consistent fashion)
  • There are many more here!

See https://discourse.jujucharms.com/t/juju-kubernets-orchestration-reasoning/340/3 for more detail.

12

Yeah, possibly I’m a bit behind there. I should get with it before I start yipping and yapping :slight_smile: Glad to hear you made it back to Ghent this year!

13

First, thanks for bringing this up. I really love that we’ve got an open community going where folks can feel free to ask hard questions and even just talk about what they’re seeing. :+1:

Yes! This is something that we’re in the middle of an identity crisis on. We put Juju out early and franky it wasn’t ready, back in the 1.x days. Juju 2.0 really was where it started to come into its own. The issue we faced is that Juju solves a higher level problem than a config mgt tool. You don’t know you have this problem until things get big and complicated enough, and so the folks that understand and find value in Juju don’t really get that pay back until things are so big. You have to need to operate the same bits of software multiple times to really understand the value of Juju. Maybe it’s many times in different clouds, for different customers, or different parts of your org. It’s why we’ve been really successful in some areas (OpenStack, K8s deploys) but really not been able to tell a good story to the smaller developer folks. I currently tell folks that until things are big/complicated enough Juju really isn’t worth the investment. However, I’ll note below I expect to see that changing a bit.

You’re starting to get into next steps for us. Juju + K8s is a real opportunity to us. K8s charms aren’t as complicated. They can provide real value in modeling what seem like very disconnected applications running across a cluster. We can bridge from the cluster to large things outside the cluster. What it does though, is give us a low impact win back at the smaller team/developer. It makes sense to look at Juju + microk8s as a great iterating developer experience. Taking that to Juju + CDK in production means a smooth transition.

Agree, we’ve taken a few stabs at this over history. From hiring a team, to trying to work with upstreams to get them to buy into charms as the easy way to test and get their software, to working with consulting/”experts” to get a return on charming investment and grow the charming ecosystem. Some folks see the value much better than others.

K8s charms are the next step and there will be good and bad things here. The good is that it’s a wider pool and it’s not as intensive to write those charms. Personally, i think the bad will be that folks are solving their own problems and that reusability will be low. It’ll mean more charms, but not as much value for others across the ecosystem. Still, more folks knowing and investing is charming is a big win for Juju.

I admit that I’ve not asked recently. When I was going around more talking to folks the big thing I found was that folks that were using Puppet/Ansible didn’t “get Juju”. To them, they had a bank of hardware they cared about, that they were invested in. They were using these tools to help lock down systems, ensure consistency. They didn’t feel they had a problem with operations at the scale of Juju. They’d basically all had some internal system they’d scraped together and each team did things a little different based on their leadership/technical experts. When you try to get them on board with Juju they weren’t really thinking across different teams and having shared knowledge/expertise there. Juju really is a great sell to the CTO, but struggles with the tech lead in a small team. They’ve “solved” their problems and come to conferences like cfgmgmt camp to get better at their tool from what I see.

Maybe Juju k8s can make a dent here that it wasn’t successful at before. Maybe these days the conversations would go smoother. You’re totally right to call out that we’re not doing enough banging on these doors. Honestly, we just moved on to the solutions based approach. “Oh, you want a kubernetes cluster? I can get you one of those in a hurry. Don’t worry about how for now, let’s just get your solution running asap”. Folks that don’t care how they get something done and we know doing it repeatedly with Juju is the best way to do it.

Ding, ding, ding! This question hits a great spot. As you know, we’re actively working on k8s charming and working to get it from the labs to a primary feature of Juju. Towards this end Canonical is doing something great. We’re chatting with folks in the k8s community and getting them to provide early and thorough feedback on Juju as a solution to k8s problems. None of us like dealing with the gobs and gobs of YAML it takes to actually get something useful going in k8s. Juju we really think can help here. We’re hopeful that by getting early feedback from folks deep in the k8s world when we get this feature set right, we can make the big push and get folks to look at Juju for a much wider array of problems.
So going back to my initial question, What’s the point? If the stand isn’t going to push the product, why bother? The time and effort would be better spent doing direct evangelism or not at all.

My reply here is that a new round is building. The dev team is going full bore. The marketing/messaging is preparing for the next wave. We’ve taken a few different stabs at getting Juju out there and we’re all in setting up the next one. The big thing is that we’re just starting to build the next wave. We don’t have the message out there yet. We’re eager for folks to find Juju and solve problems with it. We’re eager for teams to see the value that we see, and honestly, we’ve seen some nice activity here in this discourse and in IRC. We’re confident Juju has value and others can reap the benefits as well.

Right now we’re really focused on two fronts. Adding in some of the big advanced features that let folks leverage Juju for the long haul (series upgrades, model generations, massive performance improvements at scale) doing things other tools just can’t even touch, and making sure we land the next wave of Juju users. We’re looking to hook those folks developing and deploys k8s charms with the suite of tools they need.

In the end, I think the point is that we’re building a great tool and love it when folks see the value in it. However, it’s a specialist tool at the moment. It’s got a solid niche. I really think that the k8s area of Juju can help make that a much larger niche that has much broader appeal and growing the breadth of folks interested in Juju is the point right now.

1 Like
14

Thanks folks. I will respond to the comments in a bit. I would also like to point out something I just mentioned to a couple of the developers.

This isn’t a slight at anyone on the canonical side… well outside of getting some positioning stuff sorted. I’m asking these questions more in the mindset of “what can I do better to help sell the platform to other developers?” But I need input from Canonical and other community members to help make that pitch easier…

Just to clear up any ambiguity there.

2 Likes
15

Yea, I mean we’ve learned a ton of lessons over the year and always happy to help. The work you folks in the community do to speak up so it’s not just “Canonical says…” is wonderful and really appreciated.

16

Great thread, fantastic read! I have been pondering precisely all of this, thanks for bringing it up, @magicaltrout.

2 Likes
17

So I was trying to figure out, after I said I’d respond to this, whether there was anything to respond to…

There isn’t much, Rick made some great points as did James and co. So here’s my parting shot, because another thread is about to kick off… When marketing get their stuff together, and the devs are happy. Make sure you reach out to what community there is, engage us and use us and make sure we communicate the tools backstory/use cases and roadmap in a manner that allows us to help you guys bring more users/software.

I see us as unoffical developer advocates, so use us as such and make sure we get the message out there to our respective communities.

3 Likes