Monolith vs. Micro-Services – What?

When you’re first starting out building your product, your developers are going to have a choice to make about how to build the application. There are (generally) two ways that applications get built: Monolith and micro-services based.

In this article, we will walk through what each of these terms mean, the tradeoffs of each approach, and how to think about the decision with your development team.

What’s a Monolith Application?

mon-o-lith (n) – Something, such as a column or monument, made from one large block of stone

Just as with sculpture, an application built as a monolith is built as one single application. Almost every application starts out as a monolith, particularly as you are figuring out whether or not you have a product that people will pay for.

Here’s some specific characteristics of a monolithic application:

  • It usually lives in a single source code repository
  • It is deployed all at one time
  • The different parts of the application are more interconnected
  • The application scales or doesn’t scale as a whole

What’s a Micro-Services Application?

Micro-services are a holdover from the architecture of Unix / Linux, the operating system that most of the entire internet runs on, as well as the computer you’re probably using right now.

Micro-services as a philosophy means that you build something to do one thing, and only one thing, and do it very well.

For example, if your application sends out emails, you might have a tiny service whose only job in life is to send emails to your users, while another service might only send push notifications to your users. You can get as specific as you want with each service you define.

Here are some specific characteristics of a micro-services application:

  • Each of the services is deployed separately
  • Each service is independently testable without any knowledge of how it is being used by the rest of the application (sometimes called encapsulation or separation of concerns).
  • Each service has a clearly defined API for how to interact with it
  • Each service can be scaled independently of the other services

Pluses and Minuses

It’s hard to summarize all of the pluses and minuses of each approach, but here’s a starter list

  • Monoliths are great for prototyping / very early versions of the app particularly when it’s a very small team (1-2)
  • Monoliths are much easier than micro-services when automating deployment in the early going
  • As the team grows, monolith development can become difficult to manage as your developers will start running into each other in the code and / or hitting dependencies on each other
  • Monolith applications are less complex to deploy
  • Micro-service apps are easier to test because you can test discrete pieces without dependencies on the rest of the app
  • Micro-service apps make it easier to split up work amongst a growing team, as developers can own fully the services they’re working on
  • With micro-service apps, performance problems in one part of your app don’t necessarily affect other parts of the app and are (for the most part) easier to isolate and troubleshoot

Generally speaking, micro-service apps are more complex to MANAGE but much easier to SCALE. So what’s the right path for you? Most products start out as monoliths and then move to micro-services over time.

There’s a school of thought that says you begin with the end in mind, meaning that you start with a micro-services architecture from the beginning. My opinion is that you move to micro-services as soon as you have achieved early product-market fit. Until then, a micro-services architecture usually results in slower development and more wasted work.

Just Remember

Software applications are built using a monolith (one big app) or micro-services (lots of little apps). Monoliths are usually appropriate while you’re figuring out the market for your product, but once you see traction you should immediately begin to look at how you can break things up into micro services.

Your Assignment

In your next meeting with your development team, ask them if your application is monolith or micro-service based architecture. Have them walk you through the thinking for why the decisions have been made the way they’ve been made up to now, and then have a discussion about how they see the application evolving.

Whiteboards and drawing things out with your team will create a new level of understanding for you of how your team has built your application and how they think about the future. As always, ask as many questions as needed with no fear of sounding dumb.