Microservices architecture is more of a concept than a defined architecture with a specific set of requirements. It's a better way to achieve the software, which is built to scale reliably and responsively.

James Lewis and Martin Fowler laid out the following characteristics which typically come with microservices:

• Componentization via services: A component is a unit of software that is independently replaceable and upgradeable. The advantage of using services as components (rather than libraries) in a whole system, is that services are independently deployable.
• Organized around business capabilities: Services directly reflect the business capabilities, and achieve the related business processes in the respective business domains and bounded-contexts.
• Products not Projects: It is a notion that the development team should own the product for its lifetime. The product-based mentality makes closer ties to business capabilities. It brings the developer nearer to the business users or consumers, and helps him/her see how the software behaves in production.

• Smart endpoints and dumb pipes: Microservices are to be decoupled and cohesive as much as possible. The purpose here is to minimize the intelligence in your infrastructure. Microservices use simple and dumb HTTP communication protocol without any extra smartness built on top of it, and that promotes lightweight messaging between various services urging event-based communication patterns.

• Decentralized governance: Microservices architecture puts developers directly in charge of their code. They decide the technology, environment, deployment, monitoring, and support. Each microservice has its own developer who can decide on their own about all the aspects of the service life cycle. Centralized governance, on the other hand, as seen with SOA, focuses on centralizing the tools and technologies as well as monitoring, whereas, microservices emphasizes that not all problems can be solved by the same technology and toolings.
• Decentralized Data Management: Following the bounded-context concept from DDD, the data for each microservice resides in a different space--either different instances of the same database technology, or entirely different database systems depending on the specific needs. It also allows for the right technology for the right problem. So, the data is decentralized and managed by only within the owner microservice.
• Infrastructure automation: With microservices, the automation of infrastructure-related tasks becomes natural. This includes continuous integration and continuous deployment to development, test, performance, and in some cases, even to production environments with the obvious necessity of extensive automated testing.
• Design for failure: Compared to monolithic applications, microservices divide the application into a number of autonomous services, and therefore, increase the instances of failures. Since failure with a microservice can happen anytime, especially with communication, it is imperative to detect failure quickly and take an even quicker action. Microservices are architected for automated monitoring, and in many cases, automated recovery and restore.
• Evolutionary design: Microservices itself is an evolutionary design with roots in SOA and DDD. This architecture must support Plug and Play of services where you add some service for a period and then remove or discard it, such as a promotional event in your business domain. Since a microservice is self-contained and autonomous, changing and improving its internal design and technology is encouraged to be done without affecting the whole business and by only upgrading of a business capability (due to technical or business in nature).