The DevOps Toolchain per Lee Atchison, New Relic
The DevOps Toolchain per Lee Atchison, New Relic
The toolset needs to provide vision across the entire DevOps methodology. Read on for more insights from Lee Atchison in the Continuous Discussions podcast.
Join the DZone community and get the full member experience.Join For Free
Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market.
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 Lee Atchison, Senior Director for Cloud Architecture at New Relic, Ian Buchanan, Principal Solutions Engineer for DevOps at Atlassian, 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 Lee’s thoughts on the four topics we discussed:
The DevOps Toolchain as a Value Stream
I can't express enough the value of having a single set of integrated tools that show you a broad picture across the entire spectrum of that process. And you know, there is so much that can be learned from one side of the process by knowing how the other side of the process is working. And you can't get that if you have these pair of tools that aren't working together. So whatever the tool is you're using, and there are lots of good tools, the tools should be able to incorporate data from all sorts of different areas and make a consistent whole that everyone has access to.
Not just a few people that might need the ops-view as part of their job, give that data and that view to everybody. Because everyone can look and see the data from a different angle and see a different aspect of it. And that provides value to the organization, understanding how the other parts of the organization are working.
Using Tools to Align People and Teams
That's a good question. You know, there's a couple different aspects when you think of monitoring. And certainly, if you look at where monitoring sits in the toolchain it looks like it's at the end, right? It's after you deploy, it's out in production, you monitor to make sure it works. And that's certainly important to catch hiccups that occur during your deploy and latency problems that occur. But that's just one aspect of the monitoring that's important to DevOps and to the teams that are dealing with DevOps.
Monitoring is also about the front-end of the process. It's about getting data into the pipeline to support planning and improvements and to identify the areas where you need to make improvements to your application. And getting the data that supports decisions on what you should be working on into the front-end.
So monitoring is this piece really that takes what could be a straight line and turns it into the Mobius loop of the DevOps methodology. It's the thing that makes it a continuous process. And that's really what's critical here. But it's also a tool that helps with the collaboration process throughout all steps. And much like you were talking about the security aspect, understanding how monitoring the application as well as monitoring the toolchains affects everyone in that process, it allows you to help with problem diagnostics in the application and allows you to handle problem diagnostics within the toolchain.
It gives you the visibility you need. And as I was saying earlier, it gives everyone in the organization the visibility they need to understand what's going on everywhere. And by giving everyone the same level of visibility, it makes decisions more uniform, it makes problems easier and quicker to find, to identify where the problem exists and therefore, makes the resolution of those problems and the cycle time through this whole loop much, much faster.
But I also think this way too, you had a problem, you're running into where a problem is, and you have to fix the problem of the moment but then you want to start looking at the post-mortem of what's causing these issues, what is causing these problems to occur. And you find that there are certain parts of the application that are making significant changes very quickly and perhaps you're not going through the cycle quite as reliably and efficiently, especially if some of the verification steps or the security steps as it should be.
So understanding the visibility that monitoring can give you in the toolchain itself can give you the visibility on the teams that need to make some improvements or the parts of the application that are working great or which ones are not and where you really need to focus the most effort.
Is There One Right Tool?
We all work for companies and we all have our own agendas. But really, what's most important is to make sure you use a tool that's appropriate for your job and there isn't one tool that will solve all of the needs of all of the parts of DevOps value chain nor is there one tool that will solve everyone's needs for everybody that might approach the problem.
So, when we talk about monitoring, what's the number one most important thing about monitoring? It isn't that you use New Relic, it's that you make sure you monitor at all. Make sure you're monitoring. Whatever tool you use is less important, just make sure you're using a tool and you're using it appropriately.
With that said, I will say there is value in having a single tool for a given purpose and then making sure all the tools interconnect. We were talking earlier about the value chain, of allowing everyone access to all the same data, really requires your tools to be a unified set of tools that work well together and can create the unified view with one set of data that gives you the answers to the problems that you need at the same time versus conflicting data from different teams because they're using different tools for different purposes and all the complexity involved with that. So, while there's value in allowing teams to make decisions, there's also value in standardization in a lot of respects.
Adapting to the Changing Environment
It's APIs help you to give you the ability to swap tools out while reducing friction. But it's not just APIs, it's also integrations. And integrations are not APIs. As a company, I can say, "Hey, I have an API that does everything I need or want anybody to be able to do," and call it a day. That doesn't do anything to help if all the other tools have their own APIs and there's no integration between those APIs. The glue is really what I'm talking about here.
It’s not just building APIs to make sure people can get data out of our application and out of our tools. It's making sure our tools work with all of the tools that are involved in the toolchain upstream, downstream, side stream from all of us. To make sure that they work together in a way that's effective for our customers. And so, it's not just the APIs it's making sure the APIs are correct, work together, and integrate with the products that our customers care about. And that's the only way you're going to make sure a tool can easily slide in and slide out of any particular slot and minimize the stress involved in doing that.
Opinions expressed by DZone contributors are their own.