Microservices Granularity for the Internet of Things
There are a lot of parallels between the Internet Of Things and Microservices. One of the big battles in the design is the granularity of each service and the impact that can have on interdependency and network costs.
Join the DZone community and get the full member experience.Join For Free
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 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 the granularity of a service is to remain from the beginning as transport-independent as possible. As described by this article, new standards such as OSGi Remote Services/RSA and ECF's modular implementation of these specs makes transport independence much easier for the microservices designer and developer. One consequence of using such an approach is that once sufficient experience has been gained, it will be much easier to refactor a microservice to be more or less granular. It does not guarantee that all microservices granularity changes will remain possible, but it does make it easier.
Published at DZone with permission of Scott Lewis, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.