3 ms·

That sounds ideal when you say it like that. The reality is often far removed in my experience, with services calling back and forth hither and thither, which i

That sounds ideal when you say it like that. The reality is often far removed in my experience, with services calling back and forth hither and thither, which is to say that all you've done is taken the spaghetti that often characterises enterprise software and stretched it out a bit in places. And in so doing what you've done is add a bunch of latency. The one virtue of the former, non-microservice, situation is that at least you don't have the latency overhead because all that spaghetti is contained in one, or a small number of, processes, rather than spread around all over the place between a large number of processes and instances. I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces. Just my two cents, and obviously not a trendy point of view. I'd be quite interested to see how Martin Fowler's view changes over the next 11 years, assuming he doesn't retire.

vidarh 10y ago
And if they do call back and forth, then all of the advice Fowler gave in the initial article still holds. So my point is his earlier views are for the most part not in contradiction with the microservices patterns - if anything, the latter is a evolution of the former, and the combination can basically be distilled down to: If you must/want to split, split along service boundaries where communication is mostly with the client, and minimise communications surfaces between services. If you do that, you gain ability to scale services separately, and develop them separately. If there are lots of interdependencies, you have bought yourself lots of latency and reliability issues for little gain elsewhere. > I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces. I agree with that, and those people should probably start with articles like the linked one to learn to think about latency issues first.

vidarh 10y ago

And if they do call back and forth, then all of the advice Fowler gave in the initial article still holds. So my point is his earlier views are for the most part not in contradiction with the microservices patterns - if anything, the latter is a evolution of the former, and the combination can basically be distilled down to: If you must/want to split, split along service boundaries where communication is mostly with the client, and minimise communications surfaces between services. If you do that, you gain ability to scale services separately, and develop them separately. If there are lots of interdependencies, you have bought yourself lots of latency and reliability issues for little gain elsewhere. > I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces. I agree with that, and those people should probably start with articles like the linked one to learn to think about latency issues first.