Monolith vs Microservices... which is best?

The answer is... it depends!

Follow the thread to know a little more about application architectural models and find out which one is for you.

Let's start with monoliths, the *traditional* way of web development.

In this kind of web architectural pattern, every line of code (be it business-logic, front-end, or else) is written inside a big box and deployed all-together.

Seems awful right? You couldn't be more wrong.

With little organization and application of design principles, a monolith can be maintainable and don't need to comply with specific problems.

The one thing that you should know is just to apply the hexagonal architecture either called ports and adapters https://alistair.cockburn.us/hexagonal-architecture/

The basic principle is to define interfaces (adapters) between all domains of your application (ports) and separate them from your business logic.

A lot of frameworks are perfect for getting started, but they don't comply well with these design principles like Django and Rails.

They need to be tweaked a little. But by following these simple principles, we will have an easy to use framework with a lot of built-in features and fast development.

But unfortunately, this will not be true forever. At some point, the monolithic approach will show its limits.

With an increasing amount of features the techincal debt and development cost will inevitably grow. In addition some problems with scalability will arise and the solution will become difficult to maintain.

This is the perfect moment to shift to a microservice approach.

Microservices is a paradigm that leverages the physical segregation of components of different business logic areas.

Where you once had interfaces to correctly route your business logic inside your code application, in a microservice approach the interfaces will become APIs.

With each microservice decoupled from the others, you are free to deploy, scale, and, develop without worrying about the other microservices.

But this is where microservices complexity kicks in.

Everything will be loosely coupled so things like observability and logging will be critical factors to take into consideration.

And with service dependencies, you will have to take into account the availability of your services, as you don't want to lose that precious request.

In addition, to achieve true segregation each microservice should have its own data layer.

Meaning that business logic and database should be architected with this principle in mind and it's not always a very simple thing to do.

So more than a battle between two architectural patterns I see two different approaches that solve very specific problems.

And before committing with one or the other you should be checking what problems are you facing right now to determine the best approach to follow.

Hope you enjoyed this. I know we're only scratching the surface here, so if you want to discuss or have some questions reply to the thread or DM me.

I'm always available to have a nice chat!

Cheers!