Other Sellers on Amazon
+ $3.99 shipping
+ Free Shipping
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win Paperback – Illustrated, February 27, 2018
|New from||Used from|
The Amazon Book Review
Book recommendations, author interviews, editors' picks, and more. Read it now.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Frequently bought together
From the Publisher
The Three Ways of DevOps
The First Way of DevOps emphasizes the performance of the entire system, not a specific silo or department. The focus is placed on all business value streams that are enabled by IT. It begins when requirements are identified (the business or IT), are built (Development), and then transitioned into production (Operations).
The Second Way of DevOps creates right-to-left feedback loops. The goal is to shorten and amplify feedback loops so that necessary corrections can be continually made. The Second Way facilitates understanding and responding to all customers, internal and external, and embedding knowledge where it is needed.
The Third Way of DevOps encourages the creation of a culture that fosters continual experimentation (taking risks and learning from failure) and understanding that repetition and practice is the prerequisite to mastery. Practicing the Third Way of DevOps allocates time for the improvement of daily work, creates rituals that reward the team for taking risks, and introduces faults into the system to increase resilience.
Gene Kim: Looking Into the Future
The problems that DevOps solves are at the center of what every modern organization is facing. When The Phoenix Project was first published in 2013, DevOps was primarily used in internet companies. Now, it has been amazing to see these principles and practices in large, complex organizations across every industry vertical. Now more than ever, technology is not just the nervous system of an organization—it actually composes the majority of the muscle mass. Without a doubt, the best times for technology are ahead of us, not behind us. There’s never been a better time to be in the technology field and to be a lifelong learner.
About the Author
Gene Kim is a multi-award winning CTO, researcher, and author. He is the founder of Tripwire and served as CTO for thirteen years. His books include The Phoenix Project, The DevOps Handbook, The Visible Ops Handbook, and Visible Ops Security.
Kevin Behr is the founder of the Information Technology Process Institute (ITPI) and the general manager and chief science officer of Praxis Flow LLC. Kevin has 25 years of IT management experience and is a mentor and advisor to CEOs and CIOs. He is the co-author of The Phoenix Project and The Visible Ops Handbook.
George Spafford is a research director for Gartner, covering DevOps, technical change, and release management, in addition to the use of bimodal IT and the pace-layered application strategy. His publications include hundreds of articles and numerous books on IT service improvement, as well as co-authorship of The Phoenix Project, The Visible Ops Handbook, and Visible Ops Security.
- Item Weight : 1.05 pounds
- Paperback : 432 pages
- ISBN-10 : 1942788290
- ISBN-13 : 978-1942788294
- Product Dimensions : 6.05 x 1.17 x 8.99 inches
- Publisher : IT Revolution Press; 5th Anniversary Edition (February 27, 2018)
- Language: : English
- Best Sellers Rank: #2,741 in Books (See Top 100 in Books)
- Customer Reviews:
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
DevOps is this mythical assembly line of progress that gets code from point A to point B in record time, and by record time, I mean no time. Coded, auto-tested, out the door, bing, bang, boom. The book was an entertaining read (and/or listen) and the authors cleverly couch the concepts of DevOps into a story about a failed delivery system (The Phoenix Project) built ala WaterFall, versus a new system hastily assembled (heh, see what I did there?) on an impromptu assembly line and delivered in record time, performing brilliantly - when compared to the failed behemoth Phoenix Project.
So... here's the problem with DevOps, and the problem with this book.
Companies with a nightmarish legacy code base (delivered or not as-of-yet out the door) that are attempting to build DevOps are using the same people that created their behemoth nightmare in the first place. As does the company in the hypothetical story in the book. Worse. The CEO in the book is a horribly bad boss, making wrong decision after wrong decision (I am sure to ramp up the tension to illustrate the saving graces of DevOps). So, I can tell you definitively that ANY company with leadership like that would lose their brilliant techs almost immediately. The market is in desperate need of brilliant techs so there is zero possibility that they are going to stick around a cess pool of politics when they can get a signing bonus and a raise from a company already doing it better and faster, and all without the drama. I'm just saying. And in order to pull off a DevOps operation, you absolutely need brilliant techs. You need tight, well executed product code with sufficient testing hooks so you can automate as you go. So you need brilliant QA that can understand and/or code the hooks right along-side the devs.
In short, you need a whole lot more than a single Brent. You just do. And to imagine that there are a room full of brilliant techs writing broken down shoddy bloated code for Phoenix, but then can turn around and write the brilliantly architected code you need for the DevOps project... well... I am able to suspend belief when called upon, but this was more like taking it out back, shooting it, and burying it six feet under. I'm just sayin'.
And with that being said, I am a huge, ginormous fan of DevOps (and the book was a FUN read / listen, thus the 4 stars instead of 3). It just takes an incredible talent pool to pull DevOps off and books like this makes companies think they just have to implement this process with the talent they have and poof! instant quality software that can be delivered instantaneously! Woohoo! <sighs> They would be better served facing the reality of the mess they have, caused by (possibly) a lack of reasonable process, yah, but almost certainly by lack of talent as well. That's basically how they got where they got.
Off soap box now. Doing the tango. Eating Oreos. Feel free to join!
One of the best parts of the book was actually after the fictional plot ended, and the authors took the extra time to collect the concepts presented and revist them in a brief summary at the end. I hoped for this, as going back through The Phoenix Project to find each in turn, and learn more would have been difficult. If I could suggest to the authors an improvement, it would be to break the 4th wall during the fictional telling of the plot, and provide footnotes or references to the reader referencing where in the summary section they can read a bit more about a given concept. Nothing would be lost by this approach, as the reader quicky realizes the point and purpose of the plot anyways.
Overall, The Phoenix Project provides an easy way for non-business people to get their feet wet with process improvements, without making the explanations and concepts too burdensome. I find myself quoting passages with co-workers who've also read the book, realizing that all too many of the scenarios presented are real life problems we face everyday (though perhaps less severely than in the Phoenix Project.) As such, I know I've already taken something away from the book, even if I won't have a chance to master every improvement, or even experiment with them all. It provides a new way of thinking about software development, and all the organizations it impacts. Four stars.
Top reviews from other countries
With these realistic problems that no doubt face most of us the Pheonix Project lays out a number of tools and approaches that will lead the reader to think "damn, that's a good idea" or "that's an amazing way of looking at it". There's a moment in the book (I got it on kindle first, but now I have a physical copy that's getting the highlighter treatment) where one of the executives more or less goes "well dur well done you've figured it out" to which another goes, "well why didn't you think to explain this to everyone?" we often assume that the obvious is obvious to everyone, it's like a person watching poker on TV who can see everyone's cards going "well that outcome was obvious" clearly it wasn't to the people playing who couldn't see the cards.
All in all this book should be a must-read for everyone in IT or work with IT, it sets out the groundwork for implementing lean principles in IT and I wish I'd read it years ago. To be honest I think anyone with aspirations to help improve workflow through an organisation should read this, and the Goal and then sit down and think about the lessons presented within.
The story follows the life of the newly promoted IT Manager who is tasked with solving these problems and while tackling the issues he learns about DevOps. I found the book itself to be a very entertaining read and the concepts introduced both made sense withing the context of the story and reflect the real world issues a lot of us face as well.
The book does have a somewhat "accelerated" rate of adoption within the company, most real world scenarios would probably take considerably longer and be much more of a struggle with considerable more meeting - however I doubt many people who be enthralled by that. The story pacing certainly benefits from this approach.
The comparisons between IT and a typical manufacturing plant makes understanding the concepts underlying DevOps easier than speaking about them in the usual IT language.
I would definitely recommend this book to anyone who works in an IT / DevOps environment and wants an enjoyable read that also helps with the daily job.
From the frantic mess of the SAN upgrade (apparently) fighting the Payroll run in the opening section (we've all been there, done that, got the tee shirt <that is, if we are to be really honest with ourselves, folks, eh?>), to Brent and his knowledge of everything, with nothing documented.......
I grimaced at the developer who'd had to do a rushed change that broke, gone on holiday, and no-one knew. We all know that one.....
Its a gripping read, though understanding the mindset of Erik the guru is hard at times, and I'd have liked a little more domestic background.
I'm not depressed at all, no I'm fine. Really. Thanks. *inaudible weeping*