Services and Aspects -when everyone is super no-one is

For me, one of the telltale signs the whole microservices hoopla is a consultant marketing ploy is the whole microservices vs. monoliths thing, as if there is nothing 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.

The problem with these two perceptions is that it is like their eponym (services) , microservices still hold the same principles as SOA such as they should built around a business capabilities, they should have their own database, etc.

Now, 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, requires 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 to all the principles and when everything is a microservice nothing is

Personally I think this all-or-nothing 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.

I think it is important to make this distinction between aspects and services to ensure that different aspects from different services still uphold the service boundaries. It is important to break services to aspects to maintain the flexibility and simplicity as services grow in size and overall complexity.For example in ReconGate’s system I working on these days, we have some services that are small and only have one aspect such as the Users service, which holds the system users and their passwords information. However, we also have more complex services with multiple aspects. For instance, one of the services is made of 3 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 the 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.

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. Using two distinct terms , helps, in my opinion, reason about these two forces better and control the overall picture

Related posts:

Microservices – it’s déjà vu all over again SOA anti-pattern: Transactional Integration SOA patterns (finally) published