I see microservices as an architectural pattern or style. Some styles are well described in the literature (Roy Fielding's description of REST is an example). Unfortunately, there was no clear description of the microservices style when it became popular. And the growing buzz has contributed to the confusion because different people try to add nice-to-have characteristics to what a microservice should be. For example, based on things I've read, one might conclude that microservices should:

• Have few lines of code (some say 10-100 LOC).
• Not be part of circular calls across services.
• Be developed by a team that can be fed by 1 or 2 pizzas.
• Avoid synchronous communication (request-response calls).
• Offer coarse-grained operations (though microservices are "fine-grained services").
• Be run by the team who built them.
• Not participate in complex service compositions.
• Have the freedom to use new languages, frameworks, platforms at will.
• Manage their own databases.
• Be monitored by sophisticated logging and monitoring infrastructure.
• Be developed by teams split around business capabilities motivated by Conway's law.
• Match DDD bounded contexts.
• Be dynamically discovered.
• Be small enough to be rewritten in two weeks.

Thus, requirements for a microservice are all over the place, and often mention good software engineering practices known for decades.

I'd rather stick with the well-known description by Lewis and Fowler: "the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. "

From an architecture perspective, the microservice style belongs primarily to the deployment view. It dictates that the deployment unit should contain only one service or just a few cohesive services. The deployment constraint is the distinguishing factor. As a result, microservices are easier to deploy, become more scalable, and can be developed more independently by different teams using different technologies. Beyond that constraint, other characteristics describe a lean SOA service that does not use orchestration or ESB.

Despite the lack of clarity about what microservices really are, it's exciting to see the many ideas, tools, and discussion sprung from them. I'm not sure we're past the peak of inflated expectations with microservices, but I certainly look forward to seeing what consolidated shape microservices will have when they reach the plateau of productivity. At the moment, for us software developers, more important than having a clear definition is to understand the tradeoffs of using microservices.