Understanding DevOps | What is DevOps?

DevOps is a widely used term, but people interpret it differently. What does it mean and what does it really take to implement DevOps and Continuous Delivery? Ideas like DevOps Pipelines (Deployment Pipelines) implementing the core technical practices of Continuous Delivery, Continuous Deployment, Continuous Integration and DevOps automation are at the heart of this approach, but to achieve the goals of DevOps, and software development in general, it helps to extend the range beyond the technical and to think about how DevOps can improve software development more widely.
There are core ideas that describe DevOps best practices that are profoundly important to the success of a software development project. DevOps training and DevOps tutorials often focus on the relationship between “Developers” and “Operations”. This is inevitable since that is what the name “DevOps” says, but it is misleading. DevOps is a much bigger subject than that, and much more important to the success of a software project than only this relationship.
---------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original award-winning “Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
--------------------------------------------------------------------------------------
If you want to hear about new CD and DevOps courses, being released every 2-3 months, regularly check our CD.Training site ➡️ bit.ly/DFTraining
Keep up to date with the latest discussions, free "How To..." guides, events and online courses through our email updates! Follow the link for the details ➡️ bit.ly/MailListCD
---------------------------------------------------------------------------------------
Continuous Delivery Ltd. ➡️ bit.ly/ContinuousDeliveryDF
Dave Farley's Blog ➡️ bit.ly/DaveFWebBlog
Dave Farley on Twitter ➡️ bit.ly/DaveFTwitter
Dave Farley on LinkedIn ➡️ bit.ly/DaveF-LI
----------------------------------------------------------------------------------------------------------------------
Useful Books on this topic:
(Please note, if you buy a book from these links I get a small fee, without increasing the cost to you)
"Accelerate, The science of Lean Software and DevOps", by Nicole Fosgren, Jez Humble & Gene Kim
➡️ amzn.to/2YYf5Z8
"The Phoenix Project", by Gene Kim
➡️ amzn.to/3csuuop
"The DevOps Handbook", by Gene Kim, Jez Humble, Patrick Debois & John Willis
➡️ amzn.to/2LsoPmr

[@ContinuousDelivery]

Is DevOps the correct term for what we're actually doing?

[@abhilashbandi3866]

So glad I can learn from a veteran. You started working on software before I was born. Massive respect and thanks for opening this channel to help out others. I am glued to your channel.

[@prashanthb6521]

Very good explanation sir, One guy one day saw me soldering my broken motherboard and asked me "How's your DevOps going?" Another guy saw me setting up my monitoring server and called it DevOps.

[@Squeeeez]

Another DevOps interpretation - management wants the dev guys to be on call 24/7. (Loved the pink devops clouds by the way!)

[@stephanklein257]

Hi Dave - having watched a couple of your clips, I was eagerly awaiting your conclusion right from the beginning, and wasn't disappointed in the end. ;-) Most companies I know of try to adopt agile SW dev priciples by focusing on the "development - test - deployment" part, and not taking the organisational and conceptual aspect into account. This happens in my observation often deliberately, so management doesn't have to bother with "this agile thing". So while the term "DevOps" can be interpreted to support that very limited perspective of "optimisation on working level Agile", so can IMHO "CD". I think it's not so much a question of terminology, but of the willingness to approach new ideas and working styles, and follow through with them. That being said, I wholeheartedly agree with your assessment - the core principles of CD and DevOps are pretty comparable, if not identical. Your work and your channel are much appreciated, thanks for making the effort !

[@ContinuousDelivery]

Thank you, y4es, this is stuff that "leaks out" you can't really put this sort of thinking in a "development team only" box.

[@zacnavein7558]

That is an interesting point of view. There are so many interpretations. For me DevOps is something similar to SRE (to some degree). DevOps manage the operation(OPS) side by developing(DEV) tools and automating processes for infrastructure, monitoring, deployment etc. The main idea behind DevOps is reducing duplications and manual work.

[@rajadas6432]

Very profound and quality discussion. Apart from few companies due to 'quality of leadership' leaders simply run after the buzzwords. Leadership picks some buzzword from market (without understanding the context, philosophy, values and principles) and start practicing the tools/practices. This approach don't solve any real problem. Only park the problems under the rug. If we have to fix the problem, first we have ask ourselves, how can we have right people at right place, starting from top!!

[@kjelltillstrand994]

I once did a poll on the subject of CD, DevOps and the if one was a subset of the other in a consultancy firm I worked in at the time. Over all the result was pretty even. Junior consultants leaned on CD being a subset of DevOps, more senior ones had it the other way around. The most senior ones however, pretty much put an equality sign between the two. The last few years I feel that continuous delivery as a holistic approach have been reduced to a technical pipeline and as such is missing the cultural, organisational and other important aspects. For me it really doesn't matter as long as I can help create high performing teams and organisations using continuous delivery by calling it DevOps.

I refer to myself as DevOps, because I can do, and do, all of those things myself. I write the code, I add instrumentation for monitoring, I write the deployment and test pipelines and I build the development, testing and production environments. That being said, I work on rather small projects, which is obvious from the fact that I have time to do everything alone. I do feel that the term loses its meaning when talking about larger teams, in which case it is only really useful when used to describe an individual's competencies.

[@DheerajBhaskar]

Nitpick - Too much echo in audio Amazing content

[@abedjarjanazy1178]

agree ++

[@MathieuBosi]

I have the impression that the audio from the camera microphone might have been (accidentally?) used. The clip / lavalier microphone should be much more directional and greatly mitigate room acoustics effects.

[@garyfry7292]

Great to hear a voice of seasoned experience! I'm grateful that you've consolidated so much experience into a book which has clear principles. That said, it sounds like you're fishing for a revised version of your book? Would it be rude to consolidate your views into a single word? Collaboration. The inclusion of all stakeholders at the earliest possible stage provides an opportunity to think in advance about how their role can contribute towards a successful delivery. Then it's possible to prioritise additional technical and business requirements. Having a pragmatic mindset should consistently provide maximum business value every step of the way. Beware of trolls! Thoughts?

[@ContinuousDelivery]

Thank you! I am not fishing for a revised version of "Continuous Delivery", but I think that the ideas are important and am, with this channel, hoping to help promote them more. I like your word, collaboration is important to lots of this stuff, but I have a word that I think is more important, Science, we need to start using a more scientific-rationalist approach to solving problems in software. That often relies on deep, effective collaboration, but I think it goes beyond that and helps in many more ways than collaboration alone. I now believe that CD represents a genuine engineering approach to SW development, and is important, and works, for those reasons. I am working on another book, but it isn't a re-write of CD, it is about SW Engineering and what that idea means, or should mean in my opinion. Thanks for your comments.

[@garyfry7292]

@@ContinuousDelivery thanks for your thoughts there Dave. There's another word which we haven't talked about and that's pragmatism. Collaboration gives you better science, as more perspectives can be measured. That's where pragmatism works best. Forgive me for adding another word here. Value. Would it be way off for me to suggest collaboration helps increase insights, and therefore better inputs for science/measurements, which feeds into better pragmatism, and therefore increase value by balancing risk and reward? I rely on my experience and gut, and the experience and gut of others, more than what opinionated books have taught others as the truth. I can't back up my feelings with science, which is what the world cries out for. Thanks for the science! If you need some input, I might be able to help more than you think

[@ContinuousDelivery]

I agree that pragmatism is a key attribute of good developers, and engineers. I think that we have to be careful what we mean though. Everyone thinks of themselves as pragmatic. But I may think of myself as a pragmatist and you may think of me as careless or slap-dash. It is hard to draw a line. This is one of the reasons that I think that adopting a more scientific approach, albeit a light-weight one, guides us better to appropriate levels of pragmatism. If I make progress as a series of experiments, where I have a hypothesis, measure, control the variables and make decisions based on evidence then I can manage my pragmatism and make fast efficient progress, but not at the cost of reducing quality, which can be a risk for some types of pragmatist I think. Dave

[@garyfry7292]

@@ContinuousDelivery Thanks for responding again Dave. I agree with all of that. So we're kinda saying the same thing. Just to make my point a bit clearer, Continuous Delivery, DevOps, TDD, Agile / Scrum / Kanban are all best-practice disciplines / philosophies in their own right. We shouldn't be slap-dash with any of that, so it stands to reason that pragmatism needs to operate in a disciplined in intelligent framework too. Just to me clear, pragmatic can be defined as "Dealing or concerned with facts or actual occurrences; practical" Gathering data is correct. Dealing with facts sometimes requires greater collaboration in order to obtain the information you need. Software Engineering best practices, tools, attitude, capability, talent, measurement, agility, etc, are all there for many reasons: Deliver "Maximum Business Value". React to change faster. Release faster. Sometimes fail faster, so we can learn faster, reduce CCTL, rollback faster if the code cant be fixed quickly enough. Keep code quality high (with various types of testing at various layers). All of this reduces the risk of failure, so if anyone is professional enough to understand that, and are generally good citizens, how could they be possibly be perceived as careless or slap-dash? That said, the world is ever-changing, and the rate if change is ever-increasingly. It's a lack of experience in shiny new technologies (or bugs which have been introduced in the next version of them) that always seem to unexpectedly bite us engineers in the backside, no matter how many years of experience we have under our belts. Maybe we also need to measure failure rates broken down by reason, if that's not being done already. It might me an eye-opener. -Open source library version changes - Bare-metal OS version upgrades - Infrastructure-related version upgrades (eg K8S, Docker, Artifactory) Thoughts? Gary

[@ContinuousDelivery]

I think we are on the same page! There is a good study of "Causes of Production Failure" here: www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf Which makes for interesting reading. "70% of production defects are as a result of the common mistakes that programmers make in all languages, simple testing can eliminate these failures." My experience is that you can gain WAY more than 70% reduction with the kind of approach that I recommend.

[@rogierkien]

Good story. I do however wonder where UX fits in (See video at 9:30) or is this just a matter of name convention? (iterative/product design)

[@user-do4dp3ce4v]

I am leaving thumbs up

[@tj71520]

How does one begin learning CD from scratch? Btw. your channel is a life saver.

[@perumalperumal4808]

Excellent explanation on DevOps, but what about SRE? How are they different? Agile, Scrum, DevOps, SRE, TDD, BDD, DDD...too many buzzwords really confuses starters like me

[@ContinuousDelivery]

Thanks for the suggestions.

[@gavincrouch]

As a Sysadmin, I also get referred to as DevOps (somewhat annoying). DevOps is a process (development life cycle), not a role. (in my view.)

[@dennislindqvist5461]

This didn’t touch the subject very well from the infrastructure side. In many organizations, Ops is separated from development. Why should Ops care about DevOps if they can continue practice pure ITIL with slow but “safe” processes instead?

[@porky1118]

I might have heard the term "DevOps", but I don't know, what it means and also never used it.

[@WayneMunro]

Just Dev

[@MegaAnufriev]

Devops is just a poor name for what it covers. Continuous delivery makes more sense.

[@ContinuousDelivery]

Agreed :) I think that names can help and DevOps not only lacks clarity, it is actually misleading in what it describes. It is either too simple, which it is not, or it is a much bigger idea that has more power when recognised for what it is - an ability to continuously deliver software repeatably, reliably and sustainably. I think that if you take that interpretation then CD really covers what we are talking about. I almost wish that I hadn't helped to popularise the CD term, because then it wouldn't sound self-serving when I argued for it.

[@edwardcullen1739]

I've long seen DevOps as a smart marketing term to backdoor the concept of Software Engineering, without actually using the words. Software Engineering, as a term, seems to be a massive turn-off to management types...

[@marna_li]

I do think that most times someone want a "DevOps engineer" they just want a System Administrator with some special qualifications. Perhaps they will be part of a DevOps Team but dedicated to certain projects to build an maintain CI/CD pipelines. But do you need a dedicated role that is standby for that? Developers should be able to do that. Just like Agile has been misunderstood, I think the same goes for DevOps. They are confusing and assumed process and tools for the philosophy: Completely missing the point of it.