Are microservices able to fulfill the promises service-oriented architecture (SOA), allegedly, has not been able to achieve? This architectural style consists of partitioning a more complex software system into independent chunks of functionality (called microservices), each of which runs in its own execution context with its own data storage and uses “lightweight communication mechanisms” (that is, HTTP/REST) with other microservices. Such a decoupling should then be able to increase development and deployment speed over traditional SOA approaches.

This paper subscribes to this view and attempts to demonstrate the benefits of this approach by developing an editor for a certain class of process models (Petri Nets, but this fact is mostly irrelevant).

Unfortunately, however, the discussion remains at a too-superficial level with regard to almost all aspects of a thorough discussion I would have expected. This affects even highly important architectural decisions, for example, using an “API gateway” (which typically is not needed in a microservices architecture) or why the microservices really have been segmented in the way they are. Apparently, two different editors have been built, one for a mobile and the other for a (web) server execution environment, but then I could not find an explanation of how the claimed “reusability” was really achieved. Neither did the authors substantiate their “high flexibility” claim other than by using a circular argument.

Personally, I fully endorse the potential stated in the beginning of my review. The paper, though, cannot be used to advance this position. Nonetheless, as a kind of residual merit, it collects some definitions and corollaries of this architectural style (for example, Conway’s law) in a readable fashion that other readers might find useful.