Voices in DevOps – Episode 18: A Conversation with Tracy Miranda of Cloudbees

Guest

Tracy is the Director of Open Source Community at CloudBees, long time open source contributor and evangelist.

Transcript

Jon Collins: Hello, and welcome to this episode of Voices in DevOps where I'm delighted to be speaking to Tracy Miranda, who's possibly got one of the biggest business cards or you’d need to write it all very small. Tracy is Director of Open Source, the community at CloudBees, and is also on the governing board of the Continuous Delivery Foundation, which is quite a mouthful to tell people at parties, Tracy. How did you get all these titles? What's your career trajectory? Where have you been and how did you get to where you are?

Tracy Miranda: Thanks for having me on, Jon. The ‘open source’ part has probably been the theme throughout my career. I'm pretty much a veteran of a whole bunch of open source communities.

If we pick up open source first, how did that all happen? How did open source become such a big part of your working life?

Yeah, so my background [is] I actually started off in hardware, funnily enough. What happened is working at a company and as you do, they canceled the project I was working on and out of the blue, were just like, "Okay, you need to learn Java and use this platform," which was the Eclipse Open Source project.

Then I was fortunate enough to go to an open source conference of all places at Disney World, strangely enough. Having gone to that conference, I found the community really welcoming, really helpful. This whole idea that the code could and should be open and people could share that and that would lead to a massive community and loads of innovation, it was just really compelling. I was hooked from that. I think that was back well over 10 years ago, so I've stuck with open source.

As a matter of interest, going from hardware to software is an interesting transition anyway. Some might say that hardware people don't get software very well. I'm not saying I would say that, being someone that's worked with both as well. Then going from software in general to open source in particular, do you think it was the community aspect that just drew you more and more into the software-based direction as well as the open source direction?

Yes, for sure. The community, just the pace at which things are evolving as well, you could see just how exciting it was and the new things coming along. I find that really compelling and I think personally as well, I love being at the intersection of different things. It sometimes works really well, but having one foot in different camps.

Did open source beget the Continuous Delivery Foundation or is that a separate initiative?

Yes. How that came about – when it comes to CI/CD and DevOps, I'm actually fairly new, relatively speaking. It's only been about 18 months since I joined CloudBees. That came about because I got to talking to Kohsuke Kawaguchi, who's creator of Jenkins. He was looking to do some pretty exciting things with open source and with Jenkins around this foundation. It sounded really interesting and right in an area I could help drive, so I came on board to CloudBees to do that and doing so went from just a developer who's used Jenkins to really getting ‘stuck in’ with the open source community, warts and all.

I think also coming in with that fresh perspective, you get to a point where you realize the whole CI/CD landscape is just crazy. I don't know how we expect newcomers into the field to figure out which tools to use and how to put things together. I think coming in with the open source with those fresh eyes and seeing that problem, it was glaringly obvious to me.

Is this a good point to talk about imposter syndrome or shall we hold that one off until later? Particularly [laughter] you're getting involved in the source community. I can remember back in the early '90s when I started hanging out with some of the people from the Minix user group that were driving use of very early Linux back then. I felt such a fraud, and I've never lost that particular aspect. I've come to terms with my imposter syndrome. I'm very comfortable with it.

More interesting to me is maybe the perspectives that you must have from that observational standpoint, having worked in code and then with a very broad community. Then as you say, the continuous world, I don't know quite how to phrase that, isn’t – it's not one unit, is it? It's more an ecosystem. It's massively complex.

We can segue into what's causing challenges in organizations, or we can just talk about that for a bit. This complexity, is it in your mind -- I'm trying not to say a good thing [or] a bad thing, but how would you characterize it? Is it the nature of the beast? It was always going to be like that, or has it got into a place where it should not be, or is it in a good place?

Okay, you mean the complexity of the tooling or how to get solutions around?

Yeah, without asking a leading question. The leading bit of it is, I think fragmentation is a bad thing.

Yes.

Your take on seeing it in terms of maybe there are some good things about it.

Yeah, I mean, with tools and yet since every industry tends to be a pendulum, there's consolidation around specific platforms. Then as new needs arise, people tend to bring up new things. In terms of the current state, I think it's way, way too far on the fragmentation side and there's a lot of uncertainty. People don't understand what does what. There's a lot of fud [fear, uncertainty & doubt] as well around tools. I think part of this is just the sheer nature of the tech landscape at the moment with the arrival of cloud native.

As a new tech paradigm, people are trying to figure out ‘what does that mean? How do we run distributed systems?’ The environments are so different; how do we deliver for that? You've got this proliferation of environments which leads to proliferation of tools, which just makes life difficult for everybody.

Your open source background [is] you started in the Eclipse world. If I mischaracterize that, essentially a lot of that world came out of people extending the development of things they already understood. If you take Unix to Linux, if you take C++ to Java, the Eclipse framework was originally a tool set that was then open sourced and even things like OpenOffice. A lot of things then were taking something you understand, and then getting the community to extend it whereas now we've got a very different thing, which is: the community creates what it likes, which is fantastically innovative, or am I completely wrong?

While they're still at the heart of – you take the Continuous Delivery Foundation. We still have projects there. You take something like Jenkins which is by far the most adopted CI/CD tool and that follows the traditional model in terms of people write plug-ins and they figure out ways to extend it.

I think in general, open source, if I look back at where I started off with Eclipse and where we are today with open source, and the Continuous Delivery Foundation, it's such a different landscape. For one thing, open source is most definitely a C-suite concern for almost every company. You've got these big enterprise banks and they are having discussions about: what does it mean to use open source? What does it mean to extend it? What does it mean to be part of a foundation? You take something like the Continuous Delivery Foundation and we have HSBC as founding members. We have Capital One, JP Morgan, and this just points to this whole ‘software and open source software has eaten the world.’

Just while we’re on that subject, the Continuous Delivery Foundation – I haven’t set up this question. I genuinely don’t know what it does. Maybe give us a ten-second quick overview of the remit of the Continuous Delivery Foundation.

The Continuous Delivery Foundation is a vendor neutral home for some of the fastest growing projects in the continuous delivery space. We also see it as a place for collaboration to drive what we’re going to see as the next generation of tools and communities.

Okay, so it’s the basis for the next stage of platform of the tools that you need to deliver continuous delivery.

If you look at the founding – we’ve got four founding projects, which sort of give you an indication of how that’s going to evolve. You’ve got Jenkins, the largest use –

That one.

Yeah, that one. You’ve heard of Jenkins, John. Then you’ve got Spinnaker. That came out of Netflix as the gold standard for delivery. Those are the ones which are in use a lot today. Then you’ve got the new breed of the cloud native CI/CD platform, Tekton, which came out of Google’s Knative serverless platform, so that’s a built-in pipeline side. Jenkins X, which is completely cloud native, focused on developer experience around delivering software.

That’s also Knative related, isn’t it?

Yes. Jenkins X will use things like the Tekton building blocks and is just focused on how would you completely build on Kubernetes to deliver your software.

I think that’s a perfect set up for the next question then because you’re looking at both the past and you’re looking at the future and you’re talking to very big organizations and you’ve got that community background. You’re linking all the different bits. What’s the problem we’re trying to solve here in your mind? What’s not working as it needs to be addressed? What’s the opportunity that is so exciting to you that can be harnessed in some way using these new ways of doing things?

First of all, you summed it up really nicely there. I think the problem we see in the Continuous Delivery Foundation, the book on continuous delivery by Jez Humble and Gene Kim that was written around ten years ago and mapped out things really well, but if you look at any survey or anything that talks about rates of adoption, it’s pretty low. Some people will have some of their toolchain fully set up, but practically nobody has all their software automated with this ability to deliver quickly and robustly. We sort of ask ourselves, ‘Why is that? We know what to do. Why haven’t we done it?’

I see there’s three reasons. The fragmentation of just this massive proliferation of tools is one. The second is the fact that things are changing so much with the rise of cloud native. That means things have to adapt and change. The third reason is just simply that change is really hard, and it’s not just a case of adopting new tools. You have to change culture and mindset. That is the real challenging part of it.

I could add four and five, but it’s not my podcast, it’s yours.

Now I’m really curious. What’s four and five?

Two fascinating things, I think CloudBees is relevant in this discussion. This isn’t about CloudBees, this is about your experience. You know the company quite well now, one example of an organization that is looking to move beyond what it did traditionally. The vendor landscape is changing. It’s becoming less fragmented. I think we’re just seeing the beginnings of that.

What CloudBees talks about with software delivery management, I think that’s a symptom of the rapture, if you like, that’s a stake in the ground of how things are going to start to look. That’s one thing. I’ve got another one. Do you want to hear the other one?

Just a quick comment on that; CloudBees is a leader in the DevOps space and has already contributed to some of that consolidation by acquiring companies like Rollout and Electric Cloud, if you like. I think definitely we see this is an ‘ecosystem’ thing. Everybody has to work together. It will be sort of bringing all these tools together. It’s not just for one company necessarily to have this uber-tool. I think we see that really well, and we see it’s all about working together and driving towards that interoperability.

I’m struggling to predict what things are going to look like. Us analysts are supposed to be great at making predictions. What does ‘rightness’ look like? What does ‘just enough’ look like in terms of whether you need a comprehensive platform with bits added or whether you need a much thinner, lighter weight platform with bigger chunks? That’s quite difficult to predict.

I think it feels like we’re in this CI/CD renaissance where nobody knows what the answer is going to be. If people come together and we can figure it out, then we have the platform or the basis – maybe platform isn’t a good word, but the basis for driving forward software delivery. We have a couple of ideas emerging.

From some of the early conversations we’ve had in CDF, it’s simple things that we start saying there’s some low-hanging fruit around why don’t we have a canonical metadata around specific things like release information. What if Spinnaker or Jenkins X and other tools just subscribe to the same canonical metadata so you could output, release information, and other tools could consume it? There’s all sorts of things besides release data that’s test data, just having canonical metadata is like a first good step.

I think that’s a fantastic proposal. I can’t wait. The other thing I’d like – I don’t want to go full waterfall on this thing. Just to agree that there’s a notion, for example, of a requirements phase. We all call it a requirements phase as opposed an innovation phase or an ideation phase or this phase or that phase.

It’s just like you’re there. You can then change jobs from one company to another and say that you do that, without having to work out what language they’re using. I agree with you on the kind of metadata level. Equally I think we could agree on the terminology thing at the same time.

I think it would be great to have some consensus around some of the terms there as well. This probably is quite challenging for certain things just based on a few conversations. Everybody agrees that it would be nice to have that sort of common lexicon.

Wouldn’t it be nice to have a common lexicon? What a great word, lexicon. Wouldn’t that be the word of the day? I’m going to tweet ‘lexicon’ later. Just for the record, my second point was that it’s not just about what we’re currently calling DevOps. That actually has touch points with business change and so on and so forth.

I’ve been playing with various terms for my own use, things like continuous culture. You mentioned the cultural aspect. If, for example, you want to build a bot for your customer service, sometimes that’s going to be absolutely the right thing to do. Sometimes it’s going to absolutely be the wrong thing to do, and you should have a person. Those are business decisions that are still innovation decisions, but they’re business decisions in terms of how best to interact and which bits of things should be automated versus which bits – that’s where I’d like to see things extend to when we’re talking about continuous innovation or just this broader notion of transformational change that we’re seeing all organizations go through. There you go. That’s my fifth.

At CloudBees we sort of just refer to it now as just ‘continuous everything.’ That’s what it feels like.

I like that, simple and effective. If an enterprise-type person is listening to this podcast, what they’d be hearing is we’ve kind of created a bit of a rod for our own backs. They recognize that their organizations, maybe there’s pockets of best practice, but it’s really hard to scale that best practice across the organization and to reference all these other touch points. They’d also reference that the DevOps world is in a state of evolution, just by nature of what you’re saying in the Continuous Deliverance Foundation.

It’s a kind of a chicken and egg question. There could be things they could be doing now to help make their lives better and just start to be able to scale concepts and so on. Also, there’d be things they could start to think about to prepare themselves for a more mature ecosystem that they can engage with.

What you’re saying about the CDF suggests that the ecosystems vary in maturity. It’s a two-part question. One is what can people be thinking about now, and what can they be thinking about in order to prepare themselves for where things are going?

For what they should do now, when we go and talk to people, they’re heads down, focused on their own space. What I always recommend is they come up for air. They get out and go to conferences and join places where people are having these conversations.

Many times we see people who have ruled their own tooling or come up with some process that just talking to other people in the same boat is incredibly powerful, sharing ideas, sharing what’s worked and what hasn’t, and just getting context as well. The solutions are always going to be unique to your organization and your problem space. Hearing what other people have tried in the right context often is very helpful.

That does link back to the imposter syndrome, funnily enough, which is: don’t be afraid to start learning what other people are doing, and even saying what you’re doing in such a way that you can find out and even participate in the evolution of best practices.

It’s like with anything. If you want to be a better writer, you just write. Then you get the feedback and improve. You’ve got to start by just doing it. It’s the same thing with continuous delivery. Just start somewhere, start delivering, start trying to get things in order, and then figure out what the biggest constraint [is].

How do I fix that and iterate back to this idea of continuous improvement? Just do it. Talk to people. Get some feedback and keep going. Just don’t give up.

A lot of the conversations we have seem to be seeing developers as the key stakeholders in this. Would you aim that advice at a broader pool of people? What kinds of roles should be or could be building on their experience?

I’m guilty of this as well. We all fall into the trap of focus[ing] on developers. We’re trying to figure out a way for the Continuous Delivery Foundation to open itself up to all sorts of practitioners and groups who aren’t first-class citizens, who are the testers in the room and the QA. I’d love to see more to elevate those conversations and bring them in and have everybody sharing their perspective because I think that’s what it takes to get to the right solutions.

There’s a behavioral question there, which is: you assume if they’re not in the room that they don’t matter.

We sort of need everybody at the table, which is challenging, which is one of the things we have to try and figure out.

Shouldn’t Slack solve that one? You need collaboration. You mean we need Slack. Just get a Slack channel. That will make everything better.

It’s funny you should say that because CDF has just set up on a Slack channel, so you can start there. That’s one entry point.

At the end of this when I say thank you very much and we all say goodbye, remind me to ask you for some links to these things. We can list out a few salient points that people can reference for this stuff. That’s good. Large organizations, same advice? Just do it? Just start delivering, but then just start learning and sharing. Do we need a chief continuous delivery officer?

I think so, certainly an open source [person]. I’ve always seen the power of individual champions in the industry. If the champion is at the exact level, then that’s great. People should never underestimate the ability of an individual in a company to make a change.

One of the topics that I’ve spoken a lot about in the past year is this whole concept around getops. We’ve often heard people coming up and asking how can I be a getops champion in my organization? How can I encourage everybody to just sort of do these best practices? I think individuals can go pretty far as long as they’re supported, and if you’re talking to other people doing the same thing in other industries. It can be really helpful. That’s a word of inspiration for the individuals in the enterprise. Enterprises in general need to see the fact that software delivering features is a massive differentiator and assign the same value to it accordingly.

I’ve got to ask a dumb question here. Does one self-championize? Can champions be created? Should directors be identifying and creating champions or can you become a champion from within?

Yes, I think in every company, there are people who could be or would be champions. I think the role at the higher level is for the executives to identify these people and empower them, sort of get things out of their way and give them the ability to drive for that change. That can be pretty powerful for people themselves.

I’ve gone through that transformation myself from just being somebody who wants to use open source to actually advocating with big companies about what they should be doing and how they should be adopting open source. You can, to use your word, championize yourself. I’m sure there’s a continuous championization somewhere.

I think the grammar police may be knocking at the door very quickly.

If we just say it often enough, it becomes a new word.[laughter]

It becomes a thing, absolutely. On that note, ending with the principle of champions, I think the empowerment – I was looking at what you were saying about the continuous delivery and what’s become the DORA State of DevOps reports and the importance of giving people an environment where they can thrive. I think that links very strongly into that.

Last thoughts then: if you were to wave a magic wand – what’s the problem we’re actually trying to solve here? We want even the biggest organizations to be able to be as productive and deliver on their potential through the power of software, through the power of technology and get rid of the things that are in the way. If you could make that happen, what would you do to help everyone forward from here?

I would start a foundation that is neutral. I think there’s something to be said for a safe space where people can come and gather, not feeling any pressure from a specific vendor or from a specific agenda, just creating these spaces both on the tool side and on the practice side as well. I think sticking with that theme, I would encourage people to get involved with the community. We have this saying, ‘community is the capacity.’ We can do as much as people are willing to step forward and do.

I think we’re going to see a lot more on what I spoke of earlier, the drive for interoperability. Part of that conversation I’d love to have is what we call the end user companies to give that voice to it and different perspectives of that, how we’re using the software. What makes a difference? How should we evolve these tools? Get involved with CDF is my big call to action.

Thank you. If it is about starting to do things, start getting involved. On that note, is it as simple as Googling for the Continuous Delivery Foundation and the Slack channel, and everything else will just appear?

I wish. I think we’re still bootstrapping and trying to make the channels pretty clear. If you go onto CD Foundation we’ve got a mailing list. We’ve got a link up to the Slack channel. We also have an event coming up co-located with KubeCon San Diego, which is in November. That will be a big gathering of a lot of the community members. If people can join us there at that, I think it’s November 18th in San Diego. That’s an amazing place to just feel the energy and feel the direction of where things are headed and contribute and be part of that.

You’ll be there, obviously.

I’ll be there for sure.

People out there if you’re there, look up Tracy and look up the Continuous Delivery Foundation. As someone that has a personal fear about the fragmentation, it’s like Sorcerer’s Apprentice to me. We’ve just created so many brooms and we don’t know what to do with them all.

That’s a great analogy.

Brooms are great. As someone who has that very strongly in my working mind, I’d love to see you do something about it. My fingers are crossed. Good luck for the future with that. I really look forward to seeing where it goes.

Thanks very much. I’ll see you back in a year. I’m sure it will be amazing.

Let’s do this again. We’ll see how we got on.

Thank you so much.