In this video, learn about the role of tools in DevOps and tips for selecting and using tooling to achieve your end goal.
- We love tools and rightly so, they enable us to code, build, test, package, release, configure, and monitor our systems and applications. - There's been a great explosion in tools, both free, open source and commercial, along with the rise of DevOps. This makes sense. Innovation in tooling had stagnated in operations. For many years, I was using the same ops tools in 2009 that I'd started using back in 1999. Many of these new tools are pretty amazing in terms of the capabilities they bring to the service lifestyle. - [Man] We often refer to the DevOps tool chain. There's not a single tool that will do everything you need. So what you want is a series of tools that can be composed into a tool chain to address your needs. - [Man] But you want them Work together like how a Unix Command Pipeline flexibly, composes commands together. - Yeah Remember the first way systems thinking a tool is only useful to the degree that it supports your entire system. Be thoughtful about choosing your tools, make sure they are compliment both each other. And your strategy. - Also keep in mind that every tool you implement has a logistics tail. That's a fancy way of saying it has an ongoing cost. It may cost money, but even if it doesn't have a list, price, people in your department have to spend the time to learn it. And it's another application itself that needs maintenance upgrades, et cetera. There's definitely such a thing as too many tools, but it's also naive to think that tooling is only an outgrowth of higher level DevOps strategy and not a driver of it. Sometimes new technology changes our culture. The ubiquity of smartphones, for example, has implications that weren't fully understood when the technology was created. - The same thing applies to DevOps tooling, configuration management existed long before cloud computing was common. It was often implemented only as a nice to have afterthought though, but as workloads move toward the cloud, this pattern flipped to where configuration management becomes. One of the first things you need to implement. - [Man] These tools can lead to amazing new capabilities, but could also be a threat to those who don't change their approach to take the new tools into account. Automating your systems can just give you a way that crash them all at once. Instead of one, at a time, your tactics will have to change in the face of these new tools to avoid that kind of effect, which is why we stress the values, principles, and methods of DevOPs first, and the tools last. - [Man] let's talk about what you want in a tool set. First you want the tool to play well with others in the tool chain. It should be able to perform its work in an automated manner. You should be able to call it and invoke it from an API or the command line tools that are only UI driven. They're going to prove to be poor citizens in your tool chain, - [Man] Second you want the tool to be verifiable. Keep in mind, Ronald Reagan's favorite Russian proverb. He liked to quote during the cold war trust, but verify the best kind of DevOps tool exposes clearly what it's doing and provide some manner of validating that it did, what it was supposed to do correctly. Events and metrics from your tools are an important source of feed. - [Man] In third, just like kids. It's got to be well behaved both from a developer point of view and an operations point of view. You should be able to check the tools configuration into source control. It should come with tests that can be used to verify its behavior, and you should be able to deploy it in an automated manner. The tools don't have to supply this feature themselves, optimally. They would probably just plug into existing channels like being distributed as a WN package, or maybe the tool provider would have a chef cookbook. - You'll also find yourself writing your own tools. This is fine. You should see if you can use an existing tool to suit your needs first, but oftentimes you may not find the perfect fit. And one of the points of the Dev and DevOps is to be able to roll your own when you need to, as you develop your own tools though, keep these three criteria in mind so that your tool is well behaved. - We'll talk more about specific tools later in context of the three pillars of dev ops, infrastructure, automation, continuous delivery, and reliability engineering.
In this course, well-known DevOps practitioners Ernest Mueller and James Wickett provide an overview of the DevOps movement, focusing on the core value of CAMS (culture, automation, measurement, and sharing). They cover the various methodologies and tools an organization can adopt to transition into DevOps, looking at both agile and lean project management principles and how old-school principles like ITIL, ITSM, and SDLC fit within DevOps.
The course concludes with a discussion of the three main tenants of DevOps—infrastructure automation, continuous delivery, and reliability engineering—as well as some additional resources and a brief look into what the future holds as organizations transition from the cloud to serverless architectures.
- What is DevOps?
- Understanding DevOps core values and principles
- Choosing DevOps tools
- Creating a positive DevOps culture
- Understanding agile and lean
- Building a continuous delivery pipeline
- Building reliable systems
- Looking into the future of DevOps