In most organisations, everything INSIDE the main monolithic system has access to pretty much all the relevant data it needs. It is like second nature and as such, we rarely stop to consider what it’s like to not have access to data.
But crucially, anything OUTSIDE this main monolithic system has access to... nothing. For a new microservice to be meaningful, it will need to manage a piece of the data pie: it will need access to SOMETHING.
That's when maybe many will be tempted to access the main database directly, trying to bypass the monolith. However, keeping a shared database between microservices is an anti-pattern. A strong rule in a microservices architecture is: No shared database between services. Data should be owned and managed by a single service: this is called data sovereignty. Read about this principle in more detail here.
Without a significant effort, any new development outside the monolith is a "pariah", isolated from any existing data and relationship with any relevant area of the business.
That is why I say that the monolith has this black hole effect on the business, pulling in more and more data under its control. This happens because it’s faster and simpler to bolt new features and data onto the monolith rather than build a new service from scratch. Because of that, and because microservices bring their own complexities, there is never a good time to start a microservice.
Like a black hole bending the space around it, the monolith warps development priorities and architectures. Anything that gets too close is pulled in — data, features, even whole projects — until escape becomes almost impossible.
A monolith has an extraordinarily influential effect on any new development, just as a black hole will absorb everything in its vicinity by the sheer power of its mass and gravity. Escaping that gravitational pull is hard — but the first service to truly orbit outside its reach will define the future of your architecture.
Top comments (0)