Monolith or Microservices?

Recently I have been asked a lot about my opinion on monolith vs micro-services, so I wanted to summarize my thoughts in a short post.

A monolithic service is a software architecture in which all the application’s components are tightly coupled and interconnected, usually within a single codebase and deployed as a single unit. As a result, the entire application runs as a cohesive unit, including the user interface (API layer), database access layer, and business logic.

In a monolithic service, all components share the same runtime process and often the same database, making it easier to develop, test, and deploy changes to the application. However, as the application grows and becomes more complex, it can become increasingly difficult to maintain and scale since any change to one component requires the entire application to be redeployed.

The opposite of a monolithic service is a microservices architecture, a software development approach where an application is broken down into smaller, independent services that can be developed, deployed, and scaled independently. Each service is designed to perform a specific business function and communicates with other services through APIs or other messaging technologies.

In a microservices architecture, services are typically deployed in containers and managed by orchestration tools like Kubernetes or Docker Swarm. This approach allows for greater flexibility, scalability, and resilience than traditional monolithic applications.

Some key characteristics of a microservices architecture include:

  • Service boundaries: Each service has a well-defined boundary and performs a specific business function.
  • Decentralized data management: Each service manages its data rather than relying on a central database.
  • Communication: Services communicate using standardized APIs, such as REST or GraphQL, or through messaging technology (such as SQS or Apache Kafka).
  • Independently deployable: Each service can be deployed and updated independently of other services.
  • Resilience: The system is designed to handle failures in individual services without affecting the overall application.

On paper, microservices architecture offers more benefits than a monolith, but is it always the right choice? Well, it depends. It would be best always to try to find the right balance for your company and team for the right stage.

If you are starting a new company or building a new product from scratch and need to prioritize time-to-market, I would suggest going with a monolithic architecture because it’s way quicker to develop and reach a working POC version that can be validated with potential customers, increasing your ROI. Then, when the company grows, it is time to start investing in the overall architecture and creating internal services responsible for smaller tasks. It is ok to run as part of the same process (monolith?), and this is when the service boundaries come into play. When you expect to start seeing a larger scale, you should run performance testing, identify your bottlenecks, and address them individually. Sometimes, a piece of your monolith will move into a dedicated service that can scale independently (horizontal scaling).

Another important consideration is the company structure. Usually, different teams are responsible for other parts of the codebase. Therefore, they should have their services and packages to give them the proper ownership to build, maintain and deploy their code.

Once you reach this stage, it’s crucial to coordinate and keep firm ownership boundaries because now the real challenges of maintaining microservices are coming into play. Every change should be coordinated, done incrementally, and maintain backward compatibility until fully deployed – which, by definition, will reduce your overall velocity.

To me, simplicity is the key. Both architectural approaches have pros and cons. You can reduce multiple pain points and benefit from both worlds by designing the right architecture for your product, working backwards from your requirements.

Do you want to learn more about how to architect your product or have a chat about the challenges you are facing and get expert advice on the best way to solve them? Drop me a message.

– Alexander

Oh hi there 👋
It’s nice to meet you.

Sign up to receive awesome content in your inbox, as soon as it is published!