The DevOps Toolchain per Anders Wallgren, Electric Cloud

Thanks to Anders Wallgren , CTO and Sam Fell , V.P. of Marketing at Electric Cloud for hosting, and moderating, our roundtable discussion on the necessary elements of a healthy DevOps toolchain with, Ian Buchanan, Principal Solutions Engineer for DevOps at Atlassian , Lee Atchison, Senior Director for Cloud at New Relic , Ravi Gadhia, Solutions Engineer at GitHub , Mark Miller, Senior Storyteller and DevOps Evangelist at Sonatype , Prashant Mohan, Product Manager at SmartBear , and yours truly.

You can see the full podcast here .

Following are Ander’s thoughts on the four topics we covered:

A healthy toolchain can adapt to accommodate both changes in team preference, application architecture, quality processes. All kinds of other technology shifts are happening every other day for most of the people we work with. So, learn how a healthy toolchain helps teams gain improved visibility and control, as well as substantial improvements in collaboration and release cadence.

The DevOps Toolchain as a Value Stream

Every time I sit down and talk with a customer we begin by talking about the value stream. We did a webinar with Nicole Forsgren last year. And she had this great, subtle insight which was, you know, we should spend more time thinking about what happens to our code and less about what we do to our code.

And really, the way I think about that is, you know, you want to put a little GoPro camera on your code’s head and then follow it all the way through until it ends up in the customer's hands and generates value. That is the value stream, right? Maybe not the only one, but that is absolutely something you'd want to do.

Think about it from the code's perspective. Is the code sitting there in the dark, lonely, all by itself waiting for you to, help it, fix it, make it better, or are you just, sort of, always touching it and adding value to it? I think that's where these sort of 80% wait time, 20% value time, you kind of things come from is when we think less about what happens to our code and more about what we do to our code. It's most of the time it's just sitting there and that's just value waiting to be captured.

Using Tools to Align People and Teams

You always have to worry about your biggest constraints, of the day, of the hour, of the month, of the year. If you're not worrying about your biggest constraint, chances are you might be doing local optimizations that are not really going to move the ball very much.

I think one of the key things about breaking down these silos and getting visibility into what becomes before whatever I do and what comes after or whatever I do is key because we start to get an understanding of what the big picture is and think less about what our little silo is about.

It's something that's easy to forget in our day-to-day existence. I can get very focused on what I got to make this one test run faster or I got to make this build faster or it always need to happen in 15 minutes not 15 hours and all of those things. That may or may not be the biggest problem that's preventing you from success by whatever outcome you're looking for.

Depending on the outcome you're looking for, that may drastically change what becomes your biggest constraint. So it's always critical to understand we're outcome-based, what's the outcome you're looking for, how do we measure that, what's our biggest constraint to improving that outcome? And then swarm that and throw resources at that problem, and let some of the other ones linger for a while because they're not holding you back.

And that just is so insidious. It's so easy to get sucked into local optimization because it feels so good to make something that you own better, and faster, and more reliable, and all of those things. But you really have to pull back a little bit and think about is this the number one problem and that's tough if I want to make my slice better.

I'll throw one thing in there which is just on value-stream mapping. If I had to ask the world one thing before we start to try to optimize all of these things is, "Please, try to understand your value chain. Please spend time on that. Get the right people in the room, all of them, from the tail of the snake to the mouth, get them all in the room. Understand this because once you understand the whole thing, a lot of the answers become so much clearer. You struggle a little bit less with that."

Is There One Right Tool?

You know, I like the fact that we're talking about this as a tradeoff because it isn't necessarily the right answer on day-one of your DevOps journey to throw out everything you do today. That might be right for a 10- person organization, a 50-person organization. It's almost certainly not right for a 5,000-person organization.

We hear this viscerally from customers, especially our larger ones, "Yeah, we would love to do that but then we'd have to train 5,000 people," That's not an insignificant investment in time, resources, materials, all of those kinds of things. For a lot of us, the reality of the world is, as the song goes, you know, "If you can't be with the one you love, love the one you're with."

And a lot of us have to do that. Customer X uses quality product Y. They don't necessarily love all of it but they’ve got so much value invested in it today that it's going to be difficult to change. It's one of those things where it's very difficult to transition without putting a stop to everything for longer than we'd want to. So, the reality in the world is switching some of these tools out and picking best of the breed is itself a huge tradeoff in terms of what is that going to cost.

You have to develop a plan of who's going to start using  a particular tool, how are they are going to fit into the rest of the world, how do we make sure that when we swap that we don't have two systems of record where we used to have one and now we're asking people to context-switch back and forth, and all of a sudden it can get pretty messy.

A lot of times, that turns into inertia. And it's so difficult to get people out of that rut of inertia, and for good reason, because it's really expensive to do it and it takes a lot of time. If you're a company of 50,000 people and you've got 10,000 people in Dev and Ops. that's a massive investment in the current toolset, the current training, the current folklore. I love it that we're talking about best of breed and getting value out of variety and all of those things. But it's a big tradeoff the bigger you get.

Adapting to the Changing Environment

We're a small company and it's difficult for us to evolve our toolchain. I see how much more difficult it is for larger companies. Inertia is there on day one. Fight it somehow.

I'm not sure those things are incompatible with each other, quite frankly. I always just ask, "Please Lord, is there an API for this?" There are some products out there where, "Yeah, you can only do that through the GUI. Oh, you can only do that through the web UI." It's like no, no. Just please give me an API, please. I'll just ask for that, then, you know, the rest is gravy. I've simple tastes.