Microservices #1 best practice: start monolithic

A monolithic application is a collection of tightly coupled services bundled into a single application. A microservices-based application is a collection of services that are deployed and scaled independently.

A monolith generally uses a single tech stack. Microservices can use multiple tech stacks, allowing teams to operate autonomously, which is valuable in larger organisations.

You don’t need to build your product like it’s the next Uber or Netflix. That’s a waste of resources. All the tech giants started with a monolith. Here’s why almost every product should do the same.

It significantly reduces time to market

With a monolith, you don’t have the burden of orchestrating many smaller applications, so you can focus on results.

In the early stages of a product, business requirements change often. Fast iterations and easier development allow you to test the demand and direction of a product or feature.

It reduces complexity and cost

Intra-service communication needs to be orchestrated, and a proper solution may double the cost and time it takes to ship, particularly for products in their early stages.

If the solution is not thought out, you end up with a distributed monolith, microservices that are tightly coupled and heavily dependent on each other. That’s the worst of both worlds, and it can cost a lot more in the long run.

It doesn’t affect your scaling that much

It doesn’t have to be monolithic vs. microservices. It can be monolithic with microservices.

You can identify bottlenecks in your monolithic application and transition those to a microservice. If you built the monolith with that in mind, you should be able to extract the part that’s slowing things down and optimise it as a standalone service.

It allows time for reflection

Navigating software is not always straightforward. Successful products require adaptability. There are challenges and decisions that will change the course of a project.

With a battle-tested product and first-hand insights into what went right, what went wrong, and how users actually interact with your product, you can do a much better job converting a monolith to microservices than starting with microservices from the get-go.

It simplifies debugging

Since a request takes place in a single process, it’s a lot easier to follow it and find an issue.

With microservices, you need to monitor each service and the contracts between them. The bug could live in any service involved in fulfilling the user’s request. A monolith also allows easier onboarding, developers can just follow the request’s lifecycle instead of studying architecture diagrams.

You probably don’t need microservices

The first best practice of microservices is that you probably don’t need them. A monolith does have its disadvantages, the main one being that the larger it gets, the harder it is to maintain. But for most startups, a monolith’s advantages far outweigh the downsides.

If you want to read more on this, check out Atlassian’s Microservices vs. Monolithic Architecture.