Lately Microservice architecture got very popular especially with the big data. We found out that dividing the application into smaller pieces is much more scalable than a single big monolithic application.
Microservice architecture also goes along very well with the popular API economy architecture that allows applications to depend on other applications over network.
Scalability: is the most important benefit. Parts of an application with heavy-load can be deployed to more services as microservice instances.
Technological diversity: different services can be written in different technologies like Java, .NET, Node.js etc that is more suitable for the job.
Easier development: a new developer can easily work on a microservice rather than understanding a huge monolithic application.
There is no silver bullet. Microservices have difficulties as well. We should really assess if we need to use microservices and if we have enough resources to do it.
Monitoring and Fail-safe: Microservices can be automatically mounted and unmounted to servers as needed and this decreases the reliability of a single service. Network latency, fault tolerance, monitoring and Fail-safe systems should be very good. Netflix developed a system that goes and takes some nodes down randomly to check if their distributed microservice architecture is reliable and can handle on an issue.
Continuous Integration and Deployment: The more dynamic or in another way the more moving and changing parts the application has, the more solid the CI and CD setup should be. We need to automate the all testing, integration and deployment process.
Distributed Logging: Since there are lots of microservices in multiple servers, their logs and possible logged errors should be piped to a centralised log analyzer hub. Also processing logs needs a distributed computation engine. A stack that eases this pain is Logstash + ElasticSearch + Kibana which lately got very popular. It provides distributed logging and distributed processing of them.
Asynchronous programming: Both the consumer and providers applications should be highly asynchronous. It is more difficult to develop async applications because they are harder to debug and trace the code flow.
Maintenance Burden: as the number of services grow doing maintenance on them can be time consuming. DevOps / sys administrator teams should be also prepared to handle the lots of changing and moving parts. A good practice here would be continuously extracting re-usable pieces from services and create libraries. This way instead of updating apps individually the libraries can be updated easily.
This depends. My opinion is what the service does should be easily explained to another person in a few sentences.
It is better to develop a single monolithic application first, see how the application should be and what should it do, then extract pieces of services from its code base, primarily from the parts of the app where the load is high.