The Microservices Dilemma

You are currently working on a cloud-native application architecture and noticing that it seems to imply a micro-service architecture as well. However you yourself are not fully subscribed to a micro-service architecture for your application. This is a interesting dilemma because how do you define a micro-service and which part of the micro-service architecture are you against.

We define it as a collection of independently managed, loosely coupled services that are partitioned based on logical data relationships. For example Account -> User are tightly coupled data components. They would be collected into a single microservice called Account. It is a good practice to consider the data relationship between the services because this will avoid externalising a data dependency. With a micro-service architecture the client is responsible for rendering the application and acts as a aggregator.

To couple or not to couple

Queues, streams (i.e Kafka) can make the micro-service architecture more complex to define as due to the nature of these components its possible to export dependencies between micro-services. The talent of the developer is required to understand the relationship between coupling high frequency data like this. In our view it is sensible that the data relationships principle apply here today and any microservices that share data are collected into a single service. It is necessary to study your architecture when you use these tools because it is possible that developers will export dependencies via these mechanisms and break with the principles of a sound microservice architecture.