Why Microservices Don't Deliver On Their Promises 

FREE DOWNLOADABLE MICROSERVICES GUIDE: Focus on the right parts of the problem when you are creating a new microservices system. Here's my FREE 'how-to-guide-book' offering advice on the Microservices basics to help you get started www.subscribepage.com/microservices-guide

The headline is misleading. "Why Microservices Don't Deliver On Their Promises" should be "When Microservices Don't Deliver On Their Promises".

The great thing about a distributed monolith is that you are always talking to yourself.

Interesting conversation. I am reminded of the essential truth that i learned from Fred brooks in the 80s: there is no silver bullet. As long as we keep our eye on the utility to complexity ratio of our systems, and keep a proper balance of accidental to essential complexity then we are probably doing about as well as we can. Anyone who is trying to claim that these well known, simple truths no longer apply is trying to sell something.

I think there absolutely are use cases for microservices, but I think they're also often used in situations where they aren't needed and they just over-complicate things.

Thanks for this- planning on listening to the whole podcast. To paraphrase, "if you can't promote microservices independently, then you have a distributed monolith". This is true, of course. The more general issue is that problems arise when there are incorrect boundaries between services/modules. That leads to inter-service calls and various forms of data duplication Logical coupling is the problem. The physical deployment concerns in microservices just makes it more manifest and harder to hide. Coupling is absolutely necessary in any functioning system. The trick being where to put that coupling. There seems to be only 2 places that are necessary and that will not result in a BBOM: 1) The screen. The user expects that data from potentially disparate sources presented in a coherent format -> UI composition. 2) Back end business workflows that are asynchronously choreographed or orchestrated -> Message bus. Perhaps this is obvious. However, there are a ton of recent talks/courses about modularity that completely miss the point and reintroduce the very coupling that they claim to be solving.

Micros complicate unless the problem and solution are very well understood. Best to go from coupled monolith, learn, then decouple and scale with microservices.

IMHO microservices are not bad by themselves, they have a good purpose for some specific contexts. And its specificities that gives ability to respond to those specific comes with specific complexities. So it has a cost. The problem with microservices is that what is often done is not microservices but a distributed monolith full of interservice coupling . Replacing a method call (with params) by a http request (with those same params) doesn’t break the coupling. And you lost the ability to test effectively the behavior of your application. By effectively I mean automated tests that run in seconds and that ensures the functionality works fine. And by distributing the responsibilities in multiple apps makes that you cannot test the whole execution of a given request. You only manage a tiny part of 8:37 the whole story. So, even if your microservice works perfectly fine and respects the contract, you cannot guarantee that the functionality works fine in front of the user eyes. At least not without huge ineffective efforts and huge complications when the distributed monolith grows up to the enterprise information system level… Sorry, I have to try to make it shorter 😅 But so much to say 😄 …

I've never seen multiple versions of the same service for long. Often only a single service has two versions in its own quick unique deployment window.

Another fabulous T-shirt there Dave!

I've been using "distributed monolith" as a term for a long time as I work at companies that try to move to microservices and fail (though they often don't realize it.) I have never heard that term used elsewhere before, so exciting!

I work on software systems where a selected subset of functionalities in the back end could as well be realised as standalone Microservices, not for scaling purposes but for a logical separation of functionalities and it would improve testability. Additional benefit would be that you could have smaller transactions as you extract some atomic functions.

There was a mention that there are cases where you would be better off with a distributed monolith. I encourage Mr. Farley to perhaps pick this as the subject for a video. I confess that I have seen examples where monoliths are desirable, others where microservices are desirable and and some in between were moduliths are desirable. I have not seen an example where a distributed monolith is a good option. They seem to incur many of the costs of both monoliths and microservices and forgo many of the benefits of either.

Can someone knowledgeable talk about use cases where a distributed monolith is the right choice over micro-services? Web search seems to indicate distributed monoliths as microservices gone wrong with no inherent advantages of their own. References would be appreciated - Thnx.

The headlines should be “Why Microservices are Failed” simply because maintaining dependences is very difficult if impossible task for large software project< specially when we’re star talking about sustaining.

Microservices must be independent, therefore you will not care what version you dependencies are. Sam Newman goes as far as saying that microservices SHOULD be deployed separately, precisely to ensure that the anti pattern Mr. Rose mentions does not appear. I agree with other comments that this title is a bit misleading.

The very best thing about microservices is the fact you don't need them. Repeat after me: You don't need microservices. There, problem solved.

i