The point made in this article, as well as the original Fowler piece, is not compelling. It’s not that it’s wrong, it just doesn’t present an actual argument. The premise is (emphasis mine):
The problem, as Martin Fowler observes, is that teams are becoming too eager to adopt a microservice architecture without first understanding the inherent overheads. A contributing factor, I think, is you only hear the success stories from companies who did it right, like Netflix. However, what folks often fail to realize is that these companies—in almost all cases—didn’t start out that way.
Really? What is this list of companies? What about other confounding variables? And what about granularity? The argument seems to be monolithic vs microservices, but there is a lot of room between those two. The only company mentioned in this piece is Netflix and it just so happens Adrian Cockcroft is a big proponent of the start-monolithic argument. Perhaps the stance from the author and Feathers has more to do with Cockcroft being loud rather than evidence.
On another note, the author mentions “anti-fragility” several times. The commonly accepted definition (that I am aware of) of anti-fragility is from Taleb’s book on it and it means that a system becomes stronger when given a shock or stress. This doesn’t really have anything to do with SOA or monolith. I think the author might be referring to “graceful degradation”, although I’m not sure if that requires a SOA or not.
I’m really not sure why this article is controversial. It’s not hard to see that distributed systems are complex or that converting a synchronous app into async adds complexity. All my professional experience tells me it’s best to start simple and add complexity as the tradeoffs shift. I’m yet to see any evidence that a microservice-first strategy can be successful. I’m trying to stay open to the idea, but I just don’t understand how it could work.
I don’t know if controversial is the word I’d used, but I’ll bite. I believe you are making the same mistake this article is making: filling lack of evidence with your personal biases. For example, what about being monolithic implies the app is synchronous? Monolithic apps can be synchronous as well.
The general argument of “I have not seen anyone succeed who started with microservices, thus monolithic services are the correct start point” is not compelling for the following reasons:
It does not follow that the inverse is true (not microservices -> not failure).
It could be that a majority of people starting with microservices are fad-followers rather than “serious” engineers and would fail regardless of their choices.
Software engineering history is a graveyard of “use X and you will fail” arguments. We have had them over databases, languages, frameworks, hardware, just about everything. In the end, the evidence has generally come down on the side that of technology choices having little direct influence on the outcome. People can get junk to work and people can get beauty to work.
Almost all of the posts I have read on the subject seem to echoing Cockcroft rather than elucidating under what principles the idea is bad. Cockcroft happens to have run a successful engineering department that used the model he is, retroactively, advocating. At least give me multiple sources.
I believe my actual argument is quote the opposite of controversial, it’s that the microlith vs monolith discussion is probably irrelevant.
The point made in this article, as well as the original Fowler piece, is not compelling. It’s not that it’s wrong, it just doesn’t present an actual argument. The premise is (emphasis mine):
Really? What is this list of companies? What about other confounding variables? And what about granularity? The argument seems to be monolithic vs microservices, but there is a lot of room between those two. The only company mentioned in this piece is Netflix and it just so happens Adrian Cockcroft is a big proponent of the start-monolithic argument. Perhaps the stance from the author and Feathers has more to do with Cockcroft being loud rather than evidence.
On another note, the author mentions “anti-fragility” several times. The commonly accepted definition (that I am aware of) of anti-fragility is from Taleb’s book on it and it means that a system becomes stronger when given a shock or stress. This doesn’t really have anything to do with SOA or monolith. I think the author might be referring to “graceful degradation”, although I’m not sure if that requires a SOA or not.
I’m really not sure why this article is controversial. It’s not hard to see that distributed systems are complex or that converting a synchronous app into async adds complexity. All my professional experience tells me it’s best to start simple and add complexity as the tradeoffs shift. I’m yet to see any evidence that a microservice-first strategy can be successful. I’m trying to stay open to the idea, but I just don’t understand how it could work.
I don’t know if controversial is the word I’d used, but I’ll bite. I believe you are making the same mistake this article is making: filling lack of evidence with your personal biases. For example, what about being monolithic implies the app is synchronous? Monolithic apps can be synchronous as well.
The general argument of “I have not seen anyone succeed who started with microservices, thus monolithic services are the correct start point” is not compelling for the following reasons:
I believe my actual argument is quote the opposite of controversial, it’s that the microlith vs monolith discussion is probably irrelevant.