Software mixed with marketing: micro-services

A few months ago I was on the phone when the speaker on the other side mentioned micro-services. Many moons ago I'd written a blog about OSGi's µservices because people were getting confused with the term service. Though this name was unique enough in 1998, the advent of Service Oriented Architectures (SOA) had imprinted people to think about heavy weight, costly, and complex things requiring stacks and other things a developer wants to avoid. That is, everything OSGi is not. I even used the Mu symbol (µ) because it was also the symbol for friction, of which µservices have so little. I therefore kind of naturally assumed the guy was talking about our wonderful in-VM µservice oriented architecture (µsoa). Actually, I smugly told him that I coined the term, trying to impress him. This however turned the discussion from straightforward discussion about technologies into a rather confusing one, that is, until I realized that they had stolen our name again!

Looking at the discussions it seems that micro-services talk like a web-service, they walk like a web-service (that is, they don't walk, they are actually kind of static), and they quack like a web-service.  Ergo?

They could not even call it tiny-service, puny-service, or small-service (getting the alliteration for free). Oh no, they had to jump the 6 magnitudes with micro! The worst thing is that it is a terrible misnomer to call a web-service a micro-service. I get the service part, a service is clear a point to access some functionality according to a contract; all service models share this core idea. However, a REST-service and a WS-* service use the Web/REST prefix to identify the communication stack. Since the OSGi µservices have zero overhead because they are actually local calls it makes sense to call them µservices. However, this new 'micro-service' is still a web-service or a REST-service, inheriting the often sizable communications stack and overhead associated with remote procedure calls. These new incarnation of web-services are only supposed to be conceptually small.

Which is of course is quite silly, since size is not the primary factor for module decomposition (of which service design is an instance). The things that mostly counts in good design is cohesion. Cohesion measures the conceptual closeness of the service's methods in relation to the overall system, a cohesive services has a well defined single responsibility. When I read about the micro-web-services I think they actually just mean cohesive web-services.

So can someone please ask them to call their bright idea cohesive web-services? Then we all know what they are talking about, we keep the vocabulary consistent, and we can keep using the term µservices because in OSGi they actually are!

Peter Kriens

@pkriens

OSGi BOF Tonight @ OSGi DevCon 2014

OSGi DevCon 2014 is well underway and Tonight we have an OSGi BOF.

Its at 19.30hrs in Comedians Room in the South Tower at the New York Marriott at the Brooklyn Bridge.

Its your chance to come and meet with your peers, network and ask any questions.  There will be a number of the OSGi Alliance Board Members at the BOF including Dan Bandera, the President.

David Bosschaert will kick us off with a quick demo creating a project through Bndtools and then showing how to work with this project both inside Bndtools as well as from the command line with Maven.

Peter Kriens will also be around and keen to talk with anyone about OSGi enRoute or answer any questions.

In the true spirit of a BOF there will be plenty of opportunity for everyone to take part asking and answering questions, sharing and gathering insights and experience.

We hope you can join us at 19.30hrs this evening.

Mike

PS Don't forget its tutorial day tomorrow at OSGi DevCon - sign up to be sure of your seat.

Draft OSGi Enterprise R6 specification available

The OSGi Enterprise Expert Group has released a draft of the upcoming OSGi Enterprise R6 specification. You can find the following updates in the download package:

• The new Asynchronous Services specification has been added which allows clients to invoke OSGi services in an asynchronous way.
• A Promises API specification has been added. Promises are a very popular programming model in the Javascript world, where they make it easy to work with operations that execute in an asynchronous way. OSGi Promises follow a similar pattern. They are used by the Asynchronous Services specification, but can also be used independently.
• A new specification on Framework management via REST has been added. This facilitates remote framework management in cloud and other contexts where REST is the protocol of choice.
• A number of updates are made to the Remote Service Admin specification. RSA now supports remote endpoint modification notifications through new modification events. This means that if you update the service properties on a remoted services, this will no longer appear to clients as if the service was removed and then re-added. With the new modified event a previously remoted service will remain, and is updated in place.
• Subsystems have been updated to version 1.1, a number of changes have been made to this specification including the ability to provide the Deployment Manifest separate to the subsystem archive.
• The Repository spec has been updated to version 1.1, allowing more complex queries to be passed to the Repository.
• A new HTTP Whiteboard specification is being worked on. This specification brings Servlet support up to Servlet 3.x and adds whiteboard-based Servlet and Filter registration.
• Declarative Services is receiving an update which adds a new and really convenient way to work with Configuration, support for Prototype Service Factory (which is introduced in Core R6) and an introspective API.
• The MetaType service is being extended with annotations.

You can download the draft specification from the OSGi website on this location. Note that the zip file contains the draft spec, as well as three RFCs for which no spec chapter is ready yet, these will also be included in the final specification.

Also released this week, the Core Platform R6 final specification. Get it here.

OSGi EEG co-chairs,
David Bosschaert
Tim Diekmann