What do you think?
Rate this book
DevOps for Dummies
Today's fast moving world makes DevOps essential for any business aspiring to be agile and lean in order to respond rapidly to changing customer and marketplace demands. DevOps helps you achieve continuous Delivery of software-driven innovation. This book helps you understand DevOps and how your organization can gain real business benefits from it.
40 pages, Paperback
First published January 1, 2014
11 people are currently reading
143 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 - 17 of 17 reviews
June 12, 2015
Quick overview of devops. Marketing for IBM and ils devops usage and tools.
I liked the myths and facts chapter as a good reality check about devops in the enterprise.
I liked the myths and facts chapter as a good reality check about devops in the enterprise.
August 23, 2015
The book basically tries to sell you the idea "DevOps" will solve most of your enterprise problems as well that you could get rid of them by buying a bunch of proprietary software from IBM.
July 20, 2020
Implementar metodologías dentro de una organización preocupa por la inversión y la posibilidad de que el método de trabajo no sea el adecuado para el perfil del proyecto. Perder dinero siempre va a preocupar. Mientras respiro por alguna razón estoy perdiendo dinero. Dinero imaginario que pudiera invertir en otras iniciativas imaginarias.... (((pánico)))
SIN EMBARGO, situémonos en un ambiente aislado, protegido, donde el valor del aprendizaje y la mejora continúa sea más precioso que lo demás, entonces es momento de practicar el método DevOps. Está basado en metodologías LEAN centradas específicamente en la gente: gente que desarrolla soluciones y servicios para los productos que la gente va a consumir. Me resulta muy coherente el enfoque.
Este tiraje es una excelente alternativa para empezar y quizá después dar atención a grandes obras como:
* LEAN
* El proyecto Phoenix
* Speed
Para amarrar la filosofía de colaboración bajo la cultura de DevOps.
SIN EMBARGO, situémonos en un ambiente aislado, protegido, donde el valor del aprendizaje y la mejora continúa sea más precioso que lo demás, entonces es momento de practicar el método DevOps. Está basado en metodologías LEAN centradas específicamente en la gente: gente que desarrolla soluciones y servicios para los productos que la gente va a consumir. Me resulta muy coherente el enfoque.
Este tiraje es una excelente alternativa para empezar y quizá después dar atención a grandes obras como:
* LEAN
* El proyecto Phoenix
* Speed
Para amarrar la filosofía de colaboración bajo la cultura de DevOps.
October 30, 2016
After reading that book, I improved my understanding of DevOps.
I’d say that DevOps is like a Scrum where all stakeholders are in "one team". Scrum with optional service virtualization and (other) cloud-based tools. I’ve learned that the DevOps is not about daily builds. It can be done in a 4 weeks sprints.
Yet...
With that book you can play in a "Bullshit bingo", crossing the cliche slogans:
* continuous improvement - (like in Scrum, CMMI, .., and many other approaches.)
* speed of delivery
* agile
* lean
* effective
* efficient
* …
Also:
1. Some statements are so trivial, I wonder why they are in use. For example:
* teams with common goals works better.
* The goal of DevOps is to deliver value faster and more efficient - as many DevOps alternatives. You can replace “DevOps” word here with most of known and unknown approaches. … Because so far, not too many IT companies go with a "slow food" strategy.
2. Some statements are open for the speculations. For example:
"IBM survey of the industry found that only 25 percent believe that their teams are effective"
* 25% from 2 DEVelopment and 2 OPerationS members? And what was the question(s)? "Do you believe that your team Can work better"?
3. Some slogans can draw a different picture, when you link them. For example:
Chapter 1 "rapid delivery of innovation require DevOps"
and
Chapter 7 "myths may have originated in companies and projects that tried and failed to adopt DevOps".
If the companies and projects still exist - then the “require” is optional.
What’s more, I found:
1. (Not very) hidden advertisements and sales of IBM (Hardware & Software) tools & solutions. When there are some other tools on the market which "do the job" for years already. Like Octopus (source: Octopus.com) for builds.
2. "Enhanced customer experience and loyalty" slogan (most probably) means that customers will need to report bugs. And maybe even confirm that they are fixed.
(Or just move and use solution from competitors.) It means that Customers will be treated as a beta testers. (For example in A / B testing approach.). Where some Customers will be an Unwilling beta testers. (As I am for the xBox - see story below.)
"Customer experience builds customer loyalty" - if it's like with xBox or few crappy Apple updates, I'd say it's not. With 2 examples:
A) Enterprise Software - Dev team delivered 3 versions a week. And 1 major release per 3-6 months. Also a bit better tested & fixed. Many end users, who reported bugs, claimed that they will use only major releases or will use the competitors with one yearly release. I no longer work with that product(s).
B) New xBox (One S) ( game console ) - within first 2 weeks it was updated every 2nd day. It took every time up to 1h. During the update - I could not use the console.
Yet after...
There was no any visible benefits of any update. No any sign of "Added value" for me. No any extra functionalities. No any new “colors”.
Yeh. There are some noticeable changes
- now xBox hangs more around user login functionality and during the game play. (So maybe it’s an improved security. I hope.)
- now, every time I run a game, I see a 5 sec image animation of "Microsoft Solutions" words. And sometimes I think that they do want me to hate them even more (for that). Why did they stop on that - they could show the logo of MicroSoft permanently in the corner. Or even better - make it as a water sign, displayed permanently. On entire screen. I'm sure gamers will remember about the manufacturer. When there will be a time to decide what (not) to use.
(BTW: Every time I see a big logo, I remember about old computers, where you had a manufacturer's name for 2-5 sec shown. So the end user remembered. Now I remember not to use any of those time-wasters. )
Yeh... As for the updates I do not want xBox to run 24/7 for the sake of automatic updates. Not only because of ecology and electricity bills. But also because "Big brother" can use the kinect to spy on us. Plus I've tested it for couple of days - and it asked me for restarts and agreements anyway. So there was no any (noticeable) time saving benefits.
And for a fresh bugs - I searched for a workarounds online. That builds an impression of under tested product. Product I would not be able to recommend.
That is why, so called "Shift left" (testing) approach, probably could be read, by some customers, without first "f".
As a customer, I like the 1 - 2 major releases per year more than 50 updates a month.
DevOps dream of Continuous Delivery (with Continuous integration; Continuous testing; Continuous planning; etc.) can be perceived as a nightmare. With lots of wasted end users time.
Yet here cost of (Customer) feedback is exported ...on a customer... So it can be treated as a saving for a project budget. Because it’s harder to count users who abandoned the product.
Anyway, I was happy to read that book, to make my impressions:
1. DevOps is so good - it can heal the nearly dead companies and projects. (In iterations alike Scrum, Kanban, … )
2. Behind DevOps approach you may find a lot of agile conversations and chats (some treating as a ChatOps approach). (Which is great to combine with a classic “Agile Manifesto”)
3. As a professional tester, test automation (checks automation) will play a critical role in that approach.
All in all:
1. that solution can be good. It was fun to read that Netflix adopted it as a “NoOps”. With a big corporate success, regarding “shift left”.
2. The company I’m working in now, plans to implement that approach gradually.
3. Yet even after reading that book I have doubts.
Not only because of the “Bullshit bingo”, Sales Slogans and (areas open for the) Speculations. But because now I know that IF there are “Those who tried and failed to adopt DevOps” THEN it's their fault.
I’d say that DevOps is like a Scrum where all stakeholders are in "one team". Scrum with optional service virtualization and (other) cloud-based tools. I’ve learned that the DevOps is not about daily builds. It can be done in a 4 weeks sprints.
Yet...
With that book you can play in a "Bullshit bingo", crossing the cliche slogans:
* continuous improvement - (like in Scrum, CMMI, .., and many other approaches.)
* speed of delivery
* agile
* lean
* effective
* efficient
* …
Also:
1. Some statements are so trivial, I wonder why they are in use. For example:
* teams with common goals works better.
* The goal of DevOps is to deliver value faster and more efficient - as many DevOps alternatives. You can replace “DevOps” word here with most of known and unknown approaches. … Because so far, not too many IT companies go with a "slow food" strategy.
2. Some statements are open for the speculations. For example:
"IBM survey of the industry found that only 25 percent believe that their teams are effective"
* 25% from 2 DEVelopment and 2 OPerationS members? And what was the question(s)? "Do you believe that your team Can work better"?
3. Some slogans can draw a different picture, when you link them. For example:
Chapter 1 "rapid delivery of innovation require DevOps"
and
Chapter 7 "myths may have originated in companies and projects that tried and failed to adopt DevOps".
If the companies and projects still exist - then the “require” is optional.
What’s more, I found:
1. (Not very) hidden advertisements and sales of IBM (Hardware & Software) tools & solutions. When there are some other tools on the market which "do the job" for years already. Like Octopus (source: Octopus.com) for builds.
2. "Enhanced customer experience and loyalty" slogan (most probably) means that customers will need to report bugs. And maybe even confirm that they are fixed.
(Or just move and use solution from competitors.) It means that Customers will be treated as a beta testers. (For example in A / B testing approach.). Where some Customers will be an Unwilling beta testers. (As I am for the xBox - see story below.)
"Customer experience builds customer loyalty" - if it's like with xBox or few crappy Apple updates, I'd say it's not. With 2 examples:
A) Enterprise Software - Dev team delivered 3 versions a week. And 1 major release per 3-6 months. Also a bit better tested & fixed. Many end users, who reported bugs, claimed that they will use only major releases or will use the competitors with one yearly release. I no longer work with that product(s).
B) New xBox (One S) ( game console ) - within first 2 weeks it was updated every 2nd day. It took every time up to 1h. During the update - I could not use the console.
Yet after...
There was no any visible benefits of any update. No any sign of "Added value" for me. No any extra functionalities. No any new “colors”.
Yeh. There are some noticeable changes
- now xBox hangs more around user login functionality and during the game play. (So maybe it’s an improved security. I hope.)
- now, every time I run a game, I see a 5 sec image animation of "Microsoft Solutions" words. And sometimes I think that they do want me to hate them even more (for that). Why did they stop on that - they could show the logo of MicroSoft permanently in the corner. Or even better - make it as a water sign, displayed permanently. On entire screen. I'm sure gamers will remember about the manufacturer. When there will be a time to decide what (not) to use.
(BTW: Every time I see a big logo, I remember about old computers, where you had a manufacturer's name for 2-5 sec shown. So the end user remembered. Now I remember not to use any of those time-wasters. )
Yeh... As for the updates I do not want xBox to run 24/7 for the sake of automatic updates. Not only because of ecology and electricity bills. But also because "Big brother" can use the kinect to spy on us. Plus I've tested it for couple of days - and it asked me for restarts and agreements anyway. So there was no any (noticeable) time saving benefits.
And for a fresh bugs - I searched for a workarounds online. That builds an impression of under tested product. Product I would not be able to recommend.
That is why, so called "Shift left" (testing) approach, probably could be read, by some customers, without first "f".
As a customer, I like the 1 - 2 major releases per year more than 50 updates a month.
DevOps dream of Continuous Delivery (with Continuous integration; Continuous testing; Continuous planning; etc.) can be perceived as a nightmare. With lots of wasted end users time.
Yet here cost of (Customer) feedback is exported ...on a customer... So it can be treated as a saving for a project budget. Because it’s harder to count users who abandoned the product.
Anyway, I was happy to read that book, to make my impressions:
1. DevOps is so good - it can heal the nearly dead companies and projects. (In iterations alike Scrum, Kanban, … )
2. Behind DevOps approach you may find a lot of agile conversations and chats (some treating as a ChatOps approach). (Which is great to combine with a classic “Agile Manifesto”)
3. As a professional tester, test automation (checks automation) will play a critical role in that approach.
All in all:
1. that solution can be good. It was fun to read that Netflix adopted it as a “NoOps”. With a big corporate success, regarding “shift left”.
2. The company I’m working in now, plans to implement that approach gradually.
3. Yet even after reading that book I have doubts.
Not only because of the “Bullshit bingo”, Sales Slogans and (areas open for the) Speculations. But because now I know that IF there are “Those who tried and failed to adopt DevOps” THEN it's their fault.
June 26, 2018
This short introductory primer on DevOps (3rd edition is only 75 pages) is published by IBM and often distributed for free. It is helpful for answering high-level questions about what DevOps is (and what it is not) and introducing basic terminology and concepts.
The book is skimpy on details when it comes to implementation strategy and tools. The IBM case study chapter should come with a warning that IBM is trying to market its tools.
I was recently chagrined in a meeting when I was unable to adequately articulate the difference between Agile and DevOps at our company, so I downloaded this book to get myself up to speed on these concepts. The book accomplished exactly what I was hoping for.
The next task will be to figure out ways to apply what I have learned in a complex multinational environment.
The book is skimpy on details when it comes to implementation strategy and tools. The IBM case study chapter should come with a warning that IBM is trying to market its tools.
I was recently chagrined in a meeting when I was unable to adequately articulate the difference between Agile and DevOps at our company, so I downloaded this book to get myself up to speed on these concepts. The book accomplished exactly what I was hoping for.
The next task will be to figure out ways to apply what I have learned in a complex multinational environment.
January 25, 2018
At 63 pages, this isn't really a book. It's more of a brochure for IBM services that is supposed to give an overview of DevOps. What it manages to do is repetitively pass off poorly written jargon as information.
A point to remember from page 11:
"DevOps helps to reconcile these competing perspectives, helping teams collaboratively establish business goals and continuously change them based on customer feedback thereby improving both agility and business outcomes."
Most sentences in the book are similar to this run-on mess, with "lean" and "agile" showing up so often that the text feels like it has been packed for search placement. This book will not give you even a basic handle on DevOps is. It's simply an ad that's trying to be clever.
A point to remember from page 11:
"DevOps helps to reconcile these competing perspectives, helping teams collaboratively establish business goals and continuously change them based on customer feedback thereby improving both agility and business outcomes."
Most sentences in the book are similar to this run-on mess, with "lean" and "agile" showing up so often that the text feels like it has been packed for search placement. This book will not give you even a basic handle on DevOps is. It's simply an ad that's trying to be clever.
May 14, 2019
Some may find it a brochure from IBM to cell their DevOps toolchain, which might solve all your problems. However, as a begineer, I learned a lot from it. I personally liked the design of the book, which doesn't give it a look of a technical guide. The tips, remember, warning and technical stuff icons are best designed, which helps to remember them easily. A must read if you want to get started with DevOps.
Read
March 8, 2019I would like to explore the things about DevOps :)
February 24, 2021
Nociones básicas y necesarias sobre una tendencia en las organizaciones que van por una transformación digital.
December 30, 2021
Basic approach and intro to DevOps.
Compliment with other literatures on net and trainings on linkedin or udemy to get a more wholesome understanding.
Compliment with other literatures on net and trainings on linkedin or udemy to get a more wholesome understanding.
December 3, 2022
Good 30k ft overview to explain what and a small piece of why. Appears to be summed at upper management but the arguments presented are too thin to make the case.
December 24, 2015
Good introductory overview of DevOps.
November 19, 2015
Very good overview. Everyone doing DevOps should at least understand the basics and the reasoning behind it imo... this covers it. Just ignore all the Big Blue stuff.
Want to read
August 15, 2016I am interested to achieve some certificate on DEV OPS. I would like to read this book to get an idea how dev ops works
Thanks,
MAruf
Thanks,
MAruf
February 28, 2015
Short overview of Devops
July 26, 2015
it nice and you will bet basic knowleddge of devops. but he mentioned everywhere the IBM products.
April 9, 2017
Read this with my team at work and discussed in a book club. The book is short and easy to read, so it was a fun way to share ideas about how this change impacts us.
Displaying 1 - 17 of 17 reviews