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
Hey Arnon – I’m with you on having a different name for things. 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.
The term microservice lost its meaning like REST did. Similar to how (almost) every API what uses json over http is now called REST every service is called microservice. The masses don’t care about meaning, they only need buzzwords to improve their CV.
How do you define “autonomous” here?
Regarding deployment & UI access – we deploy everything in containers and use an API GW for routing (just for the UI to prevent CORS problems). The separate deployment allows for transparent and frequent upgrades
Sad but true. However (I hope )it doesn’t mean we shouldn’t at least try to use more exact terminology :)
Autonomous meaning doesn’t depend on other ACs.