Microservices Architecture vs Monolithic Architecture

Difficulties with monolithic application, when it grow 

• Large monolithic code base makes complicated to understand, especially for new developer
• Scaling become challenging
• Continuously integration / deployment become complex and time consuming. You may require dedicated team for build and deploy
• Overloaded IDE, Large code base makes IDE slow, build time increase.
• Extremely difficult to change technology or language or framework because everything is tightly coupled and depend up on each other.

Privilege with Microservice architecture, when it grow 

• Each microservice is small and focused on a specific feature / business requirement.
• Microservice can be developed independently by small team of developers (normally 2 to 5 developers).
• Microservice is loosely coupled, means services are independent, in terms of development and deployment both.
• Microservice can be developed using different programming language (Personally I don't suggest to do it).
• Microservice allows easy and flexible way to integrate automatic deployment with Continuous Integration tools (for e.g: Jenkins, Hudson, bamboo etc..). The productivity of a new team member will be quick enough.
• Microservice allows you to take advantage of emerging and latest technologies (framework, programming language, programming practice, etc.).
• Microservice is easy to scale based on demand. In a nutshell, monolithic vs microservice architecture is like elephant vs ant approach. What you wants to build a giant system like elephant or army of ant, small, fast and effective.

SOA vs Microservices Architecture

SOA	MSA
Built on the idea of “share-as-much-as-possible” architecture approach	Built on the idea of “share-as-little-as-possible” architecture approach
More importance on business functionality reuse	More importance on the concept of “bounded context”
Common governance and standards	Relaxed governance, with more focus on people collaboration and freedom of choice
Uses enterprise service bus (ESB) for communication	Uses less elaborate and simple messaging system
Supports multiple message protocols	Uses lightweight protocols such as HTTP/REST & AMQP
Common platform for all services deployed to it	Application Servers not really used. Platforms such as Node.JS could be used
Multi-threaded with more overheads to handle I/O	Single-threaded usually with use of Event Loop features for non-locking I/O handling
Use of containers (Dockers, Linux Containers) less popular	Containers work very well in MSA
Maximizes application service reusability	More focused on decoupling
Uses traditional relational databases more often	Uses modern, non-relational databases
A systematic change requires modifying the monolith	A systematic change is to create a new service
DevOps / Continuous Delivery is becoming popular, but not yet mainstream	Strong focus on DevOps / Continuous Delivery