Author: Brandon Pearman

The views expressed here are mine alone and do not reflect the view of my employer.

Before you jump into microservices you should first understand them, figure out if you need them and what it takes to do it properly. Let's start by looking a simple pro and con list:

Microservice Pros/Cons
Pros Cons
Allows team division:
It is easier to divide up teams where they each have their own code base. This is a huge benefit for large companies with large systems and also makes managing source control a lot easier for devs.
Adds complexity to communication and dependency:
Team dependency and communication slows overall progress. There are some clever ways to mitigate this but often what lands up happening is teams require some form of documentation, since they can't simply goto the method they need to call and read the code (its in another repo which they may or may not have access to).
Fast skill up:
It is easier to skill up new developers on individual services. A junior developer does not have to be bogged down by having to understand the entire system before he can start working.
Require more skilled staff:
It is harder to understand the entire system. Require more skilled devs/ops/architects to manage the system as a whole. If any public interfaces or data models are changed and there are unexpected consequences, a monolith can easily detect the issue at compile time, where microservices will only pick it up at runtime.
Independently scalable:
Can add more instances of an individual service when they are under heavy load, while the other services may not need more instances.
Harder to deploy:
When there are so many moving parts in the system it becomes difficult to keep track of everything or to replicate an environment. Manual deployments or overly simple scripts can lead to problems as the system grows and scales. Automated pipelines which are important for microservices, still adds more required knowledge and more upkeep. Deploying a monolith is really simple since there is only one thing to deploy and no fancy deployment pipelines are required.
Independently deployable:
One team can deploy their component without having to deploy any other services.
Harder to manage dependencies:
Sometimes coordinated deploys are required, for example if one team changes the contract between services then others will also have to be deployed together. Furthermore, runtime errors are prominent over compile time errors due to the decoupling. Breaking of clients can easily be missed at compile time since the microservice being worked on does not have knowledge of it's clients dependency on it. Although a good suite of integration tests and contract tests can help with this issue, this adds to the requirements to make robust microservices. System wide bugs can be detected easier with a monolith since more issues can be detected at compile time and integration tests are easier to write.
Technology independence:
Each service can be written in any language and use any technology allowing developers to decide on whats best for the new service.
Increases gaps between teams:
As teams deviate with their technologies, design, learnings and understandings, it becomes difficult for teams to share their knowledge and for members to change between teams. Losing devs which are skilled in the tech a service was built in means rewriting it or finding a new dev which knows that tech.
When one service goes down it does not bring down the entire system. Other services can still run without it.
Have to consider inter-process communication, handling partial failures and errors from network/latency issues, consistency with multiple databases, integration testing, monitoring of multiple services, and how to implement features which span multiple services. Developing and maintaining a monolith is far more simpler as most of the concerns mentioned are not an issue with a monolith.

Check out these links for more info:

My design and architecture repo