Orchestrating Your DevOps Toolchain

What is the value of integrating teams and tools in a way that provides shared visibility and control across the end-to-end process – with orchestration?

Last Tuesday I participated in an online panel on the subject of Orchestrating Your DevOps Toolchain, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps.

Watch a recording of the panel:

Continuous Discussions is a community initiative by Electric Cloud, which powers Continuous Delivery at businesses like SpaceX, Cisco, GE and E*TRADE by automating their build, test and deployment processes. Below are a few insights from my contribution to the panel:

Why Orchestrate?

Well, you don’t want to waste your time doing stuff that can be automated. You’re saving resources, you’re screening errors, if it’s a script, you don’t have to think about it. If you’re trying to reach some level of complexity, the more complicated it becomes the more benefit you’re going to get out of that.

But most of it, from the start-up perspective, is you speeding up the feedback. Most of the time we are guessing that something is valuable, the only way to make sure that it’s actually valuable is to go and deploy into production – let people use it. The more people use it the more feedback you get, the faster you can get something to production, the faster you can verify that something is working or not working. And that’s feedback.

And then you have to write less documentation, if you have everything automated you can just go read the script. You still need to document, you can explain some things, but still – documentation gets out of sync.

How and Where Does Orchestration Help?

Well, I cannot think of anything that wouldn’t benefit from orchestration. Most of my work is web applications so there it’s just essential, possibly the easiest to do. You want to start, it’s very easy if you have a new project, and just start from automating everything, sometimes you can’t do that – you have to go and break things and that’s usually when things get messy – but you still will benefit.

My current project is a hybrid web app, before that it was it’s more of a virtual appliance, so it is web – but before it was web application. In one place it wasn’t automated but it got automated, and in one we started a greenfield project, so it was automated from the beginning.  So I have experience in breaking down and trying to automate it and starting from the beginning – and much easier and pleasant, a project like that.

The benefits, well, the feedback… that’s, you, well, that’s key, right? but, Autotrail – if you script it, automate it, once again – you don’t have to, well, you do have to write a documentation but it just, you can read it and say what’s going on.

Bringing Orchestration to the Organization

It’s really hard if the team doesn’t understand they need orchestration, or in some cases automation, hopefully there are not many of those left…. But if they don’t – I mean, I guess you can go and say ‘Oh, I know better’, but usually that doesn’t work, so you will have to start with the process – from my experience it involves writing a lot of build scripts and deploying stuff and figuring out the versions and all the other stuff so you can go and try to give them the tools, but usually, in my opinion that’s probably going to fail, because it all starts with people.

But hopefully there are not that many people left who don’t think that automation is a good thing –  so you start to break out the process, and try to automate parts, little by little – and then orchestrate the little ones.

So, what I think is happening – the power struggle between development and management, is sort of like the same problem as with people trying to lose weight, the problem with losing weight is not that you eat a lot, it is that the habits you have are bad, and unless you change those habits nothing’s going to happen. And it doesn’t matter what diet you use, it doesn’t matter what magic pill you’ll use, you’re going to go back to same ways.

The same principal is at work here – if the developer doesn’t have or doesn’t acquire those habits, the system – it’s not going to work, it starts with the people. It doesn’t matter what tools you get, it doesn’t matter what new technology – web, service, it doesn’t really matter – you can do the same things with a Bascript, it’s going to be ugly and it’s probably going to create more problems but you can. Like, it doesn’t matter what tool it is, what matters is what habits you have, what you do – discipline.

And in a lot of cases you, like, people, like, it is a good market, for a developer it’s an amazing market, you don’t have to it the way somebody tells you to do it, in most of the time it’s just interesting to, you know, play with a new technology instead of sitting there writing build scripts and managing the dependencies, so people will do that.

If you don’t have support from the top it’s just not going to work. But that’s a part of the struggle, right? If the operation, the purpose of operation is say, that nothing changes – the purpose of development, putting new features in, actually drive that change. That is valuable change, valuable for the organization, valuable for producing the value, and the ops making sure – that’s the point of DevOps, that you have to negotiate, you have to start from the beginning.

It’s not like, sure, let’s use the cool technology, DevOps is not a technology, DevOps is a way that people talk to each other. People have to say, from the beginning, ‘Hey, this stuff is valuable, lets figure out how to do it’, and put in production and see if it’s actually valuable. So of course people are going to understand the value of it at the top, right? They are driving that value, the developers are supposed to produce it, but we get, the habits, it just all comes back to habits – if the way we’re producing that value is a, if the old habits worked, and there was no pain, why change?

Tips and Tricks

One tip is when you hire somebody, make sure that people in your team like each other. So give them a choice, talk to the people, and if they don’t, they don’t, if they do – that’s going to do half of the job.

And the second one – talk to each other. The more people inside the organization talk and communicate that this is going to happen, the automation is going to happen probably naturally, because the developers like to automate things and if you give them a way to do it their way, it’s probably going to happen. Talk to each other.

View All

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.