Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Term µServices Already Defined Four Years Ago

The Term µServices Already Defined Four Years Ago

This item in japanese


“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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What's the difference to Actors ?

    by Rüdiger Möller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    After Dart's "Isolates", V8's "EventLoop" we now have a third terminology describing actor alike decoupling of processing units or am I missing something ?

  • Re: What's the difference to Actors ?

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Actors use asynchronous communication but services could also use synchronous. I remember when JNI based lookup of in-process services was trendy but hardly anyone does that any more.

    For me, the OASIS SOA Reference Model (SOA-RM) is just fine as a framework that abstracts concrete service architectures of different kinds (see

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p