The main idea with microservices is that instead of one large app you have many smaller apps that each do a small part and communicate with each other.
This can have a number of benefits.
Because each small piece is focused on only a small part they can be more lightweight and thus likely much faster performance-wise than a large app.
Pieces can be and often are written in different languages. You might have a small app written in Go, another using Python, etc...
In a large team you might have members assigned only to specific microservices reducing the need to understand the entire application.
There are also downsides to microservice architecture.
The more moving parts something has the more complex it gets and the harder it is to understand everything. Things like debugging get much harder and there are many more points pf failure.
Splitting an app up into microservices is sort of the "popular" thing to do right now regardless of whether it is actually a good fit for the particuar project. Everyone seems to like to think of their app as "enterprise" and wants to use the cool toys that come along with that like microservices, big data, event sourcing, and no-sql databases.
If your app is working fine as it is and the codebase is managable I wouldn't worry about microservices at this point. Maybe at some point it will be beneficial to split a piece or two out but I say wait until there is an actual benefit.