Blame it on monoliths - Part 1

Story Behind this Post

We software developers are usually too obsessed about new technologies/patterns and always want to use the latest and greatest to solve our problems. But usually in the pursuit of using latest and greatest technologies or patterns we forget to address the real problems. I hear this notion everyday that using micro-services will solve your deployability issues and makes application more scalable. I acknowledge the fact that it will help but most of the times Organizations do move to micro-services and they still have these problems. Because instead of addressing the real problems they end up creating multiple small monoliths that are still coupled architecture wise.

In this post(Part 1) we will discuss all the theory and then in Part 2 we will try to demonstrate this theory using some application example.

Let’s start by going through the well known benefits of micro-services and we will discuss if these benefits are exclusive to Micro-Services.

Benefits of using Micro-Services

There are two main benefits of using Services is that i think all developers and can agree to is:

• Decoupling
• Services supports independent Development and Deployment.

Let discuss each of them in more detail.

Decoupling

One of the selling point for breaking a system up into services is that services are strongly decoupled from each other. This statement is true but there is more to it. Yes i agree services may not share the resource like processor or process anymore and they can be based on different frameworks etc. So we removed some coupling but there is more to consider when we are considering Decoupling as the benefit. They are still coupled by the Data they share let me explain using an example.

For Example: If a new field is added to a data record that is passed between services, then every service that operates on the new field must be changed. The services must also strongly agree about the interpretation of the data in that field. Thus those services are strongly coupled to the data record and, therefore, indirectly coupled to each other.

Supporting argument will be if interfaces are well defined between the services then we can somewhat control this problem. So is the true in the case of functions. Service interfaces are not any different from Function interfaces if they are well defined it solve the same problem.

I am no way against the micro-services pattern all i am trying to say is before we assume adopting micro-services will benefit our struggling application it’s good idea to have a good look at the current application and try to understand what new pattern will bring to the table.

Independent Development and Deployment

Another benefit of Services is they can owned and operated by dedicated teams. That one team can be responsible for writing, maintaining and operating a service. We believe a big enterprise system can be created from these multiple independently developed and deployed services. I agree with the above statement.

But we cannot deny the fact that there are enterprise systems out there that are developed using monoliths that are scalable so i just want to say services is not the only way to write scalable systems.

So my point is Services can be developed, deployed and operated independently but At the end of the day they still will be coupled by the data they share between each other so these deployments will need to be coordinated in case of enterprise systems.

Now we have looked at the two major benefits of using services. Purpose of all the above discussion was not to discourage you from using micro-services or services. So you must be wondering what was the point of all those examples and explanations.

Let’s try to Understand The Real Problem

The real problem behind the issue with maintainability and deployment issues are coupling between different components. Coupling makes our software more rigid and hard to change. This coupling is defined by the Boundaries in the System and the direction in which dependencies cross the boundaries. Whether it’s dependency between two services or two components or plugins in a Monolith Application.

So adopting a new topology for the system will not solve the problem. Then what will solve the problem. Short answer is sticking to the basic SOLID principles will help solve this problem of rigid systems especially the Open Closed Principle. We will see in the next post where we solve the problem using Open Closed Principle for both Monolith and Micro-Services based applications.

If i have to explain Open Closed principle in context of this discussion it will state In simple layman terms we can add new features to the system by adding new code instead of changing existing code.

I can carry on with explaining more details about Open Closed Principle but i think there are many post explaining already of this principle on the internet and this post is kind of getting stretched. I will try to come up with an example(in Part 2 of this Post) to support the theory i explained above. But thats it for now.

See you later

It’s time for me to say goodbye will see you soon with some other post. Enjoy your life and Be humble. I will see you soon with new post.