devopsy.kinsta.cloud

Tag: the goal

  • Five Great Books on DevOps

    Five Great Books on DevOps

    While the DevOps movement began in earnest in 2009, there are still a lot of questions about what DevOps means, how it’s done, and what the purported benefits of DevOps are. Big questions, for sure. And there are no quick answers. In fact, to thoroughly answer each would require numerous books.

    Which brings us to the question, what are the best books that define DevOps, describe how to operationalize it in the real world, and show what beneficial outcomes one could expect?

    Here are my choices of five great books on DevOps, in no particular order:

    Book: The Phoenix Project

    Authors: Gene Kim, Kevin Behr, George Spafford

    This one is a fictional story, written in engaging novel style, that tells the story of how to apply DevOps to unleash IT’s potential. The story is about Bill, the IT manager at the fictional company Parts Unlimited. Not an exciting business name, but the adventure starts in earnest when on a drive to work, Bill gets the call from the CEO that sets the story in motion.

    The book’s cover description tells it best:

    The company’s new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill’s entire department will be outsourced.

    With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.

    In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again. 

    As one Amazon reviewer put it: “This “parable” of how applying DevOps to pull out of an IT death spiral of delays and defects is an enjoyable read backed with great references and support materials for understanding the principles underlying DevOps. It’s not enough to get you all the way there, but it will get you inspired to start down the path.”

    Book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

    Authors: Jez Humble and David Farley

    This seminal read is all about putting into practice rapidly and consistently delivering new highly-functional software to your users. From the back cover: “Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes-no matter what the size of a project or the complexity of its code base.”

    The book covers automated infrastructure management and data migration and the use of virtualization, and automating creating, integrating, testing, and deploying software, as well as improvement collaboration within the teams.

    As one Amazon reviewer put it, “This is an absolute must read for anyone in software or application development. It is amazing how well the authors capture the real pain points and provide all the information you need to getting to a more effective IT practice.”

    Book: The Visible Ops Handbook

    Authors: Kevin Behr, Gene Kim and George Spafford, IT Process Institute

    This is the first book I ever read on IT process improvement, and it was an eye-opener for me. This book came out about 4 years before the term DevOps was coined, but it nailed the essence of what high-performance IT is all about. And it’s an essential read today:

    Visible Ops codifies how these [High performance enterprise] organizations achieved their transformation from good to great, showing how interested organizations can replicate the key processes of these high-performing organizations in just four steps:

    1. Stabilize Patient, Modify First Response – Almost 80% of outages are self-inflicted. The first step is to control risky changes and reduce MTTR by addressing how changes are managed and how problems are resolved.
    1. Catch and Release, Find Fragile Artifacts – Often, infrastructure exists that cannot be repeatedly replicated. In this step, we inventory assets, configurations and services, to identify those with the lowest change success rates, highest MTTR and highest business downtime costs.
    1. Establish Repeatable Build Library – The highest return on investment is implementing effective release management processes. This step creates repeatable builds for the most critical assets and services, to make it “cheaper to rebuild than to repair.”
    1. Enable Continuous Improvement – The previous steps have progressively built a closed-loop between the Release, Control and Resolution processes. This step implements metrics to allow continuous improvement of all of these process areas, to best ensure that business objectives are met.

    As this Amazon reviewer this had to say, this fall, on the book: “This is the first and foremost required reading on my team! If you are an IT professional, you must read this. It is a concise, powerful expression of how to reinvigorate your operation and become a top performing IT organization.”

    Book: DevOps for Developers

    Author: Michael Hüttermann

    This book is for software developers and engineers that aim to help improve the delivery of software by using lean practices to get apps and software into production.

    From its description:

    DevOps for Developers is for motivated software engineers, particularly programmers, testers, QA, system admins, database admins, both beginners and experts, who want to improve their software delivery process. It’s the perfect choice for engineers who want to go the next step by integrating their approaches for development and delivery of software. This book is for engineers who want to shape their processes and decide on and integrate open source tools and seek for guidance how to integrate standard tools in advanced real world use cases.

    And as an Amazon reviewer put it: “Developers tend to produce updates in short cycles whilst admins prefer a stable system. And if something bad happens, they often start finger-pointing to blame the other side. One solution is to tear down the silos of development and operation. In other words, set up integrated teams.

    This is the core message which Michael Hüttermann would like to stress out. Agile methods and tools might be used for development as well as for deployment and operation. In his book, Michael explains how to do and which (free) tools to use.”

    To be fair, the book has taken dings about not being a programming book, and repeating some of its concepts. But the value in this book is its real-life examples, and explanations as to how different roles on teams in Dev and Ops can work together more collaboratively. It also dives into common pitfalls organizations hit in their journeys of operationalizing DevOps.

    Book: The Goal: A Process of Ongoing Improvement

    Authors: Eliyahu M. Goldratt, Jeff Cox Author, David Whitford (Other Contributor)

    The Goal is the second fictional book in this list. Written more than 30 years ago, it could have been written yesterday. When discussing concepts and systems, many times story is the way to go because the motivations and thought processes of different roles can be discussed in depth and elegantly so. The Goal succeeds in this, and is a must read for anyone who seeks to help be a catalyst of improvement in their organization.

    From the book description:

    One of Eli Goldratt’s convictions was that the goal of an individual or an organization should not be defined in absolute terms. A good definition of a goal is one that sets us on a path of ongoing improvement.

    Pursuing such a goal necessitates more than one breakthrough. In fact it requires many. To be in a position to identify these breakthroughs we should have a deep understanding of the underlying rules of our environment. Twenty-five years after writing The Goal, Dr. Goldratt wrote Standing on the Shoulders of Giants. In this article he provided the underlying rules of operations.

    This article appears at the end of this book.

    Here’s what an Amazon reviewer had to say: “I have often heard myself complaining that companies over complicate the simplest of activities. Measurements do not truly measure the end result and are often held in a high regard by executives. These measurements cause further loss and mask the true issues. This book was fascinating, very “simple” in a sense which lends to making it even more fascinating. I learned a lot about the production aspect of my “department” which would often not be looked as a production department in the literal sense of the word. Thought provoking and inspirational, every leader can benefit from the story told. A must read.”

    I would love to hear from you, what are the most important books on DevOps that you’ve read?

  • DevOps and The Goal

    DevOps and The Goal

    Reading, “The Goal” was a pivotal event in my career.  More than a decade ago a friend of mine who was an operations professor at Georgia Tech told me it was his favorite book.  We were discussing the challenges of getting work done in a corporate environment.  I was grumbling about leading a web dev team in a company that did not embrace the software development discipline.  Already a fan of Tom DeMarco and Timothy Lister’s, “Peopleware”, and being very vocal about the lack of ability to focus whether due to environmental distractions or the constantly changing priorities and schedules, I was receptive to the message in “The Goal”.  It gave me a vocabulary and a roadmap for improving our throughput issues.

    Our throughput problems were a textbook case for development disaster.  When I joined the project, we had three source code repositories, from none of which could we build production and when we did produce a build it would work in pre-production environments but not production (this just slightly predates the widespread acceptance of continuous integration).  We also had the classic inconsistent release cycles that would lengthen based upon insistence by the business owners to include more features.  Looking back, it is not surprising in the least that we were not successful.

    Not surprisingly, these issues led to a lack of trust with the business.  Overcoming the technical problems was straightforward using brute-force tactics.  We addressed the source code problem by recruiting a senior developer and empowering him to make improvements.  We overcame the build quality issue by using a primitive form of agile and enforcing knowledge transfer; the operations engineer sat between two developers during the build and release process and he was the only one allowed touch the keyboard.  Our tactics were basic, and they worked.

    The bigger challenge facing us was getting our business owners to accept a different SDLC model.  We were saddled with a classic waterfall process, each phase being dependent upon the last with a lot of idle time built-in at each phase gate.  The shortcomings of the waterfall process were amplified because the business lacked confidence about when, if ever, they would get a feature released to production. This lack of confidence led to a constant rearranging of the priorities to get the most important feature du jour in the next release.  The constantly changing priorities created even more idle-time and a lot of work-in-progress (WIP) which Goldratt’s Theory of Constraints (TOC) tells us is at the root of inefficiency.

    Using TOC as a guide, we redefined our SDLC from requirements through QA.  We focused on developing a process that de-coupled the phases, reduced idle-time and work-in-progress (WIP).  De-coupling the phases meant the work could queue between each phase allowing the teams, (requirements, development, QA, and operations) to vary independently; they didn’t have to wait on the team before or after to complete their work which reduced idle-time.  We then focused on improving the slowest areas, which seemed to be requirements and deployments.

    We convinced our business owners to trial a monthly release cycle (this was a long time ago, even before continuous integration was widely accepted!).  The monthly release cycle helped give the business confidence that they would see their features in production at an expected pace and it allowed requirements to cycle on schedule independent of development and QA.  Some features would get done in a month and some would span several months.  Over a period of three months we got into a rhythm that worked for about 14 months until organizational focus changed and we focused elsewhere.

    Reading “The Phoenix Project” reminded me about those days and the challenges Goldratt helped us overcome.  I really liked “The Phoenix Project” and many of the situations rang true.  I have since moved from development to operations (twice!) which gives me a unique perspective as I see both sides.  I see DevOps as the embodiment of Goldratt’s ideas in IT; reducing work-in-progress, reducing cycle-time and always focusing on the most constrained processes.  Add a consistent release schedule and it looks a lot like DevOps.  Everyone has their own ideas about what is DevOps and how best to implement, I suggest we follow Goldratt’s advice and focus our efforts where they will have the most benefit.

  • Is DevOps Ready to Cross the Chasm to Mainstream?

    Is DevOps Ready to Cross the Chasm to Mainstream?

    There are just a handful of business books that I have read that have had a profound influence on me.  One was Gene Kim’s “The Phoenix Project”, another was Eliyahu Goldratt’s “The Goal”. A third one was Geoffrey Moore’s, “Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers”.  Even though written in the early 90’s, it is as relevant today as it was then.  Though our technology has changed (dare I say advanced), the adoption curve of who uses it has remained static.

    When I look at the world of DevOps today, to me it is on a classic chasm model.  The real question is will it or rather how quickly will it make the hop over the chasm into mainstream. The picture above is a great representation of the chasm. Most technologies go through the enthusiast period, moving to the visionary.  I would say that DevOps has been in this visionary period for a few years now.

    In order for any technology to jump the chasm it needs to build up enough momentum and critical mass to successfully make the jump.  Now there are some technologies that never build up enough critical mass to successfully jump over to the pragmatist’s cliff of mainstream adoption.

    Back in my StillSecure day’s NAC had a tough time making the jump. It was not until mobile technology and BYOD served as ignitions that NAC made the cross-over to mainstream.  But enough about NAC lets return to DevOps.  For DevOps the Cloud and virtualization have been ignition points.  Using software to replace hardware has allowed for rapid deployment, automation and continuous delivery models that characterize DevOps.

    With so many pundits and analysts predicting that this is the year Cloud goes mainstream (I thought it did already), DevOps will not be far behind. As disruptive as Cloud is, could it be as disruptive if not for DevOps? There is a symbiotic relationship between the two.

    But it is not just Cloud alone. DevOps has other boosters that will help it over the chasm. SDN is another big boost.  Software will eat the world according to Marc Andresseen. It may very well start with networking hardware.  But software is eating more than hardware.

    One of the hottest trends in security (and one you will see featured here in the SecOps neighborhood of blogs on devopsy.kinsta.cloud) is Software Defined Security.  It may sound like marketing speak to you, but it involves putting security right into the virtual, software stack.  It is DevOps for security.  In fact DevOps and security is something you are going to hear more about from the likes of Josh Corman, Dave Mortman and Dwayne Melançon and others.  Their “Rugged DevOps” discussion is ripping through the security industry for the last year or more.

    All of the above aside the real key for DevOps to making the leap is that instead of just enthusiasts and visionaries being involved, what Moore calls “the Pragmatists” get involved.  These pragmatists are not hung up on labels or new versus old.  They just want to get the job done. If DevOps will help them get the job the done, that is good enough for them.

    The pragmatists make up a good chunk of the mainstream market.  The silent majority if you will.  To win these pragmatists over DevOps just has to show that its benefits are real, quantifiable and worthwhile. The good news is that the Pragmatist are the first group on the other side of the chasm.

    Having the Pragmatist as the first part of the mainstream is a good thing, because after that it gets harder to gain traction.  According to the Chasm model after the Pragmatists come the Conservatives.  Though not quite reactionary, this group doesn’t like change. They won’t change until they are nearly forced to by business pressures. They will resist adopting DevOps just because it is different than what they do now.  Generally technology has to be pretty mature, its benefits well established before this group will consider doing anything more than a small trial.  With DevOps representing as much a change in philosophy and culture as it does new tools, this is a really bitter pill to swallow for the Conservatives.

    I would think we are years away from DevOps making real traction into this group. Especially when there are still some folks who claim that DevOps is DOA, DevOps is much ado about nothing, that it is doomed to failure. But hey there are people who still say that the science doesn’t point to climate change and that we should teach creationism in schools.

    Call me the eternal optimist though. I do think that as Cloud and the other catalysts behind DevOps continue to expand, DevOps will be swept up even into the conservative base.

    Between Conservative and Pragmatist, a large slice of the market is spoken for. Added to the pre-chasm market and DevOps is well beyond critical mass.  Whether the last segment of the market, the skeptics ever adopt is not even relevant.  Many of these skeptics have a bone to pick. As I have grown older I am convinced that they are just wired to be skeptics.  They literally look at everything through a half empty glass.

    So there is little doubt in my mind that DevOps will not be a stillborn technological movement. It has the catalysts, the benefits and most importantly timing and circumstances are lined up to help push this from the early adopter crowd and right over the chasm into the mainstream. What’s more is I think this is already under way and will be much quicker than most people think.

    This is all a big reason why we launched devopsy.kinsta.cloud.  There is a big enough critical mass now to support a site dedicated to DevOps like this.  But as we cross the chasm to mainstream, we want to ride the crest of the wave, helping to bring DevOps to pragmatist, conservative and anyone else who would benefit from it.