Monolithic & Microservices Architecture

  • Simplicity — All the code is in a single solution. If you need to change something, all the code you need is in a single place. If you need to run the app locally, it’s only necessary to run a single application.
  • Easy to deploy — It’s easy to deploy because it’s only necessary to deploy a single project. Every time a new feature is added or a bug is fixed, it’s only necessary to deploy a single application.
  • Well known — Almost every developer already worked in a monolith application, so this makes it easier to find someone who can easily start to work on the project.
  • Easy to debug — It’s easy to debug a monolith because all the code is in a single solution. So when you need to debug, it’s only necessary to run the code and debug without doing extra configurations.
  • Easy to test — It’s easy to perform tests in a monolith application since everything is in a single app, so it’s not necessary to configure the communication between other applications, neither check if the other apps are running, and so on. You can also easily implement end-to-end testing by launching the app and testing the UI with some tool like Selenium.
  • Easy to monitoring — When a failure/bug occurs, it’s easier to identify where the problem happened, because the code is all in a single project.
  • Can become too big and difficult to maintain — When the project starts, it’s easy to maintain, but through the years the application can become bigger, and this can be difficult to manage. A monolith application works really well for small or medium applications, but when the application is very big and complex, this can become a problem.
  • Unavailable time in deploys — When something changes in a monolith and needs to be deployed, the whole application will be unavailable during the deployment.
  • Can be difficult to work with big teams — Imagine a scenario where you have a monolith application, and there are many teams working in the same application. In this scenario, there are more space to some problem happens, because every team will be working in the same code, in the same project, this way increases the possibility of some conflicts happened when the code is merged in the repository, or also sometimes when one change is made by a team can affect something that the other team is working.
  • Scalability is not flexible — Monoliths can scale, but it’s only possible to scale the full application. If the application receives too many requests in only some specific part of the app, you can not scale only this part, it will be necessary to scale the whole application. Also, it’s not always possible to make use of horizontal scaling, it will be necessary to scale vertically and this is generally more expensive.
  • Restrict to the chosen technology — It’s difficult to switch the technologies in a monolith application, so generally, when a monolith is created, it will probably use the same technology for long years.
  • When you know that the application is not going to be so big
  • When you don’t know exactly how the application will be, for example, if the requirements are not well specified, or the domain is something new to you or to your team
  • When the project is a proof of concept
  • When the team is small or is a new team and the domain is also something new
  • When the app will only contain some CRUD operations with a few business rules
  • Flexible scaling —Each microservice can be scaled independently of the other services. This way when a part of the application is receiving many requests, for example, it’s possible to scale only the specific microservice, instead of scale the whole application. Microservices are handy in cases where it’s necessary to have high availability of the application.
  • Deploy independently — Because microservices are loosely coupled (they are independent of each other), it’s possible to deploy only one microservice. This way it will not demands that the whole application stop working for a few moments because only a small part of the app will be updated/changed.
  • Eliminate the single point of failure — Splitting the application across many small services, eliminates the “single point of failure” in the app.
  • Reduces the risk of breaking the app If a microservice breaks, it will not affect the rest of the application, it will only affect that single microservice, while the other parts of the app will continue working correctly.
  • Minimize downtime when a new version is released — When a new version of the microservice is released, the application will not stop working for a while, only the part which uses that specific microservices will be unavailable.
  • Can be easier updated — Since a microservice are not, in general, a big application, it’s easier to change something in the code or even update the framework which is used by the microservice.
  • Easier to work with multi teams — When working with many teams, each team can be responsible for a specific microservice, or for a group of microservices, separating the responsibility of each part of the project between the teams.
  • Easier to understand — A small application is in most of the time easier to understand than a bigger application.
  • Easier to expand — It’s easy to expand an application by creating new microservices.
  • Independently changeable — When something needs to be changed in a microservice, only the own microservice needs to change, and this will not affect the other microservices.
  • Can have different databases — It’s possible to choose a different database for each microservices. In one microservice a relational database can be the best option, and for other microservice, a NoSQL database fits better, and this is possible to achieve when working with microservice. Each team can define which database is the best option for the microservice.
  • Technology agnostic — Each microservice can have different technology, one can be done in .NET, other in Java, other in Node, other in Go, and so on. This way each team can define which technology they want to use in each microservice.
  • Agility — With microservices it’s very easy to add something new and deploy a new version without having much impact on the whole app.
  • Development productivity — Imagine a scenario where there are ten microservices, and you need to implement a new feature in one of them. In some cases, it’s necessary to execute many of them locally (using some specific version) or make use of an environment where the microservices are deployed for development purpose, to be able to access many parts of the application.
  • Can be difficult to debug — It’s not so simple to debug an application in a microservices architecture because most of the time it’s necessary to run more than one microservice to debug or perform tests. Imagine that you are implementing a new feature or searching a bug in a microservice, but to test the whole process, it will be necessary to run two other microservices in order to test or search for a bug in the process.
  • Communication between the microservices — The communication between the microservices is also something that needs to be taken into account when working with this kind of architecture. There are some microservices that can use synchronous communication (like user authentication for example), but in others, it’s better to use asynchronous communication using some kind of message technology like RabbitMQ, Kafa, Azure Service Bus, or others. This also increases the complexity of the app.
  • Handle with errors — The error handles in a microservice architecture is much more complex than in a monolith application. Imagine a scenario where a request will be processed using two or more microservices, if something goes well in the request to the first microservice, but something goes wrong in the request to the second microservice, the operation should be reverted to the previous state.
  • Update Shared Data — Imagine a scenario where you have in one Database the table “Customer”. In one microservice (or imagine also a bounded context) like “Sales”, the entity “customer” can have some properties, and in another microservice (or bounded context) as “Support” for example, customer can be something different, with other properties, but some properties can be shared between them like Id, Name, and others. So when some operation in one microservice change some information in the Customer from the Sales, for example, it’s also necessary to update the Customer in the Support, and the other way around. In this situation, you can think about “Saga”, which is a design pattern that can be used to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step.
  • Automated deployment — Different from a monolith application where it’s only necessary to deploy a single app and it’s easy to do it manually when working with microservices the deployment process should be automated because it will be necessary to frequently deploy many applications.
  • Identify errors can be difficult — Identify a bug in a microservice architecture, can be much more complex and difficult than in a monolith app, especially when handling asynchronous communication. If you need to debug the app and search for the problem, probably it will be necessary to run more than one microservice locally.
  • Monitoring — In order to have traceability, it’s a good approach to have a centralized place where it’s possible to check the logs and monitor all the errors or problems that happen in a microservice. This will make a bit easier to identify where some error/bug occurred in the application. In order to track problems and errors, it’s important to have logs and make use of some monitoring tool like Elmah or others.
  • When you know that the application will grow a lot and will be really big
  • When you know about the domain of the software and the business rules, or the requirements are well specified and it’s possible to identify that will be a complex application
  • When the team is re-written an old application which is big and complex
  • When availability and flexible scaling is one of the requirements for the application
  • When working with multiple teams and the domain is well known



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Henrique Siebert Domareski

Henrique Siebert Domareski

I've been working with software development with .NET since 2011, and love programming and solve problems using clean code particles.