What do you think?
Rate this book
Operations Anti-Patterns, DevOps Solutions
Operations Anti-Patterns, DevOps Solutions shows how to implement DevOps techniques in the kind of imperfect environments most developers work in. Part technology tutorial, part reference manual, and part psychology handbook, this practical guide shows you realistic ways to bring DevOps to your team when you don’t have the flexibility to make sweeping changes in organizational structure.
Summary
Operations Anti-Patterns, DevOps Solutions shows how to implement DevOps techniques in the kind of imperfect environments most developers work in. Part technology tutorial, part reference manual, and part psychology handbook, this practical guide shows you realistic ways to bring DevOps to your team when you don't have the flexibility to make sweeping changes in organizational structure.
Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.
About the technology
To some extent, all organizations—even yours—suffer from poor development practices, garbled communications, and outdated legacy systems. The good news is DevOps can help you improve your processes. First, however, you'll need to recognize the core issues holding you back. This book empowers you to deliver DevOps with limited resources while navigating the office politics and entrenched mindsets that are all too common in actual workplaces.
About the book
Operations Anti-Patterns, DevOps Solutions offers clear steps for transforming development and communication. Using jargon-free language, this book describes incremental techniques that pay off immediately. Streamline your workflow, manage unplanned time, and build operational metrics. Whatever your issues, this book holds the keys to organizational success.
What's inside
Turn failure into opportunity
Drive change through culture
Break down knowledge silos
Settle middle management turf wars
About the reader
For team leaders and managers.
About the author
Jeffery D. Smith has been in the technology industry for over 15 years. He has managed DevOps transformations at the ad-tech firm Centro and the online ordering platform Grubhub.
Table of Contents
1 The DevOps ingredients
2 The paternalist syndrome
3 Operational blindness
4 Data instead of information
5 Quality as a condiment
6 Alert fatigue
7 The empty toolbox
8 Off-hour deployments
9 Wasting a perfectly good incident
10 Information Only Brent knows
11 Culture by decree
12 Too many yardsticks
Summary
Operations Anti-Patterns, DevOps Solutions shows how to implement DevOps techniques in the kind of imperfect environments most developers work in. Part technology tutorial, part reference manual, and part psychology handbook, this practical guide shows you realistic ways to bring DevOps to your team when you don't have the flexibility to make sweeping changes in organizational structure.
Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.
About the technology
To some extent, all organizations—even yours—suffer from poor development practices, garbled communications, and outdated legacy systems. The good news is DevOps can help you improve your processes. First, however, you'll need to recognize the core issues holding you back. This book empowers you to deliver DevOps with limited resources while navigating the office politics and entrenched mindsets that are all too common in actual workplaces.
About the book
Operations Anti-Patterns, DevOps Solutions offers clear steps for transforming development and communication. Using jargon-free language, this book describes incremental techniques that pay off immediately. Streamline your workflow, manage unplanned time, and build operational metrics. Whatever your issues, this book holds the keys to organizational success.
What's inside
Turn failure into opportunity
Drive change through culture
Break down knowledge silos
Settle middle management turf wars
About the reader
For team leaders and managers.
About the author
Jeffery D. Smith has been in the technology industry for over 15 years. He has managed DevOps transformations at the ad-tech firm Centro and the online ordering platform Grubhub.
Table of Contents
1 The DevOps ingredients
2 The paternalist syndrome
3 Operational blindness
4 Data instead of information
5 Quality as a condiment
6 Alert fatigue
7 The empty toolbox
8 Off-hour deployments
9 Wasting a perfectly good incident
10 Information Only Brent knows
11 Culture by decree
12 Too many yardsticks
320 pages, Paperback
Published November 24, 2020
17 people are currently reading
145 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 8 of 8 reviews
January 23, 2021
Wow, I really enjoyed this book. It is clearly written by someone who has lived operational pain and come out the other side. It's a great collection of practical advice to improve the operations (and developer) side of any technology team.
The Good:
- Great, practical advice throughout. I found the format of focusing on antipatterns really helpful, because I can relate to a lot of the problems Smith has identified and it's nice to be able to start with a problem and understand why it's bad. Smith's thoughts can be really helpful to frame discussions with your own leadership.
- Great framing for problems I hadn't been able to put words to before:
- The empty toolbox - for organizations which think about the product or feature being released, but not the work required to maintain it or the tools required to make that maintenance bearable.
- Quality as a condiment - for organizations which use QA as a replacement for unit testing (scream)
- Super well written, really funny in places, all around great.
The Less Good:
- The audience is a little tricky. Smith states that the book targets ICs, in my experience many of these things will be hard to implement unless you're a senior IC or a mid-level manager with a lot of leverage in your organization. That said, I think there's value in this book for both brand new ICs - here are some things to think about as you gain influence - as well as high level managers - here's why this thing you're proposing is getting some push back.
- The author is clearly quite technical, but I actually felt the most useful parts of the book were in the high level ideas. I started to doze off a bit when we got into code examples and details (of which there aren't many sections). I might have cut those out entirely, since the main points were well delivered in the high level section.
Favorite quotations:
> Lots of companies have a dedicated quality assurance (QA) team that’s responsible for ensuring that you’re producing a quality product. But the quality of the product can’t exist in itself. Overall quality comprises the quality of all the individual ingredients. If you’re not checking the quality of the ingredients, the quality of the final product can be only so good. Quality is not a condiment. Not in restaurants, and not in software development.
> Here’s another example of how companies value some documentation and not others. Have you ever launched a service, application, or product without any documentation around it? Most of you probably have. In organizations like that, documentation might be important. The company wouldn’t stop you from providing documentation on the product and would probably even applaud you. But when push comes to shove, if you need to launch that product, a lack of documentation is definitely not going to delay deployment.
> The documentation isn’t really the end goal. The end goal is the sharing of information. If you can get the same quality of information sharing via a different means, then it might absolutely be worth it to skip the mounds of written documentation in favor of something a little easier to manage or produce. The value of documentation must exceed the opportunity cost of producing it.
> Automated testing is often held to the unfair silent standard that if it doesn’t catch everything, it isn’t worth anything. People don’t openly say that, but they treat it that way in their behaviors and their approach. Teams will stall on automation because of all these esoteric edge cases that might be difficult to catch. The automation must be flawless. That’s a false dichotomy, and you should fight that at every level of the organization.
> The industry tends to focus on the FANG companies (Facebook, Apple, Netflix, and Google) and the way they go about solving problems. But truth be told, most of you reading this book aren’t facing the same types of challenges that the FANG group is. Most of us are solving the same problems over and over again en masse.
> The fear of deploying is also related to the effort it takes to roll the change backward in the event of a failed deployment
The Good:
- Great, practical advice throughout. I found the format of focusing on antipatterns really helpful, because I can relate to a lot of the problems Smith has identified and it's nice to be able to start with a problem and understand why it's bad. Smith's thoughts can be really helpful to frame discussions with your own leadership.
- Great framing for problems I hadn't been able to put words to before:
- The empty toolbox - for organizations which think about the product or feature being released, but not the work required to maintain it or the tools required to make that maintenance bearable.
- Quality as a condiment - for organizations which use QA as a replacement for unit testing (scream)
- Super well written, really funny in places, all around great.
The Less Good:
- The audience is a little tricky. Smith states that the book targets ICs, in my experience many of these things will be hard to implement unless you're a senior IC or a mid-level manager with a lot of leverage in your organization. That said, I think there's value in this book for both brand new ICs - here are some things to think about as you gain influence - as well as high level managers - here's why this thing you're proposing is getting some push back.
- The author is clearly quite technical, but I actually felt the most useful parts of the book were in the high level ideas. I started to doze off a bit when we got into code examples and details (of which there aren't many sections). I might have cut those out entirely, since the main points were well delivered in the high level section.
Favorite quotations:
> Lots of companies have a dedicated quality assurance (QA) team that’s responsible for ensuring that you’re producing a quality product. But the quality of the product can’t exist in itself. Overall quality comprises the quality of all the individual ingredients. If you’re not checking the quality of the ingredients, the quality of the final product can be only so good. Quality is not a condiment. Not in restaurants, and not in software development.
> Here’s another example of how companies value some documentation and not others. Have you ever launched a service, application, or product without any documentation around it? Most of you probably have. In organizations like that, documentation might be important. The company wouldn’t stop you from providing documentation on the product and would probably even applaud you. But when push comes to shove, if you need to launch that product, a lack of documentation is definitely not going to delay deployment.
> The documentation isn’t really the end goal. The end goal is the sharing of information. If you can get the same quality of information sharing via a different means, then it might absolutely be worth it to skip the mounds of written documentation in favor of something a little easier to manage or produce. The value of documentation must exceed the opportunity cost of producing it.
> Automated testing is often held to the unfair silent standard that if it doesn’t catch everything, it isn’t worth anything. People don’t openly say that, but they treat it that way in their behaviors and their approach. Teams will stall on automation because of all these esoteric edge cases that might be difficult to catch. The automation must be flawless. That’s a false dichotomy, and you should fight that at every level of the organization.
> The industry tends to focus on the FANG companies (Facebook, Apple, Netflix, and Google) and the way they go about solving problems. But truth be told, most of you reading this book aren’t facing the same types of challenges that the FANG group is. Most of us are solving the same problems over and over again en masse.
> The fear of deploying is also related to the effort it takes to roll the change backward in the event of a failed deployment
May 19, 2024
This was a good book but I found the content a bit basic after a long time in the industry but if I was reading this for the first time I would have gotten more value. It felt like the book wanted to be technical in the beginning but decided to become people/process focused in the back half. Overall good if you are new to the concept of devops but not a mandatory read if you're already familiar with many of the topics.
November 24, 2020
A comprehensive account of migrating to a DevOps and more flexible mindest across a whole company.
March 2, 2021
Great book for anyone interested in DevOps
April 9, 2021
Excellent book to apply immediately as a devops
April 24, 2021
Pragmatic and practical solutions for implementing DevOps. While most wasn't new to me it would be great for new comers or as a refresher.
September 9, 2021
Great Book. It takes the heart of the problems- anti-patterns, tools first approach, devops as title and team. Must Read!
July 10, 2024
This was a slog. Some of the contents are interesting, but the book lacks structure, the author frequently repeats himself, and some of the material is only tangentially related to the core topic. I appreciate a DevOps book that focuses on principles rather than tools. But this could have been probably 30% of the length.
Displaying 1 - 8 of 8 reviews