Economics is about production, distribution and consumption.
Microservices aim to break down logic from what could become a monolith application.
Hence, this is my definition of a microservice if it follows one or more of these messaging models:
- publish/subscribe – message queue (like NSQ) or messaging transport (like Project Iris)
- broadcast – Project Iris, mangos
Messaging services work within a private subnet. If it needs to communicate across subnets, it needs to talk to a Web service in as much as you talk to a router if it is beyond your subnet.
However, Web services go beyond that since it speaks the entire TCP/IP protocol suite; that is why, it hogs the media hype trailing behind little brother “messaging middleware” in the wide spectrum of application development.
Messaging is not about client/server nor is it about broker/brokerless dichotomy (that is an implementation detail). Messaging is all about separating producers from consumers. It is about division of labor. It is about loose coupling. It is about reactive programming which is programming with asynchronous data streams. And it is scalable.
In a word,
microservices = Web services + messaging middleware
Microservices solve the producer/consumer problem.
On the other hand, containers and virtual machines solve the distribution problem.
The distribution problem does not care which stack you are using. All it cares about is that, you can move your app (in the case of container) or virtual machine to another place (be it on your laptop, network or across a datacenter).
That is why it is important not to confuse a container from a virtual machine. Otherwise, you may do things onto a container that is only appropriate for a virtual machine, and vice versa (see hyper.sh).