Increase profitability, elevate work culture, and exceed productivity goals through DevOps practices.
More than ever, the effective management of technology is critical for business competitiveness. For decades, technology leaders have struggled to balance agility, reliability, and security. The consequences of failure have never been greater whether it's the healthcare.gov debacle, cardholder data breaches, or missing the boat with Big Data in the cloud.
And yet, high performers using DevOps principles, such as Google, Amazon, Facebook, Etsy, and Netflix, are routinely and reliably deploying code into production hundreds, or even thousands, of times per day.
Following in the footsteps of The Phoenix Project, The DevOps Handbook shows leaders how to replicate these incredible outcomes, by showing how to integrate Product Management, Development, QA, IT Operations, and Information Security to elevate your company and win in the marketplace."
Table of contents
Preface Spreading the Aha! Moment Introduction
PART I: THE THREE WAYS 1. Agile, continuous delivery and the three ways 2. The First Way: The Principles of Flow 3. The Second Way: The Principle of Feedback 4. The Third Way: The Principles of Continual Learning
PART II: WHERE TO START 5. Selecting which value stream to start with 6. Understanding the work in our value stream… 7. How to design our organization and architecture 8. How to get great outcomes by integrating operations into the daily work for development
PART III: THE FIRST WAY: THE TECHNICAL PRACTICES OF FLOW 9. Create the foundations of our deployment pipeline 10. Enable fast and reliable automated testing 11. Enable and practice continuous integration 12. Automate and enable low-risk releases 13. Architect for low-risk releases
PART IV: THE SECOND WAY: THE TECHNICAL PRACTICES OF FEEDBACK 14*. Create telemetry to enable seeing abd solving problems 15. Analyze telemetry to better anticipate problems 16. Enable feedbackso development and operation can safely deploy code 17. Integrate hypothesis-driven development and A/B testing into our daily work 18. Create review and coordination processes to increase quality of our current work
PART V: THE THRID WAY: THE TECHNICAL PRACTICES OF CONTINUAL LEARNING 19. Enable and inject learning into daily work 20. Convert local discoveries into global improvements 21. Reserve time to create organizational learning 22. Information security as everyone’s job, every day 23. Protecting the deployment pipeline
PART VI: CONCLUSION A call to action Conclusion to the DevOps Handbook
APPENDICES 1. The convergence of Devops 2. The theory of constraints and core chronic conflicts 3. Tabular form of downward spiral 4. The dangers of handoffs and queues 5. Myths of industrial safety 6. The Toyota Andon Cord 7. COTS Software 8. Post-mortem meetings 9. The Simian Army 10. Transparent uptime
Gene Kim is a multiple award-winning CTO, Tripwire founder, Visible Ops co-author, IT Ops/Security Researcher, Theory of Constraints Jonah, a certified IS auditor and a rabid UX fan.
He is passionate about IT operations, security and compliance, and how IT organizations successfully transform from "good to great."
As a seasoned DevOps and Continuous Delivery practitioner, I didn't find this book useful or inspiring.
It's an attempt to put both technical and organizational practices in a single book, which is too much. The result is a vast, dry list of practices described "do this, do that..." format. Format full of content, but pretty boring.
Instead:
* For technical practices, read Continous Delivery (older, but more in-depth book). * For organizational and team practices, read Teams Topologies. * For inspiration, read The Goal and The Phoenix Project.
If this had been published in the 90s it would've been groundbreaking (and wrong). Published in the early 2000s it would've been bold. Publishing it now is redundant. Terms like CI are so common you don't even need to explain the initialism.
I was severely disappointed with this book. It is NOT a handbook of any kind. This is pure evangelism aimed at managers. Also, very quickly, I realised how extremely narrow the authors' world is. Basically: web services. Almost every argument and anecdote is based on the confines of the crazy world of silicon valley and web startups.
Most of the content is highly repetitive and very broad, not going into any useful details. None of the caveats or drawbacks are considered, just pure hype. It is not nuanced.
The authors are not wrong (most of this is common sense and not some novel process), it's just not a very good book.
tl;dr This is a must-read for anyone who wants to understand, explain and implement DevOps culture, process and tools for high performance development and operations.
The DevOps Handbook (437 pages, 2016, Kim, Humble, Debois, Willis, Allspaw) is a must-read for anyone who wants to understand, explain and implement DevOps culture, process and tools for high performance development and operations. The Phoenix Project (2013, Kim, Spafford, Behr) took us through the challenges of IT development and operations in narrative form, and showed us sensible and human-centric solutions. The DevOps Handbook builds on that and provides a more detailed and practical guide to apply those solutions within your organization. It also extends the solutions from The Phoenix Project to cover information security and compliance.
The book includes case studies from Google, Capital One, Target, Netflix, etsy and other companies, demonstrating how DevOps culture and practices can improve business outcomes. There is material here for stakeholders in almost all parts of the organization, including upper management, operations, info sec, development and compliance.
I read this book cover-to-cover. The authors’ advice is thought provoking and should spark dozens of productive discussions within your team.
It's not as good as I hoped for, after the fabulous 'Phoenix Project'. The technical level is perfect for a high level overview for a technical manager, but don't expect detailed guidance from this book.
Also if you are a frequent blog reader, you might already heard or read most of the things. It's good to have it in condensed form.
All the case studies give the book a nice grounded touch, but as the recent events around Etsy and Yahoo have shown, sometimes it might still not work out in the end. I hoped that the book would be honest about this and it ultimately is, in the last paragraph
This book actually reminds me of the book “Release it ” but with much less emphasis on actual technical patterns but with a stronger accent on soft skills.
It’s also complimentary to the “Phoenix Project” written by the same authors.
If you’ve skipped the “Phoenix Project” or you don’t like to read the novels, like I do, I would recommend you to start with this book as it has much more momentum than the first book.
It has a bunch of great inspiring examples of successes from the companies that have embarked on the “DevOps journey” which to me is the best part of this book. Also the book is relatively recent therefore a lot of its advices are quite innovative and might be even disturbing to some.
This book describes a new way of structuring work for tech teams: DevOps.
While the old way of doing things included many different departments working together (e.g. database department, QA department, testing department) which caused a lot of bottlenecks and low deployment frequencies, DevOps aims to eliminate these bottlenecks with putting all of these fields closer together and tries to build structures where we frequently add changes to our code and deploy it quickly.
More precisely it focuses on three principles that seem to be important in the DevOps philosophy.
I: Flow Which methods can we use to shorten the time between a customer request arriving and deploying this feature to the live version of our application?
II: Feedback It is very important, that we as developers have fast and iterative feedback on our work, so that we can learn and adopt new things quickly instead of sticking to bad habits for a long time.
III: Continous Learning and Experimentation It is good to adopt the mindset of being lifelong learners across the whole team and build structures where everyone feels secure and is motivated to learn.
After explaining these concepts on a theoretical level, it follows with more practical guidelines and how to implement these.
The book is very tedious to read and I personally would have liked more practical examples on how to implement these things on a technical level. Instead there were too many stories from companies that had success with DevOps for my taste.
Overall it still is a very good introduction to the topic and made me curious to go deeper and try new techniques like implementing CI/CD pipelines and TDD.
Finally gave up on this around the halfway mark. I did the audiobook version of this and it was just a sleep-inducing experience for the vast majority of the time. What finally broke me was when I realized I had completely zoned out for a good 15 minutes, but I didn't feel like I actually missed much or care if I did. Having done The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win a few years ago and having enjoyed that, I thought I'd give this a go as a refresher of the concepts brought up in that book. Unfortunately, while The Phoenix Project was well written and did a great job of giving context to the various ideas it espoused, this was basically a textbook of outdated information that pretty much everyone already knows.
The only target audience this might be for anymore is for students that have no experience working in an organization with an IT department. However, that's also why I can't in good conscience give this a 1-star rating since the information contained here is fairly solid and informative, albeit quite dated at times. The dry and overly structured presentation of the information is also perfect for students already used to that kind of delivery method, unlike me who has this weird notion that books should be enjoyable to read.
In the beginning, a lot of this book felt like a lengthy advertisement for The Phoenix Project, but my opinion improved over time. The material overall is not particularly new or earth-shattering, but the book does a good job of collecting several practices and underscoring their importance in a larger context. While the book has an understandable focus on cloud development, with a bit of ingenuity, several of the practices could also be adapted to more legacy desktop software development areas.
I did, however, find it extremely irritating how often the authors overused the phrase "win in the marketplace." a) It felt like lazy writing and editing that they couldn't come up with another description of overall project success, and b) For teams working on internal systems development, "winning in the marketplace" doesn't necessarily carry much weight or meaning.
Is there really a need for another book about DevOps? This trend? movement? paradigm? approach? is present for at least few years & we have tremendous numbers of various types of materials & tools - is there a niche for this book then?
I dare to say - it is.
Need for DevOps has been well described in Lean Enterprise, common practices have their description in Continuous Integration & Continuous Delivery books, there are plenty of specialized books for particular tools / platforms, BUT WHAT WE WERE MISSING (in a concise, written form) is the "soft-side" of "how-to". And it's extremely important, because many people still:
* miss the whole point of DevOps * think about DevOps as a specialized role of certain individuals * consider DevOps as a purely technical "thingie"
IMHO this books helps to fix these perspectives in a very clear way - I really liked the way authors have decomposed the topic into three sub-areas of: (work) flow, feedback loop and continuous learning (& experimentation).
OK, about the book itself: not surpisingly (if you've read earlier Kim's or Humbles' books) it's approachable, well written & to-the-point. It's completely tech-agnostic, quotes scenarios from very different types of enterprises (not just SV unicorns), isn't overzealous about non-core principles (pragmatism FTW).
Recommended for everyone who wants to understand what's expect from modern IT delivery unit.
Paired with Google's SRE book these two are absolutely required reading for anyone trying to build modern, reliable and long living software. This book covers a lot of ground in terms of best practices on getting your code from the repo to running in production, starting at the basics, with automated testing, metrics and logging collection, outliers detection, desaster recovery, bottleneck removal, how to introduce security and hardening best practices, how to sell these improvements to top leadership and how to cause change in organizations that might not thing they need to change stuff.
It's full of actual case studies, with reports from the people that were fighting the issues, what they did, whether it was right or wrong and the outcomes of these decisions. The focus on lean, removing roadblocks and lead time to deliver is also a blessing, helping you to point out exactly where the issues that are preventing you from producing software faster are, even if you can't see them right now.
This is a must read for anyone that is serious about running stuff in production for real.
I believe this book captures the true spirit of the DevOps movement, it lays down the problems & challenges clearly, sets the stage for different roles in the organization, and offers a clear path from traditional model to an organization that efficiently delivers value continuously. Highly and strongly recommended
Innovation is impossible without risk taking, and if you haven’t managed to upset at least some people in management, you’re probably not trying hard enough.
Great book! It would be better for me to have read it 4-5 years ago, but nonetheless it was interesting to know that I adopt or learn the principles and methodologies by trying and failing and by meeting people that helped me to understand what DevOps is and why it was born. Hope every companies by now, even no tech companies but that use technology, are adopting this for a while or are adopting or they will be out of business very soon or at least without the best persons for the job.
I enjoyed reading, but because it not showed me nothing new, I gave only a 4 star.
My 2nd time reading this was much better. The first time I felt like it was too much information packed into it.
But after a few years working in devops and coming back to it I found it to be pretty amazing. It does contain a ton of information and repeats things but in a deliberate way.
As others have said it's a must read for devops professionals, developers, testers or managers. It's a philosophy, not tools and this book lays out the philosophy well.
I found it an easy read, common sense and with numerous useful examples. I won't offer up the cliche that more developers should read this book but will offer up the suggestion that more of them follow up by implementing it's suggestions.
The start of the book is very engaging but later its becomes little boring due to either too much details and book talks about only one company called Etsy. I like the case studies in the relevant chapter but few places it just doesn't make sense. Overall good read but unfortunately not very productive. There is plenty of information and reference material available at the end which occupies almost 20% of the book. I think I expected more.
Devops is not a designation. It's a culture of adopting some practices, principle and tools to improve your all means of engineering. Dev QA ops sec whatever you call. learning and experimenting is much important. I recommend this book to all folks doing software development, testing , security, operation etc..
Well written, good content. Lack of fifth star is more about me than the book itself. It wasn't too engaging and it's probably due to my familiarity with the ideas discussed.
This is an excellent overview of devops, including a summary of lean manufacturing, agile software development practices, security and compliance issues, etc. The authors stayed at a relatively high level - we will not find detailed solutions with exact steps here. Rather, the book points you to areas you might want to research further.
I am familiar with automated testing and continuous delivery practices, so most of the book sounded pretty familiar. The authors focused on IT practices of large and mostly web-based companies, whose business is essentially creating and running software on large-scale server farms. The issues and case studies emphasize large organization issues, changing slow, traditional practices to agile/devops principles.
If your software is used for controlling hardware, however, the book offers little insight. You can’t automatically create CNC machines and hardware components, so creating environments on demand is not possible. It also does not address small and midsize companies.
The text is rather dry and often repetitive. I have listened to the audiobook, if I was reading, I would have probably skimmed quite a bit. Kudos to Ron Butler for bringing life and interest to the text.
Overall this is well worth to keep on your reference book shelf.
Ótimas ideias, conceitos muito bem explicados, cases coerentes e que dão esperança de dias melhores para quem não vive uma cultura assim.
Senti falta de cases de empresas menores, onde a luta entre feito e perfeito acontece de forma mais visceral, vejo que empresas gigantes não tem opção a não ser fazer da melhor forma possível, o melhor e mais seguro produto possível. É muito mais fácil e prudente adotar e adquirir uma cultura devops quando se tem dinheiro para investir no longo prazo, que quando se luta para pagar o jantar. Nessa segunda situação, eu sempre presenciei os defensores de projetos de longo prazo serem taxados como apaixonados malucos que não entendem o mundo real.
Ao fim do livro fica a sensação de que só vai ganhar dinheiro quem adotar devops, e que só vai adotar devops, quem tem dinheiro para suportar a pressão do início, que é quando todos os problemas são tirados debaixo do tapete.
I'd recommend this book to anyone who wants to work—or currently works—in software. For experienced professionals I believe this would be a nice reminder, but for newcomers this is an invaluable resource. Throughout the book you are presented different case studies into how big technology organizations work—Google, Netflix, AWS, among others—and given practical advise as to how you can implement this into your own endeavors. While reading this I was working on my own software project and applied many of the techniques described in this book: testing, linters, formatters, automation servers, git-hooks, and security validations. Spoiler alert, they obviously made the development process more efficient and secure. As a whole the book is amazing and the information given throughout the journey is useful, up-to-date, and empowering.
I really liked the content of this book. It’s very instructive. Authors supports their arguments with lots of real life examples which is both inspiring and admirable.
However I really don’t like couple things about the book as well. Let’s start with fonts. They are too small for me to easily follow sentences. My astigmatism is not helping either. I’d appreciate to have 2 volume series with more readable fonts.
The language of the book is too complicated. Even though I have some prior context as a software developer, time to time I found hard to follow up the jargon of the book. Especially the abbreviations. Sometimes I even forget where they were originally given if they have been given. It would be nice to have them in place repeatedly so that we are not distracted by the action of searching them.
Those being said, I think this is still a very valuable addition to my library. I’d definitely revisit it time to time. However let me put it honestly, it’s not an easy read if you want to read it cover to cover. It’s one of the reference book that you would like to revisit it again.
Although terms like CI and CD are the standard nowadays, I'm sure that most who use them don't know why they do so. That's why I think everyone who works in the IT industry should read it. Commonly available tools are not the "things" that make DevOps culture so effective. It requires a mindset shift at every level of an organization. What I also like is the fact that the book is totally technology agnostic. While the author mentions a few tools, those are just examples of implementation. The book doesn't promote any tool-specific functionalities.
Even though I'm the guy who loves examples, use cases, and so on, I was tired of them. I'm aware the context is essential but, come one. Sometimes I felt that I was reading over and over the same story. I'm pretty sure that the author could get rid of one-third of the examples without any loss. What also annoyed me was the formatting. I couldn't find the pattern of why the author starts a new paragraph when the sentence is related to the previous one.
To sum up, while I love the content and I will advise to ready it by every single fellow from IT, I won't force myself to get through the book ever again.
Must read for everyone involved in software development: devs, ops, QAs, project managers, etc., as DevOps is a culture, mind-changing culture, so everyone in software development process should understand what it is about and embrace it. Having dedicated DevOps team in the company doesn't necessary mean that you have taken most of DevOps practices, as DevOps is more than just a dedicated team, it is transformation of the entire software development process, from which every participant can gain a benefit: people, teams and entire organisation.