Monolith vs Microservices

Monolith vs Microservices - which should you build? As ever in software development, each has its benefits and its downsides. What is a monolithic architecture in this sense, and what are microservices?

One useful perspective on this is what is the scope of change that you need to evaluate before release, and how easy is it to make, and evaluate those changes. To put that another way, if we think about this from the perspective of version control, should you store your changes in a single mono-repo or in multiple-repos?

In this episode, Software Engineering expert Dave Farley looks at this problem from the perspective of Continuous Delivery and explores some of the trade-offs, and while he’s doing that he rules-out a very common, but wasteful approach to SW design and architecture.

_____________________________________________________

📧 FREE MICROSERVICES 'HOW TO GUIDE' 📧

Sign up for the CD mail list and get Dave’s free guide on How to Get Started with Microservices

-------------------------------------------------------------------------------------

🚨 My "TDD & BDD: DESIGN THROUGH TESTING" Course is Available NOW! 🚨

Learn to write great tests, and how to use those tests to improve the design of your software: with step-by-step guidance and demos by Dave Farley, and practical exercises for you to learn TDD and BDD. Available to start now!

_____________________________________________________

📚 BOOKS:

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

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.

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[neildutoit]

Yea when I got into software engineering "monolith" was a synonym for "badly designed". I thought I had to do things microservices. I thought there was no choice. At this point I'm trying to reduce the number of services I have on all my projects, and all new projects I start are monolith. Networking is hard, expensive, and even when it works, extremely slow. And (at least in Python) API frameworks are terrible. The versioning problems discussed here have been especially bad for me because I do document processing pipelines so each step depends completely on the service before it and what version it was. I've spent most of my time over the last few years fighting to try and get APIs to do what I want them to. Such a waste of time. Not nearly worth the effort. So much documentation these days just assumes that you're running microservices and you're running clusters and I'm starting to think that companies are doing this on purpose to get you to buy more servers. Honestly I've never needed multiple databases running in a cluster. And I've never needed to run more than one copy of my apps. You can say oh well I've only worked on small projects which is true but vertical scaling is so underrated a well written application on a big server can handle millions of requests just fine.

[PavelHenkin]

It's rare that I want to upvote a video twice, but here we are. Thank you for elucidating the issue. Too many teams don't take that step back, but just go with the loudest voice's misunderstandings.

[sdb]

My last client was so happy that I chose a monolithic approach to keep everything simple.

[psyaviah]

We exactly decided on doing this, as we suffered from a "dumb-one" approach as we thought it would be better... Yet we stumbled on that testing roadblock and dependency roadblock of shared code... It just so happens you made a video about it as well today. But hereby I can fully agree, please don't split too much. It will hurt you on the long term.

[viewerone]

Mono repos can have independently deployable modules inside of it. They’re not always coupled to each other outside of commit history. Tools like Azure DevOps allows directories in a mono repo to be treated as if they are a separate repo.

[TantalG]

I really like how you leveled up your editing. Great job, and great content, as always
Thank you!

[taraskuzyk]

This is a question I struggled with for the last week, and there was almost nothing on this online. Thank you so much for this.

[superfluidity]

I think the term monorepo may have caused some confusion - Dave is using it simply to mean "one VCS repository that holds the entire system", but I think what a lot of people understand by the term is more like "one VCS repository that holds multiple separately deployable parts, generally containing all or most of the software for an an organization, and often with tooling that detects which parts are changed and only re-deploys the changed parts"

[jimbrown]

This is the best discussion of repos for microservices vs monoliths. Great I am designing a global class app from scratch for the Green House Gas programs around the world. I have chosen microservices in their own repos with their own pipelines as you describe. I had considered grouping microservices but you easily showed me why that is not a good idea. Keep up the great work!!!!

[a__random__person]

THANK YOU for making this video! Hahaha I've seen so many companies do this, and recently convinced a team to revert back to monolith as they were starting to go down this road. I previously would refer to it as "micro-features" but coupled modules makes more sense haha.

[chulucninh]

Thank you Dave. When I asked for your comments on mono-repo vs multi-repo in your video, I thought you ignored it. But instead you release a whole informative video for the topic, WOW!

[dlabor]

I really appreciate you reminding me to hit the like button every time. Makes my life a lot easier not having to think about it all the time. Luckily I don't have to worry about the subscribe button and bell because that was done a long time ago. It is also very interesting to keep hearing from your sponsors and I always enjoy remembering the priceless knowledge and experience you share in your books. Hopefully a lot of people will use your online course, I can't, but that's another story.
Keep it up, Dave!

[randomgeocacher]

A company I worked at consolidated ~3 tightly coupled repositories into one. For about one year productivity was high and the devs were happy. Then someone decided to invent an architecture and that each architecture box into a module. A dev asked me to review a change (as experienced subject matter expert, wasn’t part of the devs). “Why is it in 8 gits?” “It’s because of the new architecture, the change spans 4 gits and then it is also needs a port to the customer’s mirror” “okay it looks okay-ish but it’s weird that the format conversion in one direction in module A, but in the other direction in module B. Decide where the conversion belongs and handle both sides in one module”. (Month go by, dev shows up in other errand) “hey we talked about X some time ago, how did it go?” “I f*ing gave up. It is impossible to get merge approval on a 4 git change. Fixed for customer only and did not merge upstream.”

That’s an impressive way to tank productivity of a company.

I never understood the wisdom of implementing a repository restructuring their most experienced devs described as bad (but in much more profane wording), if the ones who actually understands code says you are shooting yourselves in the foot… but eh, companies unable to understand who to listen to.

My current responsibilities span a a bunch of trivial automation scripts where we’ve already run into dependency issues even if everything is just trivial scripts, no “real software”. But so far I’ve just identified our few stupid couplings and de-coupled the so virtuellt nothing spans more more than one or at most two gits. Do spend some time wondering if we should move mono-repo’s, but there also is something nice with a collection tiny gits where all history is just about that script. But sometimes I worry that my ant-army of tiny gits will become an issue in the future, hindering growth.

[mesopotamianmessenger]

I reached to similar conclusion after practicing the dumb option for a while. This video came too late for me but it is good that it is up now - it can save someone from making their life difficult for no reason.

[stephenpaul]

I love this channel!

My CTO's motivation was not so much about the microservices being independently deployable, but more about scalability.

I often feel that this decision was premature and wonder whether we could have somehow correlated specific operations with a spike in memory, and then after exhausting our optimization options, extract dedicated microservices piecemeal.

We also now have a 'kitchen sink' microservice which is responsible for 80% of the work.

Developers are ambitious, with a Nostradamus complex. 9 times out of 10, our predictions about the 'axis of change' are wrong. We're not all working on the next Uber, and even if we are, we will then have the budget to design the system appropriately. I also feel like we've spent a lot of money (on developer salaries) in order to save a comparatively tiny amount of money on our server costs.

[seiofecco]

We use the multi repo approach. We chose it to help us be sure that there are no hidden or overlooked dependencies between services.
Once a service artifact is deployed to production, we save a copy of the artifact.
Our return to safety is to simply re-deploy the old version.

[madmanX]

Very cool topic and also a great video. I need to share it with my coworkers who think splitting up the codebase of a monolith into separate repos is a good idea :-)

[brianbatchelor]

An excellent presentation of monolithic architecture.

[manuelgurrola]

What do you think about Microservices as a solution for Software Modules that are used in many different (but similar) projects?
A sort of implementation for a Platform.

[fede]

Great video and one of the BEST t-shirts ever!!