Is DevOps Good Or Bad?

Подписаться 205 тыс.

Просмотров 27 тыс.

50% 1

DevOps represents a significant step forward, or at least it can do. It is a powerful effective approach to software development and delivery but is easily and commonly misunderstood. DevOps tools and DevOps workflows are at the heart of the most effective approach to software engineering, but they are also commonly abused in practice by organisations that don’t understand what this loosely defined set of practices really means. Here at Continuous Delivery, we think that a DevOps process is effective, but that “DevOps" is maybe not the best way to describe it. So is DevOps the same as Continuous Delivery, and which works best, in terms of software engineering to deliver better software faster?
In this episode, Dave Farley explores these ideas and more as he looks at the good and bad of DevOps. Which ideas are important, and can we learn from, which are misleading and confusing?
-------------------------------------------------------------------------------------
📚 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
📖 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
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses. ➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
LINKS:
State of DevOps report 2021 ➡️ services.google.com/fh/files/...
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley

Наука

Опубликовано:

9 ноя 2021

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 50

2 года назад

Glad to know I have been doing DevOps as intended. For me everything is summed up as "if a developer needs to ask me for something related to their job then there is something to improve"

@Resurr3ction 2 года назад

Exactly. It is not always bad to have a DevOps team because someone needs to build the infrastructure in the first place so that you don't have to raise the ticket and do the stuff you need. But the mission statement should be as OP says so it is kind of like trying to remove your job when you are working in DevOps. :-)

@sverdrup4321 2 года назад

This channel is gold. Thank you Dave and CD team for providing us with such high quality content for free!

@ContinuousDelivery 2 года назад

You're welcome! Thanks for the feedback!

@roffel06 Год назад

Thanks for your videos. I find them quite enlightening and helpful, even though I'm not a software developer myself. I find your explanations clear and they helped me better understand the concept that is agile. While the (small) amount of my programming that I do will probably not necessitate DevOps or CI/CD anytime in the near future, the fundamental concepts that you explain in this and other videos do help me with regard to creating more modular and sustainable products. Having increased my understanding, you also have given me a better idea of how to better interact with my stakeholders. Thanks again!

@ondrejbase7390 2 года назад

Loving the step up in production quality! Very nice

@ContinuousDelivery 2 года назад

Thanks 😁

@ilovepickles7427 2 года назад

I just discovered your channel by accident. For a week now I haven't been able to look away. Moment after moment my mind is just being blown away. So many AHA! moments that I lost track. Thank you, sir!

@ContinuousDelivery 2 года назад

You're very welcome!

@felipelopes3171 2 года назад

Hello Dave, thanks for the thought provoking video. The organization I am working on has a lot of the patterns, or maybe antipatterns you describe. We have a Dev and DevOps team, and the DevOps team is a mixture of traditional Ops people who were renamed DevOps, and people like myself, who were originally developers, but got interested in infrastructure tooling, and now do Ops and also bug fixing and application optimization. However, we do try to make people from different disciplines work together in a squad. Even though it was not the original idea, I think DevOps as a role (distinct from Dev and Ops) is better because it has revitalized the role which in the past was called a Technical Architect, a role that's very important, which the market has neglected for a long time, to the point that if someone today has the title of architect it's usually some sales person trying to push a tool or someone who merely does business modelling with no regards to implementation. Although I agree it would be better to have a different name for this role, it's the name that stuck, and I believe it's in high demand because it's the best approach right now.

@saschadibbern339 2 года назад

Some years ago at a financial institution client we made an agility experiment, where all devs over a periode should learn and become an ops and doing ops-work. Vice versa with the ops guys. It helped to break down the barrier. The devs learned the consequences of 'crap code' ...like being woken in the middle of the night and the constraints of limitations like system resource and policies given from 3rdparty like it-sec, company and industrial standards... The ops learned to understand the system, some of the code, system and component purpose, the importance of testing, the thinking of dev and last but not least to communicate their demands better. After half year 2 teams became one

@davidlamb1107 Год назад

What kind of work was a non-dev "ops person" doing such that they had the ABILITY to "put out fires" in the middle of the night? Doesn't resolving such problems almost necessarily involve a developer adjusting code in some way? I feel like I'm missing something.

@weyrdereveryday3478 Год назад

@@davidlamb1107 Yes, normally it does often require a dev to handle things (I remember being called in the middle of night to find somebody wrote script-code that "injected itself" into the processed data, which then failed in downstream jobs), but then the prod-system (a huge set of batch-jobs running financial simulations on grid of calculation servers) and the project (which at that time was at least in it's 5th year and X time of remodifications) still was in a transition-phase awaiting a final okay from the financial authorities. So as the prod system was still legally a production yet, but the ops needed to be trained already, as later failures of night-runs would imply hefty fines by the authorities. Initially the ops people could then still reside to simple commenting out certain code as much of the processing was purely script-languages and rerun the failed jobs again...and that approach is well not the way to understand the system at all, so they needed more hands-on experience into what is inside the system. Even most devs did in reality not understood most of the systems parts (why is this calculating thing here) as core parts of the system are from a 3rd-party system which financial mathematicians ("quants") where configuring. The devs had no financial background (derivative pricing and risk management) to fully understand the why and how of the results coming out. We had a small group risk-quants doing that job... the most funny part though was the observation of people trying to "parrot" things they deeply had no understanding of, but trying to comply with code to what was said to them.

@frozenintime 2 года назад

I'd be interested in knowing how to use continuous delivery for high availability infrastructure development where the applications running on them would lead to a separate team for application development that would eventually run on HA infrastructure.

@CynicalOldDwarf 2 года назад

I think the worse implementation of DevOps is in companies where HR gets too involved in the hiring process and tries to reduce the number of employees by only seeking people that can do both Dev and Ops at the same time, instead of having two teams of specialists that work together closely. And I'm saying that as a former Opper that moved to Dev, I'd actually be one of the magical unicorns that can do everything. But a large reason I left Ops was because I was fed up of doing everything, and the last thing I want to do is run myself ragged doing two people's jobs. I quite enjoy being a dev having standard hours, not having to constantly put out fires, being able to focus on one task at a to,e and specialise in learning very relatable technologies; instead of the slow death of a Admin

@dennislindqvist5461 2 года назад

Sounds like you are talking about Pre-DevOps? But if Ops don´t have the power to tell the organization to put some things on hold while re-organizing, then there will be no improvement. No self-service and no automated tests before delivery. Of anything…

@CynicalOldDwarf 2 года назад

@@dennislindqvist5461 I'm talking about companies that go "We have a flat leadership structure" (aka, we have no actual leadership, we expect you to work it out yourselves) and "We want T-shaped people" (aka, we want people that can do a bit of everything because your downtime is time you're not making value for us) Sure, there's going to be some companies that will have a mature culture and can make the above work, but the majority of times it's going to be HR and Manglement cutting corners without setting up the culture to support them.

@mathalphabet5645 2 года назад

To some. Continuous delivery means releasing a features by merging a dev branch that has been worked on for a sprint on master and running a Jenkins job automatically after merge

@ContinuousDelivery 2 года назад

That is what some people mean, but it does sound more like dis-continuous delivery to me.

@buxeessingh2571 2 года назад

I always thought that DevOps had the dual ideals of facilitating Continuous Delivery for Developers and enhancing stability and standards for Operations via automation. I never thought it should be truly separated from Dev and Ops but rather should be the overlap between the two groups.

@jasonracey9600 2 года назад

At Microsoft there's no ops people. Dev does both. I've gotten pretty good at knowing how to research, template, and deploy cloud infrastructure.

@soundwalkie Год назад

But when I report a problem, as an Azure DevOps user, all I get is the level 1 support replying to me that they cannot reproduce and then case closed.

@denmishchishin722 2 года назад

My (semi)sad story is that i rejected all devops proposals for last year. Literally because im tired to "fight" with wrong perception of topic. Before that i changed 3 places having exact same problematic, that described here. Thank you for your job. I will use your video next time i need to lift this boulder.

@dougarnold8609 2 года назад

Hi Dave, awesome video. Have you a link to the State of DevOps report you were mentioning. I've found both Puppet and Google ones and neither seem to be what you are displaying. Thanks.

@ContinuousDelivery 2 года назад

It is from this years DORA report, you can find it here www.devops-research.com/research.html The picture is p26 of the report.

@dougarnold8609 2 года назад

@@ContinuousDelivery Amazing. Thanks so much :) Definitely consider buying your books after this!

@-Jason-L 2 года назад

Grady booch created the term "continuous integration" ... and it did not mean daily (or multiple times per day). That was XPs approach to CI years later, but they did not originate the term.

@ContinuousDelivery 2 года назад

Did Booch say what he considered “continuous” to mean?

@-Jason-L 2 года назад

@@ContinuousDelivery the Booch methodolgy faded away when RUP consumed everything, but his books are still out there :) XP is extreme programming. It took the "good" ideas/concepts to their extreme. In this case, Beck took CI to it's extreme.

@ContinuousDelivery 2 года назад

@@-Jason-L I know all of that, but CI means "Continuous Integration" so I assume that Booch meant something more than just occasional integration, I was just interested in what he had to say about the CI part. I don't recall ever reading anything about CI in his pre-RUP writings.

@randomgeocacher 2 года назад

I love these why software in “agile” fail. DevSecOps or Dev*Ops to try to solve DevOps not working in org is a classic example, way to close to home. Being agile and devsecops and it still takes several months to get a small simple pen test and ordering it takes significantly more work than the actual time spent by testers execute the test. And devs in a devops team benchmarking trying to understand why their traffic is slow noticing the ingress traffic is unacceptably slow. Then the spectate ops/monitoring semi-confirming that something is wrong/slow in the ingress. Now someone authorized to raise tickets raise the ticket. Wait. Wait. Wait. “Nah they responded to the ticket that it works as expected.” “Wtf what does that even mean? That all the benchmarks and observations were wrong and it isn’t slow? Or that extreme slowness is to be expected by the ingress?” “I’ll see if we can get more information”. Moved on, never got to learn what the final answer was. As far as I know the ingress still is mysteriously slow, connection setup is hundreds or thousands of times slower than normal ingress, and no one knows why for sure.

@davidlamb1107 Год назад

I'm rather confused by the idea of an Ops person who has some kind of Dev gate-keeping power, but who isn't actually also a Dev person themselves. What kind of responsibility does such a person actually have, and why/how would they be "putting out fires" as I've read elsewhere?

@ContinuousDelivery Год назад

I think that your description of a DevOps person, though common, is one of the anti-patterns that I am referring to. The idea of DevOps is not for it to be a role represented in a single person. What you are describing is simply ops. DevOps is a team level discipline, in that successful development teams need to be responsible for their software in production. For that you may want some Ops people as part of the team, you certainly need some Dev people there too, but the important point is that, however these skills and responsibilities, are spread amongst the people, the dev team are monitoring and controlling their system in production. Tonight's video is on this topic "You Build it, You Run it", so watch out for that.

@esra_erimez 2 года назад

I just received your book from Amazon and haven't put it down

@ContinuousDelivery 2 года назад

Thank you!

@MrStefanica 2 года назад

DevOps deffinitely enhances belief. Thanks Dave! 🙂

@SaaS_Components 2 года назад

Very, very good IMHO. So close to real-life scenarios...

@sdb584 2 года назад

I still get the sense that the more established financial institutions are so frightened by removing the friction and still require so many sign-offs to accomplish even the simplest tasks.

@muyvin98 4 месяца назад

While its true that there are good benefits in devops. but in most companies, this usually means multiple hats being done by few people. which is considering devops is a large scope. equals burnout

@wtfxyandzee 2 года назад

Intransigent Truculent Operators from Hell is quite a tongue twister 😄.

@bleki_one Год назад

I like to think that there shouldn't be DevOps engineer or DevOps team, as DevOps is an idea, a movement, similar to Agile. But then we know what with Agile and the same happens with DevOps I'm afraid. And it becomes a shell for selling tools and services.

@jamesprice7612 2 года назад

My company is a bit weird. We didn't have an Ops team. IT "managed" our infrastructure (which was basically never get anything done) and a separate test team tests software/firmware. We've started to embrace CI/CD mentality and formed a "DevOps" group to take infrastructure work away from IT as they didn't even want to do it. However our DevOps team isn't ensuring good releases. It's more focused more on infrastructure, security, deployment, etc. This stuff is important for CI/CD for developers, but how off base are we from the intended definition? We do edge computing, not web services so not everything is a perfect fit from CI/CD/DevOps view. We often get to update software/firmware 2-3 times a year but it's critical it's high quality. Would other terms be more applicable?

@PaulSebastianM 2 года назад

Doesn't it seem like our capabilities keep increasing or at least they expectancy of our capabilities keeps increasing? Is that normal? Is that sustainable? Is that fair?