The Term µServices Already Defined Four Years Ago
“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.
“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.”
“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.
What's the difference to Actors ?
Re: What's the difference to Actors ?
For me, the OASIS SOA Reference Model (SOA-RM) is just fine as a framework that abstracts concrete service architectures of different kinds (see docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa...).
One of the most obvious and widely used SOAs out here is the Bluetooth ecosystem and most of it can be mapped to the SOA-RM.
I image that IOT (internet-of-things) architectures will also fit right in.
Finally, I am glad that our childless love affair with REST is over and we can all get back to work.