Three years ago Arnon Rotem-Gal-Oz discussed the then relatively new topic of microservices and how they related to SOA, as well as raising a question about nanoservices. In a recent article Rotem-Gal-Oz maintains that microservices are perhaps not the panacea some would believe and it may be a marketing ploy:
For me, one of the telltale signs that the whole microservices hoopla is a consultant marketing ploy is the whole microservices vs. monoliths thing, as if there is nothing in between. On the other hand, it seems that these days everything that happens to be delivered at an endpoint and runs in its own processes is called a microservices.
Though he may have a point, clearly others do see a spectrum of approaches, and not necessarily binary. For instance, Gartner and others talking about miniservices, which are by one defintion:
A miniservice is true SOA (not unlike a microservice) that can include numerous microservices. It's a level above microservices. It's an external approach to services, while microservices focus on internal scale, ultimately improving external capabilities.
And of course there's the other miniservice-like concept, the so-called microlith. But back to Rotem-Gal-Oz, he is worried about the inference that if you aren't developing a microservice then your service is somehow bad, or a monolith:
[...] if every independently deployed component is a microservice, and needs to have all the traits of a micro service, life gets really complicated. These traits, separation and autonomy, require work, hard work to avoid API coupling, transactional coupling, temporal coupling, internal structures coupling and so on and so forth. Instead, we get to the point that everything is called a micro service even if it does not live up to all the principles.
As one of the commenters on his article points out, and we have reported several times in the past, the same happened with REST:
The term microservice lost its meaning like REST did. Similar to how (almost) every API that uses json over http is now called REST, every service is called microservice.
Rotem-Gal-Oz believes that the binary approach to services (they're either good microservices or not so good services) is counter productive:
It is better to acknowledge that services are indeed these things that are built around business capabilities, APIs (or contracts) delivered at endpoints and governed by external policies with autonomy and what-not. While on the other hand, there are motivations to break services to smaller semi-independent components, which can exhibit most of the principles and benefits like independent deployment and development cycles, but can still share some dependencies esp. around data-structures and storage. I call these semi-independent component aspects.
He goes on to say that making the distinction between aspects and services ensures that different aspects from different services can still uphold the service boundaries. Breaking services into aspects can help to maintain flexibility and simplicity as services grow in size and complexity, i.e., as they potentially move away from the current definition of a microservice. Rotem-Gal-Oz gives some real world examples based on a system he has worked on, where some services that are small (Rotem-Gal-Oz does not give a definition of 'small', so perhaps based on lines of code) and have only one aspect. However, they also have more complex services with more aspects.
One aspect deals with ingesting event data into the service and performs transformations and data munching (building relations graphs of new and existing data), another aspect deals with user driven mutations to that data and the third aspects provides a query API (in graphQL) for accessing that data. Each aspect has its own life cycle, each aspect is independently deployed, they are using multiple languages (Scala and JavaScript) but they do share data on the one hand, and they maintain set boundaries from other services.
Now these aspects sound a lot like microservices even if they are deployed together and operate as a coherent unit, because let's face it, microservices don't exist in isolation. Perhaps the overall architectural approach is similar to the Strangler Pattern, which Martin Fowler and others have discussed before. Rotem-Gal-Oz concludes:
Controlling the coupling levels and maintaining service boundaries is important. Understanding what’s an aspect and what's a service allows controlling the overall architecture and making sure it doesn’t become a tangled web of interdependencies, and at the same time increase flexibility and turnaround times by using smaller components.
Whether these "aspects" are microservices in all but name, it seems that at least one other (Udi Dahan) has also come to a similar conclusion, though he calls these software components something different:
I've been using the term Autonomous Component (AC) to describe the software package of a service that may be deployed as its own endpoint or possibly hosted together with other ACs. This co-hosting model is most useful when building composite UIs.
In Udi's definition, autononmous means that they don't rely upon other ACs, which he discussed many years ago around SOA. Fortunately, Udi wrote more about ACs and microservices a few years later, when he said:
Microservices almost equals Autonomous Components. Why “almost”? Because an Autonomous Component (AC) isn’t necessarily a physical unit of deployment, very often we’ll see multiple ACs deployed in the same physical process. One of the most common occurrences is in a web front end built as a composite UI. In the same web server process we’ll see components from multiple Services.
The distinction between Aspects/Autonomous Components and microservices seems like a useful intermediary step from the monolith to a pure microservice architecture, yet the non-standard definition of microservice could still allow these components to be microservices themselves. As such, maybe others have been doing this already without calling it our explicitly.