The Problem With Microservices

Microservices are one of the most popular modern architectural approaches, but they are much more complicated to do well than most organisations think. So what is Microservices Architecture, what is it for, what are Microservices and why are they a lot more complex than they look on the surface?

In this episode Dave Farley will explore the costs, and benefits, of microservices listing the key features that distinguish this approach from others and answers questions like "When are they a good choice” and "when are they not?”. One of the biggest problems with this useful software development approach is that many, maybe most, organisations that try to build a microservices system, aren’t building microservices at all! It is more complicated than it looks!

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

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
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

📖 The original award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

_____________________________________________________
Also from Dave:

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

The best way to keep up to date with the latest discussions, free "How To..." guides, events and online courses.
---------------------------------------------------------------------------------------
Other Useful Books on this topic:

(Please note, if you buy a book from these affiliate links I get a small fee, without increasing the cost to you)

[Arvigeus]

Expectations: Rant about microservices
Reality: Misuses of microservices and advices how to avoid mistakes

10/10 quality content!

[SiKeeble]

I’m a 30+ years Software Engineer, with clearly a similar path. This is extremely well articulated and should be on the ‘reading’ list of all modern software developers who want to understand concepts from a big-picture level. I don’t often comment on YouTube content but this is worth expressing thanks for a good, down to Earth presentation.

[rialpleya]

Every developer out there should watch this video. Orchestration and monitoring tools vendors made a lot of damage by trying to get everybody adopting microservices so they could sell their shiny tools. Then developers found themselves producing distributed entangled spaghetti aberrations just because nobody taught them what Dave excellently does here.

[christophjahn]

Wow! With almost 25 years of professional software development under my belt, this was the first video/document on Microservices, which made sense to me. Everything else, and that includes most of the big software conferences, was just a variation of marketing bullshit. It is really fascinating to see that it always comes back to how we deal with "complexity". And that is not technical stuff, but the organizational and domain side of things. Thanks a ton!

[podell]

I have been interviewing with a lot of companies lately that want candidates with micro services experience. Unfortunately most of the companies don’t really understand micro services. They think it’s the NEW way to do development. What they don’t realize is that micro-service’s is just one of many ways to implement your project. Great video!

[PowerScissor]

I'm a 25 year Master Journeyman plumber...but somehow have become fascinated by microservices over the last few weeks.

I absolutely never plan on coding a single thing in my entire life...but really enjoyed this video.

Gives me a little perspective when I update some software and wonder how they introduced so many bugs with a simple small update...

[janezbarbic]

This channel is amazing, thank you sir! I am arguably a seasoned engineer at this point but listening to you keeps me motivated to better myself constantly. I think will watch every single video of yours. Keep up the good work!

[rolandfisher]

The explanation of the bounded context is better than any other I've heard.

[edwardallenthree]

My development is mostly a private affair. I write code that I use, web interfaces that I am the only customer for. This content is still helpful, even for my hobby. This video got me thinking of problems that should be decoupled that aren't, and conversely convinced me not to decouple things just to make them "micro." There is no shame in coupling my front end with my back end code, for example in my latest node.js project.

[pedroluiz]

One problem that I’ve experienced with microservices is that it is really hard to keep everyone up on what are the boundaries of each of you services… sometimes a lot of requirements come from the managers and they want it do be done in service A when it should be done in service B and not all employees know all of the microservices that well to be able to set those boundaries…

I’ve experienced features being done in a service and then it came up that the same feature was already being done in another service that is called way up in the architecture, way after it was already shipped to production.

I’ve thought about it if that’s a problem of not having so many people understanding that well the architecture or if that’s a leadership or management issue…

I feel like there’s a small inner system that developers are capable of understanding, it’s almost impossible to master the design/domain of so many of the microservices.

I haven’t seen anyone talking about this, I’m always wondering how companies like Netflix deal with that, like, how many other mircroservices do your engineers need to grasp besides the one/ones they are really contributing code to?

[adrianperez]

As a relatively new developer (2+ years) I really enjoy your video. Helps me to think at a scale larger than the code immediately in front of me. Thank you for this!

[SpanishandGo]

I clicked because I saw Captain Dissillion's logo.

[stephenmyers]

I've watched a number of your videos now and they are brilliant. Straight talking and oozing knowledge and wisdom. From now on, part of my decision process is going to be 'what would Dave Farley do'

[mno]

The only software engineering processes and practices related content that makes 100% sense.

I've been a part of multiple discussions around such topics like software architectures, design patterns, agile development, behavior/test driven development etc...none of them make as much as sense as much as your content does.

Dave, please continue posting such videos. I want you to know that your experience, talks, and discussions make lives easier for many software engineers worldwide! 🙂

[MaxPicAxe]

The idea of "bounded context" is so important. Whenever i discuss architecture with people i talk about my idea of a "module boundary" but i always struggled to explain what i mean. This description of a bounded context is exactly what I was looking for.

[PhilipAlexanderHassialis]

My key takeaway here is this: the API (as in the names of the calls, the expected arguments, the expected results, etc) should be the first thing to be designed and agreed upon when the analysis phase is over. On top of that it must be cast in stone, immutable and stable during a development cycle. Finally it must be the first thing that will be mocked during implementation so the service consumers have something to work upon.

The mentality to adhere to all of this in an agile environment where there are constant releases every e.g. month or so, this is the real fight, this is the real issue, the fact that people must put down some communication constraints, draw a box and remain in there, no "well, you see, the customer also decided they want this and this and this so we are mutating the API definition".

A mini lecture on how to keep people in check (both on customer side and on the PM/TechLeads side), now, that would be a treasure!

[wjcvanes]

Although I am a software developer with 22 years of experience I am new to microservices and this video really helped to improve my understanding, so thank you very much.

My immediate conclusion, taking Melvin Conway's wisdom into consideration, is that an organization that wants to adapt to a microservices architecture should be willing to reorganize accordingly. If the management of the organization is not aware of this, the campaign of migrating towards microservices will fail (at least initially). So business consultancy (of good quality) should be involved to make this a success.
What I have often seen, however, is that new paradigms or technologies are presented to managers as a panacea of all their current problems without any big effort on their part (just buy our product or pay our consultancy fee). Do you have any thoughts on that? How can a senior software developer advice or influence the management of an organization to do the right thing? (either endeavour a reorganization or recognize that microservices are not for them, yet)

[destroyonload]

Your experience shed light on exactly what I felt was off about people/companies claiming to be doing microservices but most definitely are not. This is an enormous problem for semantics and execution. Not everyone is on the same page. I really think of big monolith companies that want to decompose their design into "microservices", but in the end they will spend a ton of money for little to no benefit (ROI). So much time is often wasted chasing after 'trends' before thinking things through...

[melphiss]

Microservices is the most convenient model for cloud providers profitability. You’ll end up buying much more api gateways, load balancers, monitoring, databases, virtual machines etc than normal services

[zentratuskrypto]

I feel that the font used for the presentation points is the same font used in the Star Wars opening text crawls, and it is immensely appealing.