Image Image Image Image Image Image Image Image Image Image

Mudassir Shahzad | March 26, 2019

Scroll to top



Why use microservices ? Monolithic vs Microservices style

Why use microservices ? Monolithic vs Microservices style
Mudassir Shahzad

The term “Microservices” has risen over the last few years describing a way to design software applications as independently deployable services.

While there is no general explaination or definition for this term, there are certain characteristics: enabling business capability by using standalone software, running in its own process, small problem domain, integration via interfaces(HTTP, JMS etc.).

Whenever you search for the term “Microservices” on google, I dare you to read a complete article without falling asleep.

So, I will keep this as short as possible because KISS(Keep It Simple Stupid)

To better understand the microservices architecture, we first need to understand the monolithic style.

Monolithic: The currently used natural way of building an enterprise software application is to create the application as a single unit including three parts:

  1. Client side (HTML, Javascript, CSS etc..)
  2. A set of tables which reside inside an RDBMS (for example Oracle)
  3. Server side (Business logic to get data from the DB)

Now, monolithic applications can be successful but increasingly people are feeling frustrations with them as more change cycles are tied together.

A small change in any part of the application requires a redeployment of the whole application. As the application progresses overtime, it’s often hard to keep a good modular structure and ultimately it becomes a mess.

A question is risen here, how will microservices solve this problem ?

Good question. Very very good question. In fact, the answer to this question is the reason you are reading this article for. It is the sole purpose of this article and if you understand this, you will get the idea of what this article is about and the answer is: “Separation of concerns”.

Thank you. Thank you. Please be seated. I will be here all week.

However, when discussing microservices, we normally confuse it with SOA which is an elder approach and was introduced in early 2000’s.

SOA focuses to integrate(connect) monolithic or legacy(old) systems.

Microservices architecture focuses on a single application(usually monolithic) divided into independently deployable services.

So, microservices focus to avoid monolithic style.

Repeat with me, microservices focus to avoid monolithic style.

Once more, with feeling, microservices focus to avoid monolithic style.

I will be writing more on this topic. Stay tuned and share among you circle :)


  1. Shahzad khan

    Wow. Very nice article. Your way of explaining things is awesome. Especially that humorous touch.
    Microservices are awesome. Loved your article.
    Also, Nice article picture 😀

    • Mudassir Shahzad

      Thank you shahzad. Appreciate it :)

  2. Thomas HENRY

    We have a JSF monolith and wish to deploy angular, monolith has become a beast. Vendor proposal is to break up monolith into containers, maintain JSF UI. I have requested that we stand up angular/container microservice environment, maintain/freeze monolith, and develop/migrate to new environment over 2-3 years (agile) to tske advantage of process improvements, etc. Big pushback due to security involving redirects between old/new environs. Thoughts?

    • Mudassir Shahzad


      Remember, microservices is not the solution to every problem. Sometimes, having a “modular” monolith is better than microservices based architecture. The thing with microservices is that they come with their own infrastructural requirements which most companies avoid because of the cost.

      Now, keeping in mind your situation, the idea here is to perform an incremental migration, in order for it to be as smooth and painless as possible. Attempting to do it all at once will be a suicide mission— on one hand, no one in its perfect judgement will be happy to deal with a ‘big-bang’ integration that this kind of migration implies.

      The approach I recommend and that have worked well for me, is to avoid rewriting the existing production code, at least until an actual problem is found or a new feature is to be delivered. Try to start building new services around the existing system in a more reactive style of development, only rewriting the old internals if and when needed, not sooner!

Submit a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.