“I wrote about and coined the term µServices four years ago to separate lightweight services from the heavy, costly, and complex services people tended to think about because of the advent of Service Oriented Architectures (SOA)” Peter Kriens recently claimed.
Peter, a former employee of the OSGi Alliance, defines an OSGi µservice as a service that always communicates within the same process, without any overhead. Calling a method on a service is as fast as calling a method on an object, making services almost lightweight objects. Because of the lack of overhead, he used the Mu symbol (µ), the symbol for friction, for naming these services and also coined the term µsoa for an in-VM µservice oriented architecture.
Although web-services and OSGi µservices according to Peter have the same underlying architecture for decoupling he claims they still are very different when it comes to execution, purpose, and overhead with a web-service always communicating with a party outside of its process.
James Lewis and Martin Fowler in their description of microservices earlier this year claimed communication is between processes:
“In short, 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.”
Russ Miles in his forthcoming book Antifragile Software lists what he sees as commonly considered properties of microservices:
“Single-purpose, simple (i.e. disentangled), autonomous and separately deployed services organised according to the change stressors on the system and that share nothing, especially state!”
Russ specifically notes that there is no mention whether a service is an object or a function and not if it’s invoked synchronously or asynchronously, using HTTP or other protocols
As a way to distinguish between the definitions Peter argues that that cohesion is what matter most for module decomposition in good design, not size. Cohesion measures the conceptual closeness of the service's methods with a cohesive service having a well-defined single responsibility. He therefore suggests the name cohesive web-services for what other calls micro-services.
