Here is a list of things:
- Summiting Mount Everest
- Memorizing Pi to two-thousand digits
- Reading a Thomas Pynchon novel with complete comprehension
All of these things I feel more confident about than defining DevOps. Dylan Smith is a braver man than I, so he published a piece giving it a shot. Like all things DevOps, I’m sure many will disagree, but it might just be broad enough to be acceptable. Just because it’s broad, doesn’t mean it’s inaccurate. There’s a deceiving simplicity to it, as evidenced by the solutions to some of the conflict inherent in DevOps. For a seemingly impenetrable topic, Dylan makes a concise and coherent case. I won’t spoil his overall point, so give it a read if you’re interested.
Western Devs comments:
As with any pipeline, there is likely a bottleneck somewhere that restricts the flow of value. Lean is all about identifying and attacking these bottlenecks. 10 years ago – before Agile – the bottleneck was probably Analysis, or maybe Test. With Agile development becoming mainstream over the last decade, it has done a pretty good job of attacking those bottlenecks, resulting in analysis and test becoming more just-in-time, spread out over the course of a project, and embedded in the regular dev workflows. They are no longer the bottleneck.
A new bottleneck has arisen, that is at the boundary of the dev/test team and the operations team. These tend to be very separate teams, with a clear handoff between them. This results in friction, and a bottleneck in the flow of value.
—
If you want help adopting DevOps practices or technologies, my company Imaginet is always happy to help. Check out our DevOps offerings here: http://bit.ly/2gzHtvY
Read more at: What Is DevOps?
