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 everything that happens to be delivered at an endpoint and runs in its own processes is called a “microservice.”

Microservices, like their eponym (services), still hold the same principles as SOA (Service Oriented Architecture),  such as they should be built around business capabilities, they should have their own database, etc.

Now, life gets really complicated if every independently deployed component is a microservice, and it needs to have all the traits of a microservice. These traits, namely separation and autonomy, require work and hard work. How do you avoid API coupling?, and transactional coupling? Temporal coupling? Internal structures coupling, and so on and so forth.?. We get to the point that everything is called a “microservice” even if it does not live up to all the principles, and when everything is a microservice, nothing is

Personally, I think this all-or-nothing approach is counterproductive. 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. On the other hand, there are motivations to break services into smaller semi-independent components — which can exhibit most of the principles and benefits like independent deployment and short, separate development cycles.  But can still share some dependencies, esp. around data structures and storage, as long as they belong to the same overall service. I call these semi-independent component aspects.

I think the distinction between aspects and services enables us to balance things out and get the best of both worlds –  i.e., both ensure that aspects from different services still uphold the service boundaries. But still, maintain flexibility and simplicity even though the overall service grows in size. For example, at ReconGate, we have some services that are small and only made up of a single aspect, such as the Users service, which holds the system users and manages their passwords. 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 data. Each aspect has its own life cycle and is independently deployed. They are not even using the same language (two are Scala, and one is JavaScript), but they do share a database amongst themselves –  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, increases flexibility and development speed by using smaller components (and minimizing the impacts of changes). Using two distinct terms helps 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