Microservices: A Bad Name for a Good Idea
Although the word microservices is in broad use, there isn’t much clarity on what it means. Microservices are not about services and are not about being small, so it’s not surprising there is some confusion.
Microservices are a way of dividing the implementation of an application into a set of components. Microservices are not about identifying a function that is common to multiple applications, and creating a single, shared deployment of that function.
An accurate, if clumsy, name for microservices would be "network protocol-based components." The "network protocol-based" qualifier is important because an essential characteristic of these components is that they talk to each other using the sorts of distributed network protocols that are used for communication between physical or virtual machines, or between isolated containers within a machine.
Replace "microservices" with "HTTP component"
In principle, any network protocol can be used for communication between microservices, but the vast majority use HTTP. Because of this, it is usually correct to mentally substitute "HTTP component" for "microservices" in discussions. If you do this, you’re likely to get better insight into the uses, benefits, and challenges of microservices.
So why did we end up with the word microservices? Because these components—like all components—expose some sort of API to one another, they can be viewed as offering services to each other, and so they can be called services. While this is true, it is not their most important characteristic. The fact that they are implementation components is more illuminating.
How "micro" is micro?
The "micro" modifier was added to the term to indicate that these components only offer services to other components of the same application—if they offered services to multiple applications, they would just be regular services.
Many people have mistaken the term "micro" to mean an indication of size rather than scope, which has led to a lot of discussion about what the ideal size of a microservice is. This is equivalent to discussing the ideal size of a component in general, which is about as useful as discussing the ideal length of a piece of string. By definition, microservices are smaller than the larger application of which they are a component, but other than that their size is not very relevant.
Understanding what microservices are is a first step to understanding what they are about. To get a full understanding, we have to look at what we do with them, and how that is achieved, as we'll cover in an upcoming post on the 12 characteristics of microservices.
Are microservices really just small services? Join the conversation on this topic on the Apigee Community.
Image: Flickr Creative Commons/frankieleon