Microservices #1 best practice: start monolithic

You don’t need to build your product like it’s the next Uber or Netflix; it’s a waste of resources. All the tech giants started with a monolith. Here are some of the reasons almost each product should start as a monolithic application:

It significantly reduces time to market

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

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

It reduces complexity and cost

The intra-service communication needs to be orchestrated, and a proper solution may double the cost and time it would take for your product to be shipped, particularly for products that are in their early stages. 

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

It doesn’t affect your scaling that much

Technology can be bent; it doesn’t have to be Monolithic vs. Microservices, it could be Monolithic with Microservices.

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

It allows time for reflection

Just like in life, 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 in its entirety takes place in a single place, it’s a lot easier to follow it and find an issue.

Unlike microservices, where you need to monitor each service and the contracts between them, the bug could reside with any service involved in the fulfilment of the user’s request.

This also allows easier onboarding, as developers don’t need to study diagrams to understand what’s going on; they can just follow the request’s lifecycle and the application’s behaviour.

Conclusion

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

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

Here at Oxentree we build cost-effective solutions that can scale (up to millions). We’ll handle the technical direction so you can focus on what really matters: product strategy.

Let’s talk about your MVP or startup, email us at contact@oxentree.com or use the form below.