Did Microservices Break DORA? • Dave Farley • GOTO 2024

We’re so pleased to having teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.

Find plenty more from Dave on his @ModernSoftwareEngineeringYT channel.

Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.

RESOURCES
Dave

Links

ABSTRACT
The "State of DevOps Report 2022" from DORA offers some interesting, and surprising findings. One of them says that "Loose-coupled architecture leads to more burnout". This is completely opposite to what previous year's results have said - so what's going on?

In this episode Dave Farley looks at some of the findings, and explains why this report matters. Dave also offers his critique of the report and highlights some of the interesting things it has to say about security, cloud, and loose-coupled architecture, as well as asking if the new addition to the best metrics in software really stand up to scrutiny. (It's not all about microservices).

CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

RECOMMENDED BOOKS & LINKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:

#GOTOxDaveFarley #Microservices #DevOps #DORA #Programming #DORAReport #MicroservicesArchitecture #DaveFarley #GOTO #GOTOcon #Complexity #ProgrammingTutorial #SoftwareEngineering

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[kellyfj]

18:50 "How is it possible that there is more stress and more burnout in teams like these (Microservices teams)?". The problem lies in the increased complexity of distributed systems especially as they get "crufty" over time (software rarely gets less complex). As with ALL engineering each decision has a trade-off - yes Microservices (when designed and implemented correctly - which is rare!) provide clearer architectural boundaries and enable speed of development by independent team. But what's the trade off ? Complexity at run time. You have to keep an eye on the performance of the APIs, or if event-based then if you are falling behind and time to event execution. You need to be able to autoscale but good luck if you have a relational DB. Something upstream suddenly needs 10x the capacity? Good luck there too. Having canary deployments and rate limits and lots of other tools in place becomes critical. And the tooling there is not great.

There is no free lunch and to think that microservices were just an absolute good is to miss the tradeoffs inherent in all engineering decisions.

[fluffysheap]

Microservices not only aren't good, I think they're actively bad: you push complexity out of your server language that's designed to handle it, and into the nebulous space outside of anyone's responsibility, where it can't be managed by any technique or technology.

[WouterSimonsPlus]

Thanks for the commentary on the report, I really like it. It makes me wonder about the results that the new element of “Good” is scoped to reliability, especially considering that Google is behind it. Google has produced a lot of value for the industry in my opinion with things like their cloud offerings, kunstmest, and SRE practices. But there is a risk that the population questioned is also very much in favor of these things and the question development might also show a bias towards these things I fear. Can we still trust the independence of DORA from this bias?

As for an example with experience showing a different outcome; I like the story of basecamp exiting the cloud to get cheaper infrastructure with better performance that matches their particular case with a very specific product. In those cases, can you say that these teams would be less likely to be high performing because they do not leverage the cloud?