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.
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.
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.
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.
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 !
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.
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!!
3 года назад+1
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.
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
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?
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.
@@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
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
@@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
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.
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?
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.
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...
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.
Is DevOps the correct term for what we're actually doing?
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.
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.
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.
Another DevOps interpretation - management wants the dev guys to be on call 24/7. (Loved the pink devops clouds by the way!)
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.
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 !
Thank you, y4es, this is stuff that "leaks out" you can't really put this sort of thinking in a "development team only" box.
Nitpick - Too much echo in audio
Amazing content
agree ++
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.
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!!
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.
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)
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
Thanks for the suggestions.
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?
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.
@@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
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
@@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
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.
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?
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.)
I am leaving thumbs up
Biggest problem I see is that companies have created a DevOps role, rather than treating existing roles for DevOps.
How does one begin learning CD from scratch? Btw. your channel is a life saver.
I might have heard the term "DevOps", but I don't know, what it means and also never used it.
Devops is just a poor name for what it covers. Continuous delivery makes more sense.
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.
Just Dev
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...
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.