The bad parts, yes, there are a few

Implementing the microservices architecture leads to a change in organisational culture, and it is not an easy one to make. Seeing a few large companies achieving success by following this model doesn't necessarily mean it's the right option for your company's need. Before making any changes, it's best to make careful considerations of the benefits and challenges ahead. SOA or having a monolith haven't become obsolete patterns, and neither is microservices the ultimate solution. These points do not intend to drive you away from using microservice architecture, but to make you aware of the disadvantages and certain pitfalls that you'll need to pay attention to. You are probably going to run into rough edges when trying this out at first, but it's essential to be able to learn from your mistakes and decide what works and what doesn't for your team.

Modular services that are defined by business capabilities are not easy to do. There are concepts of DDD, such as bounded context and single responsibility, that help guide us, but these aren't easy to get right first time. It sometimes helps to start off by writing a monolith and then refactor it into microservices later. This helps with defining the business boundaries and modules to build, which is never clear at the beginning of a project.

Having multiple databases can be challenging. Transactions across services which affect various databases are not easy to work with. When a single request is made into the application, the same is often passed downstream to other services which participate in the request handling. Identifying the issue with a request becomes difficult when multiple services are involved. To allow tracing of such requests within the application, a correlation ID is generated at the start of the request and gets passed as a header to each service. The idea is not unique to microservices, and is often used in SOA or other service orchestration solutions.

No matter how much developers love to rewrite code following the next technology buzz, not all projects are candidates for migrating to microservices. With any form of distributed computing, there are challenges that are well-known in the computing world, such as:

• Administering and monitoring dozens or hundreds of services is hard
• Development and testing of distributed systems is not easy; thus, automation of testing and deployment is essential to have
• Decomposing may lead to violation of the DRY principle (duplication of code), which needs some analysis
• Another general issue is referenced as Fallacies of distributed computing, which is also well-documented in material found on the internet

When doing microservices development, it's best to avoid some common mistakes. Here are few Dos and Don'ts to consider, before we move on: