Microservices Granularity for the Internet of Things
In a 2014 blog posting, Martin Fowler discussed issues around creating networked services in Microservices and the First Law of Distributed Objects. One of his points is that networked services should generally be more coarse-grained than local (in-process) services. The reason for this is that distribution always has costs (bandwidth, performance), and these costs easily can become large with fine-grained remote calls.
But as Fowler points out, there are good reasons (e.g. complexity) to make a networked API as fine-grained as possible. How granular/coarse should IoT microservices be? In his blog posting, Fowler suggested that granularity was an open question, and that experience with different systems with different levels of microservices granularity would provide eventual insight.
I agree with Fowler's view that experience is necessary to decide on 'appropriate' granularity. I think it's particularly true for the Internet of Things, where multiple people and organizations are attempting attempting to create consistent abstractions for the relatively-limited input and output capabilities exposed by newly networked devices...aka 'things'.
But when actually defining remote services, often the first thing done is to bind the service to a particular transport+protocol+impl framework (e.g. https+json+jersey). Once bound to a transport, the service API may become very difficult to refactor and version. This is especially true once a service has been deployed, but frequently deployment is the only way to get enough real experience to be more (or less) granular!
One way to provide flexibility...and allow future change to a service is to remain as transport-independent as possible. As described by this article, new standards such as OSGi Remote Services/RSA and ECF's modular implementation makes it possible to design and refactor services independent of the transport. Such independence will make it easier to update the granularity of a microservice when necessary.