One of the principles I love in software is keep it small. This principle is applicable irrespective of what you are talking about--the scope of a variable, the size of a method, class, package, or a component. You would want all of these to be as small as they possibly could be.
Microservices is a simple extension of this principle. It's an architectural style focused on building small capability-based independently deployable services.
There is no single accepted definition of a microservice. We will look at some of the popular definitions:
- Sam Newman, Thoughtworks
"Loosely coupled service-oriented architecture with bounded contexts"
- Adrian Cockcroft, Battery Ventures
"A microservice is an independently deployable component of bounded scope that supports interoperability through message-based communication. Microservice architecture is a style of engineering highly automated, evolvable software systems made up of capability-aligned microservices" in the book Microservice Architecture
- Irakli Nadareishvili, Ronnie Mitra, Matt McLarty
While there is no accepted definition, there are a few characteristics that are commonly featured in all definitions of microservice. Before we look at the characteristics of microservices, we will try and understand the big picture--we will look at how architecture without microservices compares with architecture using microservices.