Microservices versus monolithic architecture

Question

I read a little about microservices, and I'm a little intrigued. This seems to be an interesting concept. But I wonder what advantages and disadvantages microservices use over monolithic architecture and vice versa.

When microservices are better suited, and where better to go with a monolithic architecture.

Answer 1

While I am relatively new to the world of microservices, I will try to answer your question as fully as possible.

When you use the microservice architecture, you will have increased isolation and separation of problems. Since you litteraly share your application.

This leads to the fact that your code base will be easier to manage (each application is independent of other applications, so as not to work and work). Therefore , if you do it right , it will be easier in the future to add new features to your application. While with a monolithic architecture, this can be very difficult if your application is large (and you can assume that it will be at some point in time).

In addition, deploying the application is easier because you create independent microservices yourself and deploy them on separate servers. This means that you can create and deploy services whenever you want, without having to rebuild the rest of your application.

Since different services are small and deployed separately, it’s obvious that they are easier to scale , with the advantage that you can scale certain services of your application (with monolithic you scale the complete “thing”, even if it is only a certain part of the application that gets overloaded) .

However, for applications that are not designed to become too large to be managed in the future. It is better to keep it in a monolithic architecture. Since the architecture of microservices has some serious difficulties. I stated that it’s easier to deploy microservices, but this is only true compared to large monoliths. Using microservices, you have the added complexity of distributing services on different servers in different places, and you need to find a way around this. Creating microservices will help you in the long run if your application becomes large, but for small applications it simply remains monolithic.

Answer 2

This is a very important issue because some people are lured by all the noise around microservices, and there are trade-offs to consider. So, what are the pros and cons of microservices (compared to the monolithic model)?

Pros:

• Deployment : More flexibility to deploy new versions of the service due to shorter build + test + deployment cycles. In addition, the flexibility to use security, replication, persistence and monitoring settings for a specific service.
• Reliability : a microservice malfunction affects this microservice system on its own and its consumers, while in a monolithic model a service error can destroy the entire monolith.
• Availability : Deploying a new version of a microservice requires little downtime, while deploying a new version of a service in a monolith requires a typically slower restart of the entire monolith.
• Scalability : each microservice can be scaled independently using pools, clusters, grids. Deployment features make microservices an excellent combination of cloud resilience.
• Modifiability : more flexibility to use new frameworks, libraries, data sources and other resources. In addition, microservices are loosely coupled, modular components are only available through their contracts and are therefore less likely to turn into a large ball of dirt. Dynamic discovery and registry binding (e.g., Apache ZooKeeper, Netflix Eureka) is sometimes used for location transparency.
• Management : Application development efforts are distributed among groups that are smaller and work more independently.
• Design autonomy : the team has the right to use various technologies, frameworks and templates for the design and implementation of each microservice and can independently change and reinstall each microservice.

Minuses:

• Deployment : Deployment becomes more complex with many tasks, scripts, transfer areas, and configuration files for deployment.
• Performance : Services most likely need to communicate over the network, while services in the monolith can take advantage of local calls. In addition, if the microservice uses dynamic discovery, a registry lookup is an overhead.
• Availability : If you use the registry for dynamic discovery, inaccessibility of the registry could jeopardize customer interactions.
• Modifiability . Changes to the contract are likely to affect customers deployed elsewhere, while in a monolithic model, consumers are more likely to be in a monolith and deployed in a lock using the service. In addition, mechanisms for increasing autonomy, such as possible consistency and asynchronous calls, complicate the work with microservices.
• Testability : Automated tests are harder to set up and run because they can span different microservices in different runtime environments.
• Management : The application is extended because monitoring requires more runtime components, log files, and point-to-point interaction.
• Memory usage : several classes and libraries are often replicated in each set of microservices, and the total amount of memory increases.
• Autonomy of execution : in a monolith, the general business logic is combined. With microservices, logic propagates through microservices. Thus, ceteris paribus, it is more likely that the microservice will interact with other microservices over the network - this interaction reduces autonomy. If the interaction between microservices is associated with data changes, the need for a transactional boundary further exacerbates autonomy. The good news is that to avoid runtime autonomy problems, we can use methods such as possible consistency, event-driven architecture, CQRS, cache (data replication), and microservice alignment with a limited DDD context. These methods are not inherent in microservices, but were suggested by almost every author I read.

Once we understand these tradeoffs , one more thing we need to know in order to answer another question: which is better, microservices or a monolith? We need to know the non-functional requirements (quality attribute requirements) of the application. Once you understand how important performance and scalability are, for example, you can weigh the trade-offs and make an informed design decision.

Answer 3

@Luxo is the place. I simply would like to propose a small change and lead to its organizational perspective. Not only microservices can unleash applications, but they can also help at the organizational level. For example, an organization can divide into several teams, each of which can develop on the basis of a set of microservices that a team can provide.

For example, in large stores like Amazon, you might have a personalization team, an e-commerce team, an infrastructure services team, etc. If you want to get into microservices, Amazon is a very good example. Jeff Bezos instructed teams to communicate with other teams if they need access to common functionality. See here for a brief description.

In addition, engineers from Etsy and Netflix also had a little discussion the same day when microservices were against the monolith on Twitter. The discussion is a little less technical, but may offer some ideas.