Microservice or Monolith Architecture?

Application Monolith

Server-side applications can come with either a modular hexagonal or layered architecture with four main parts: presentation, business logic, database access, and application integration. The presentation deals with the HTTP requests coming into the server and processing the HTML/JSON to structure it. The others are pretty self-explanatory (business logic is the applications business logic, etc.). When deploying your application, these four parts come together to make a monolith of code. This is called Monolithic Architecture and it's structured like this for a couple of reasons. The most dominant reason and the only reason it is still integrated so frequently is that it is so simple. It's simple in developing, testing, deploying, and scaling. With this simplicity does come some drawbacks, unfortunately. These drawbacks revolve mostly around complexity and run-time as once an application gets too large, the monolith structure starts to struggle. Other struggles include redeploying after every update, conflicting resource requirements, and sometimes even reliability. Overall, this architecture is very convenient and easygoing that tends to struggle once the application gets larger and more complicated. In the modern age and where application building is headed, it will eventually be outdated and underpowered as the future hopefully holds larger and more complicated projects.

Microservice Architecture

Looking at the monolith picture above, you can visualize it as one unified structure using the four different blocks. With microservices, they significantly affect the database and application relationship. This is because microservice architecture splits your application into smaller, embedded services that have their own business logic and adapters to act on their own and create individual actions. Each service is different and acts on its own so instead of sharing one big schema (like monolith), they each have their own connection to a database. Because microservice architecture utilizes multiple databases there is most likely going to be data overlap but in return, it ensures loose coupling. The benefits that come from using this architecture start at tackling complexity, enabling a team to work more cohesively and effectively, reducing the struggle to adopt new technologies, and enables technologies to be updated and scaled independently. As you can tell, microservice architecture handles all the problems that monolith architecture couldn't but this also comes with drawbacks. The drawbacks are a lot more complicated and less straightforward. For instance, the first problem is complexity. Once you add multiple services that all have separate motives, it becomes a lot harder to understand where a problem is coming from, and fixing it can become lost in the order of operations of how the site is populated. Testing a microservice application can also be a lot more complex in the sense that you would need to launch that service and any services that depend on it, in order for it to work or be tested in general. This also means that deploying and running your site will be harder because each service will need its own runtime instance and each instance is going need to be configured, deployed, scaled, and monitored.

Summary

Monolith = easier and lightweight
Monolith != able to handle heavy loads and convenient
Microservice = effective for large projects and accessing information from multiple places
Microservices != simple in any way or able to be implemented with haste.