(Please note this article is part 1 of a series of posts addressing the concept of microservices.
This post also endeavors to engage the readers practically; for maximum optimization of the learning process, please follow along with the project.)
What are microservices?
Microservices are an approach to building our software applications where we have our system split into multiple sub-applications. Traditionally, in monolithic architecture, when building applications, we create an n-tier layered architecture or an onion architecture, but each layer is deployed as a single entity. In the microservices sphere, rather than having our software as one entity, our app is a composition of sub-apps distributed across networks and deployed as different individual applications.
Microservices VS Monolith
As stated, the difference between microservice and monolith architecture is that our application is split into smaller applications.
For effectiveness, one must not blindly follow the trend of implementing all applications as microservices simply because it might not be necessary for that particular project.
In building our systems, the architecture is subjective to the specific project and the best approach for effectiveness and efficiency.
Pros and cons of Microservices VS Monolith
Application - Microservices are split into multiple applications, while monoliths are not - this offers a lot of flexibility in that the sub-applications can be worked on independently by different teams using diverse tool sets.
Source control - Microservices split our source control repository into multiple repositories, while monoliths are usually in one large repository.
Scalability - Microservices offer the possibility for different services to scale independently of one another, according to the demands. In monoliths, the whole application is scaled together.
DevOps - Deploying microservices requires a lot of infrastructural and DevOps-related concerns. Monoliths are most times easier to deploy with minimal hassle.
Microservice architecture is an effective approach to building applications. It offers a host of advantages, but so do monoliths. The key is understanding the system you're trying to build, the resources at hand to accomplish that, and deciding on what works best.