Monolith vs Microservice

There has been a lot of discussion over the last few weeks over Monolithic architecture vs Microservice architecture. If you haven't heard it, it was sparked by an article from Amazon Prime team discussing a move in their stack from Monolith to Microservice architecture. One of the reasons I found this very interesting, is because it seems to go against some of the key selling points of AWS: decouple your infrastructure in the cloud for improved scalability. All in all it was interesting read. (See more here: https://www.thestack.technology/amazon-prime-video-microservices-monolith/).

To give a quick introduction:

• Monolith - could be described as a gigantic codebase with closely couple components. For example, a single backend server may handle all of the routing, business logic and CRUD operations that may take place in the application.
• Microservice - is the opposite of a monolith, it is a lot of different components which may reside on their own infrastructure. In this instance, a microservice may seperate the business logic into different components that are focused on a task. But the key difference is loose coupling.

So why is there a big discussion?

Well each of these approaches has its pros and cons...

Monolith advantages:

• Easier to get up and running.
• Can be simpler to comprehend with a smaller codebase.

Monolith disadvantages:

• Difficult to maintain when large codebases get exceptionally large.
• Can have cascading failures between closely coupled components.
• Limited options with scaling as it is one giant unit.

Microservice advantages:

• Easier to maintain components independently.
• Easier to comprehend what different components responsibilities are.
• Easier to reduce the risk of a cascading error as each component has its own concern.
• Easier to scale components independently, which can reduce overall cost of ownership.
• Easier to avoid vendor 'lock-in' as components can be repackaged and moved elsewhere.

Microservice disadvantages:

• Due to the increase in provisioned infrastructure (such as automated code pipelines), there could be an increase in cost of ownership.
• Can be a learning curve for teams not experienced in microservice architecture.
• Additional security around component transactions.

In my time working in various roles around software development, I have seen all sorts of architectural patterns gigantic monoliths, monoliths microservice hybrids, system of systems etc. I have also seen the benefits and disadvantages of both.

Overall, in many cases there is not one clear choice for every situation. For example if you have critical workload which needs near-real time updates, strong failover capabilities and high availability decoupling your infrastructure into microservices could be the solution. However, if your building a web application for a local shop that doesn't have a dedicated DevOps team to support their production application having a microservice architecture might be too much.