IMO it is not fair, even accurate, to compare these three architectures. They apply to different aspects os software systems. Monolith and microservices refer to how an application is distributed (or not), while layered is one of the options available for the internal application's architecture.
You can end up with crappy code, like the one used as example for the monolith application, while building microservices. You can build elegant and well structured monoliths, very likely involving some layered approach in the internals.
The difference is, generalizing, if you ship all the moving parts together in a monolith, or as set of independant applications with microservices.
I haven't seen the video, maybe there you go more in details on it, but considered worth to comment the above. "Monolith" has some undeserved bad press I trend to counter when possible ;)
I do agree with you when you say "how an app is distributed" in that monolithic does not necessarily mean disorganized and poor coding patterns, and I realize that this post does not highlight that fact well. I have updated various parts of it to reflect this and want to thank you for pointing this out!
The intention in the post was to highlight the difference between having files that circularly referenced each other (i.e. poor "n-tier" design), but what I failed to mention was what you pointed out on how this problem can arise even in a microservices architecture. The first example is a "Poorly designed monolith" while the second example is a "Well designed monolith".
And finally, to your point on monolithic architectures getting bad press, I definitely agree. From my experience, I would say that anything you are designing from scratch (i.e. you have a general idea how to build it, but not enough foresight to fully plan) should start as a monolith and get refactored in only the places where it is truly necessary.
About the levels of quality you can find inside a monolith, I am experiencing right now the curious situation of how, in order to be able to extract some functionality out of a poorly designed monolith to some separate service, the process of decoupling and isolating the code is leading to some decent implementation of it and removing the need of a new service and all the burden it implies in terms of communication, testability, etc.
As you point out in your post, the simplest choice that covers your quality needs is the way to go.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
IMO it is not fair, even accurate, to compare these three architectures. They apply to different aspects os software systems. Monolith and microservices refer to how an application is distributed (or not), while layered is one of the options available for the internal application's architecture.
You can end up with crappy code, like the one used as example for the monolith application, while building microservices. You can build elegant and well structured monoliths, very likely involving some layered approach in the internals.
The difference is, generalizing, if you ship all the moving parts together in a monolith, or as set of independant applications with microservices.
I haven't seen the video, maybe there you go more in details on it, but considered worth to comment the above. "Monolith" has some undeserved bad press I trend to counter when possible ;)
I do agree with you when you say "how an app is distributed" in that monolithic does not necessarily mean disorganized and poor coding patterns, and I realize that this post does not highlight that fact well. I have updated various parts of it to reflect this and want to thank you for pointing this out!
The intention in the post was to highlight the difference between having files that circularly referenced each other (i.e. poor "n-tier" design), but what I failed to mention was what you pointed out on how this problem can arise even in a microservices architecture. The first example is a "Poorly designed monolith" while the second example is a "Well designed monolith".
And finally, to your point on monolithic architectures getting bad press, I definitely agree. From my experience, I would say that anything you are designing from scratch (i.e. you have a general idea how to build it, but not enough foresight to fully plan) should start as a monolith and get refactored in only the places where it is truly necessary.
My Monolith SJW spirit feels way more calm now :D
About the levels of quality you can find inside a monolith, I am experiencing right now the curious situation of how, in order to be able to extract some functionality out of a poorly designed monolith to some separate service, the process of decoupling and isolating the code is leading to some decent implementation of it and removing the need of a new service and all the burden it implies in terms of communication, testability, etc.
As you point out in your post, the simplest choice that covers your quality needs is the way to go.