Microservices architecture has become a buzzword within the last five years with the emergence of cloud-based hosting services. There is no fixed definition of this architecture, but in general terms, microservices architecture is a way of designing and implementing software as a collection of independently deployable services that are highly coherent and loosely coupled. Each of these services will be designed, implemented, deployed, and maintained by a team of usually 5 to 10 members with complete ownership and accountability. Each microservice will address a particular domain of a system (user, sales, and others), can be developed using different programming languages, and can have its own persistence and an API to enable synchronous communication and/or a publisher/subscriber model for asynchronous communication. 

Microservices architecture was preceded by monolithic architecture, where all the functionality was grouped into a single application that loaded and ran inside a single process. This monolithic software was really heavy and took a lot of time to load, and scaling required the entire application to be scaled by replicating it in multiple servers. There was no way to scale a particular functionality alone. This is depicted in the following diagram:

Microservices architecture addressed these pain points by enabling us to run small, highly cohesive applications that do one functionality really well. This could load fast and require fewer resources to function. Scaling of a microservice can be done by distributing it across servers and by replicating it as and when needed. Consider the following diagram:

There are some characteristics that can be found in any Microservices architecture-based software application, which are as follows:

• Service components: The components in a microservice architecture are services that can communicate via a web request, RPC call, and so on. Unlike library components in a monolithic application where communication happens between library components via in-memory, in-process calls internally without an external API.
• Organized by business domain: In a monolithic application, layering of the application was done using techniques such as user interface, business logic, and database. But in a microservices architecture, layering is not like that; instead, it is based on a business domain such as user, or transaction.
• Building products, not projects: A monolithic application is considered to be a project, where it will be developed by a groups of engineers, deployed by another group of engineers, and maintained by another group, whereas microservices architecture-based software applications are built as products, which are owned by the group of engineers that developed them. They are accountable for the deployment, smooth running, and maintenance of that microservice product.
• Smart Microservices, dumb queues: Instead of using an Enterprise Service Bus (ESB), which is capable of doing complex tasks such as transforming, filtering, routing, and aggregating of the messages being communicated, microservices rely on using dumb queues, which are just to communicate between two microservices asynchronously. All heavy lifting should be done in microservices.
• Decentralized persistence: Polyglot persistence, as it is commonly known, lets each microservice use its own persistence (Database, Key/Value store—whichever suits it well), instead of relying on a single persistence store.
• Fail tolerance: Microservices should be able to work under predictable and unpredictable failures. 
• Automation: Microservices should be able to be deployed using continuous integration and continuous deployment tools. 
• Future-proof with the ability to evolve.