95

What are advantages and disadvantages of microservices and monolithic architecture?

When to chose microservice architecture or monolithic architecture?

Ravindra babu
  • 37,698
  • 11
  • 250
  • 211
user902383
  • 8,420
  • 8
  • 43
  • 63
  • 7
    Martin Fawler has written an extensive article on the subject. I highly suggest you to read this: http://martinfowler.com/articles/microservices.html – Kaj Oct 09 '15 at 15:41
  • Check out this article on microservies architecture : https://medium.com/startlovingyourself/microservices-vs-monolithic-architecture-c8df91f16bb4 – Bhagwati Malav Feb 24 '18 at 12:29
  • Its just that a micro-service is a fragment of a whole application system running as a server or service process independently and it is run on the cluster of servers. So if a bug happened on that service it is isolated and your whole system will not break down entirely, that is one advantage aside from concurrency you can get. – LEMUEL ADANE Nov 18 '18 at 22:24

3 Answers3

174

This is a very important question because a few people get lured by all the buzz around microservices, and there are tradeoffs to consider. So, what are the benefits and challenges of microservices (when compared with the monolithic model)?

Benefits

  • Deployability: more agility to roll out new versions of a service due to shorter build+test+deploy cycles. Also, flexibility to employ service-specific security, replication, persistence, and monitoring configurations.
  • Reliability: a microservice fault affects that microservice alone and its consumers, whereas in the monolithic model a service fault may bring down the entire monolith.
  • Availability: rolling out a new version of a microservice requires little downtime, whereas rolling out a new version of a service in the monolith requires a typically slower restart of the entire monolith.
  • Scalability: each microservice can be scaled independently using pools, clusters, grids. The deployment characteristics make microservices a great match for the elasticity of the cloud.
  • Modifiability: more flexibility to use new frameworks, libraries, datasources, and other resources. Also, microservices are loosely-coupled, modular components only accessible via their contracts, and hence less prone to turn into a big ball of mud.
  • Management: the application development effort is divided across teams that are smaller and work more independently.
  • Design autonomy: the team has freedom to employ different technologies, frameworks, and patterns to design and implement each microservice, and can change and redeploy each microservice independently

Challenges

  • Deployability: there are far more deployment units, so there are more complex jobs, scripts, transfer areas, and config files to oversee for deployment. (For that reason, continuous delivery and DevOps are highly desirable for microservice projects.)
  • Performance: services more likely need to communicate over the network, whereas services within the monolith may benefit from local calls. (For that reason, the design should avoid "chatty" microservices.)
  • Modifiability: changes to the contract are more likely to impact consumers deployed elsewhere, whereas in the monolithic model consumers are more likely to be within the monolith and will be rolled out in lockstep with the service. Also, mechanisms to improve autonomy, such as eventual consistency and asynchronous calls, add complexity to microservices.
  • Testability: integration tests are harder to setup and run because they may span different microservices on different runtime environments.
  • Management: the effort to manage operations increases because there are more runtime components, log files, and point-to-point interactions to oversee.
  • Memory use: several classes and libraries are often replicated in each microservice bundle and the overall memory footprint increases.
  • Runtime autonomy: in the monolith the overall business logic is collocated. With microservices the logic is spread across microservices. So, all else being equal, it's more likely that a microservice will interact with other microservices over the network--that interaction decreases autonomy. If the interaction between microservices involves changing data, the need for a transactional boundary further compromises autonomy. The good news is that to avoid runtime autonomy issues, we can employ techniques such as eventual consistency, event-driven architecture, CQRS, cache (data replication), and aligning microservices with DDD bounded contexts. These techniques are not inherent to microservices, but have been suggested by virtually every author I've read.

Once we understand these tradeoffs, there's one more thing we need to know to answer the other question: which is better, microservices or monolith? We need to know the non-functional requirements (quality attribute requirements) of the application. Once you understand how important is performance vs scalability, for example, you can weigh the tradeoffs and make an educated design decision.

Paulo Merson
  • 13,270
  • 8
  • 79
  • 72
  • Hey, interesting answer. I was wondering if the performances were that different or not. Because, microservices needs network exchanges where monolithic doesn't. However, if you have a million of requests, then even if you have network exchanges, the treatment gets split by the microservices where the monolithic has to support the full request treatment right? If we take a simple authentication, it would use a part of the all block where microservices would just give a bit of a part. So does monolithic's perf decreases that much compared to microservices when the request amount growth? – Emixam23 Mar 18 '18 at 01:26
  • 4
    I don't quite understand the comment, but the point is in comparing the performance of the same functionality implemented and deployed as a set of microservices versus as a set of components within the same monolith. All else being equal, in this case performance (response time specifically) tends to be better in the monolithic approach due to the possibility of local calls as opposed to remote calls required by the microservices. – Paulo Merson Mar 19 '18 at 02:22
  • 1
    Long call chains involving multiple microservices are an anti-pattern to be avoided, and there are specific ways to do so. Therefore, response time should not get worse, with microservices. Only, you'll probably use more hardware to serve the same load. The additional hardware cost, however, brings you things you don't get as easy with monoliths (if you do microservices right): better scale-out properties, higher resilience and reliability and much shorter release cycles. – user625488 Sep 23 '18 at 11:01
80

While I'm relatively new to the microservices world, I'll try to answer your question as complete as possible.

When you use the microservices architecture, you will have increased decoupling and separation of concerns. Since you are litteraly splitting up your application.

This results into that your codebase will be easier to manage (each application is independent of the other applications to stay up and running). Therefore, if you do this right, it will be easier in the future to add new features to your application. Whereas with a monolithic architecture, it might become a very hard thing to do if your application is big (and you can assume at some point in time it will be).

Also deploying the application is easier, since you are building the independent microservices separately and deploying them on separate servers. This means that you can build and deploy services whenever you like without having to rebuild the rest of your application.

Since the different services are small and deployed separately, it's obvious easier to scale them, with the advantage that you can scale specific services of your application (with a monolithic you scale the complete "thing", even if it's just a specific part within the application that is getting an excessive load).

However, for applications that are not intended to become too big to manage in the future. It is better to keep it at the monolithic architecture. Since the microservices architecture has some serious difficulties involved. I stated that it is easier to deploy microservices, but this is only true in comparison with big monoliths. Using microservices you have the added complexity of distributing the services to different servers at different locations and you need to find a way to manage all of that. Building microservices will help you in the long-run if your application gets big, but for smaller applications, it is just easier to stay monolithic.

Yahya Hussein
  • 8,767
  • 15
  • 58
  • 114
Kaj
  • 2,445
  • 3
  • 23
  • 34
  • 23
    My experience (and I've worked on both kinds of codebases) is that monolithic is much simpler: the codebase is much easier to manage (there's much less of it!), it's easier to add features (you only have to add them in one place and don't have to define inter-process APIs for everything), and deploying it is much easier (you're only deploying to one set of servers, not half a dozen types). @Paulo's answer is a much more complete picture! – Ben Hoyt Jan 17 '17 at 16:33
  • _"Also deploying the application is easier, since you are building the independent microservices seperately and deploying them on separate servers. This means that you can build and deploy services whenever you like without having to rebuild the rest of your application."_ - When you have several types of deployments for different services it makes deploying in general harder, not easier. Having one CI configuration vs many, the one is easier to maintain. – Michael Dec 27 '17 at 06:58
  • The best case of splitting the monolith into multiple services when there are completely _independent_ functionalities. If you haven't get rid of dependencies first, you may run into worst case - **distributed monolith** (tight coupling - trivial change = change every service). See more details: **[Microservices Split Criterion](https://uvsmtid.com/microservices-split-criterion-index/)** – uvsmtid May 21 '18 at 15:27
  • This answer is not neutral because you can build modular applications without microservices. The code base is not smaller because you enforce a service API instead of another form of contract, EJBs or Corba services also allowed for modularity. On the other side, the alleged simplicity of deploying a self-contained binary that includes the application server comes at the cost of the flexibility and is biased against the separation of roles between developers and production operations / support engineers. – Jose Manuel Gomez Alvarez Jun 21 '19 at 15:49
12

@Luxo is spot on. I'd just like to offer a slight variation and bring about the organizational perspective of it. Not only does microservices allow the applications to be decoupled but it may also help on an organizational level. The organization for example would be able to divide into multiple teams where each may develop on a set of microservices that the team may provide.

For example, in larger shops like Amazon, you might have a personalization team, ecommerce team, infrastructure services team, etc. If you'd like to get into microservices, Amazon is a very good example of it. Jeff Bezos made it a mandate for teams to communicate to another team's services if they needed access to a shared functionality. See here for a brief description.

In addition, engineers from Etsy and Netflix also had a small debate back in the day of microservices vs monolith on Twitter. The debate is a little less technical but can offer a few insights as well.

Will C
  • 1,750
  • 10
  • 20