What is the difference between Monolith and n Layer?

Question

i have a few questions regarding monolith and n layer architecture.

First, whats the difference between Monolith and n Layer architecture?

Second, let's say I have a single Visual Studio solutions that consist of multiple projects such as:

1. Presentation Layer
2. Service Layer
3. Business Layer
4. Cross Layer
5. Data Layer
6. Unit Test

Is that considered as Monolith or n layer architecture?

If I have microservices that consist (let's say) 3 Web API and I build each service in single separate Visual Studio solutions, it is ok to implement my previous project structure (service layer, business layer, data layer, etc)?

Thank you very much and sorry for my bad english.

Bruin

Answer 1

"Monolith" solutions are the old way of basically having ONE project in a single solution which has all the code in there.

So let's say you're doing a website.

This means you would create a single Solution with a single Project and all the database calls (persistence), logic (business logic/services) and finally figuring out how to display that calculated data (presentation) are all mixed in, in a chaotic way in that single project. Sometimes people have tried to split the concerns into folders, but usually it's a large mess. This makes support/maintenance of the application a nightmare. If you wish to make a single change to the website/application, the entire application will go offline/restart.

vs

n-tier / n-layered solutions/applications. This is where we have multiple projects (usually) in a solution which separates the concerns of our application in to more bite-sized components. This enables us to keep the problem space to a single area making it much easier to maintain and support. This also enables easier reuse of your various components/projects/DLLs into various other subsystems of your application. It's way better than the old monolith architecture pattern. But, if you wish to make a single change to the website/application, the entire application will go offline/restart still.

Finally, we have "microservices". This is a more modern concept and continues on with the evolution of monolith -> n tier -> microservices. This is when we split up our application concerns into individual applications so that when one microservice needs to be updated, then entire application hasn't come to a stop. Sure, the part of the application that has a dependency on the microservice might stop/be affected, but it's possible that the entire app is not.

Let's use an example:

• I have a website that sells Pets (cats/dogs/etc).

• I might split this website up into separate microservice mini websites:

  • authentication
  • administration/backend management (think: stuff only an admin can see)
  • public website
  • animal inventory
  • shopping cart

So each of those are a single website, like the the n-tiered architecture'd application. So it would have a presentation layer (the MVC website). some database project and some basic services.

Now each of the 4 microservices (mini websites) all do that.

Now, you need to update some stuff with your administration section of the website. You take that offline and the main website stays up. People can still browse and buy animals.

So yes, it's a nice thing to implement microservices if you application is large enough that it has areas you might want to segment. It does add some more complexity but it also brings about its own advantages.

And yes, your microservices should follow the n-tiered pattern if you application isn't some silly hello-world app or some Research Project.

Landsturm

thank you very much for your detailed answer, it's really help me to understand the difference. – Bruin

Great explanation (though not a fan of buying/selling pets :). – Nostril

I'd like to add that the microservice approach is mostly used on platform-like apps, if I'm not mistaken - meaning that you can easily create another eg. frontend-app which would interact with all the existing microservices, while with monolith, you'd have to edit your single solution and incorporate the new app into it. Also, the microservices and all of it's services, frontend apps etc. can be hosted on different servers, which you can't do with monolith. Regarding the n layered architecture - it is ok, and all monolith, or microservices, should implement it these days anyway. – Topfull

In spite of the fact that your explanation was useful and good, it was not entirely accurate. Both monolithic and microservices can be considered n-tier applications. See this link. Check this: https://mcmap.net/q/748721/-what-is-the-difference-between-a-monolithic-architecture-and-a-3-tier-architecture – Girder

Answer 2

The short answer to your question is - Horizontal Partitioning of the Technology stack (n-Tier Architecture) vs. Vertical Partitioning of the Technology Stack (Microservices)

Chastity

This doesn't answer the question. Read the question again and answer neatly 2 main question - "First" and "Second" and then lastly third question about "implement"ation. – Baudelaire