Microservices to Maximize an MVP mindset

When you think about the MVP approach, probably the first thing that comes to mind is quick and dirty, building fast, re-using and extending existing models and APIs.

You might want to do short iterations in order to get initial feedback and validation on your solution, understanding what works and what isn’t working.

Everyone knows that this comes with a price — technical debt.

In the early product and engineering stages, you might have to accept this price. Spoiler — using the microservices mindset for MVP can even help you avoid it.

Microservices architecture and MVP may sound like a contradiction, one is quick and the other is much more robust. When considering the microservices guidelines, implementing them in MVPs and even using actual microservices for MVP can have a huge impact.

Let’s see how you can apply the microservices mindset for MVPs.

How to use microservices for MVP

I’m leading one of the squads that focus on user engagement at Augury, when developing a new feature we always aim for high impact to the user, while considering the effort. As a result, it’s highly important for us to consider all implementation options and make the ‘right’ decision.
Let me illustrate this…

Phase One — Preparing for scale

About a year ago, our squad PM realized that there was a need for new capabilities in our product.

The requirement set was very initial, the solution required more validation and there were still open questions.

We wanted to start with a small and lean MVP, learn and improve in the next phases (like we always do). We had two options in hand:

• Extending the existing model + data collections
• Opening a new technical domain (as part of the monolith or new microservice)

At this point, opening a new microservice wasn’t that trivial. We were only extracting more mature flows into microservices, the flows whose requirements were stable and there to stay.

In addition to the fact that the domain boundaries weren’t clear, we chose to extend the existing model + data collections, while creating separate APIs in preparation for the next stages. When the domain would become clearer, it would be much easier to separate the code into a different domain and microservice.

Phase Two — MVP mindset change after product-market fit

A few months passed and our company reached product-market fit — our product has a solid user base and gives high value, our engineering team is scaling up with new developers, and the infrastructures are more robust.

This also brought new challenges:

• Onboarding new developers into a complex system
• Lots of developers working on the same areas
• Enabling domain autonomy
• Cost of technical debt

After analyzing user behavior and getting users’ feedback on our solution, we wanted to have another iteration — extending feature capabilities. We now had a better understanding of the new domain and more confidence in our solution.

The mind shift — microservices can increase dev velocity even in MVPs and early product stages.

Even though there were still open questions and unknowns about the future requirements of the feature, we understood that opening a new microservice for our new domain would make sense:

• Product reaching maturity and product-market fit enables us to start defining our domain boundaries using DDD (Domain-Driven Design) patterns
• Having more users and more developers requires more robust infrastructures
• Microservices enable domain autonomy that increases dev velocity
• At this point creating a new microservice was very trivial and required minimal effort

So we decided to migrate existing logic to a new service, and extend feature capabilities.

And now comes the best part, we learned from this and started to look at MVPs from a different perspective…

Our takeaways

The second iteration was very insightful, we realized that it was easier to implement our new feature in a new microservice, even on our first MVP and even when our ‘new’ domain requirements weren’t clear and there were still open questions.

Cost of deletion

In some cases, after the first iteration we would realize that there wasn’t enough impact and usage of the new feature and we decided to remove it from our product.

• When assessing the new functionality effort, we need to add the cost of deleting it from the system
• Dedicated service enables us to quickly remove it, without the need to cherry-pick the logic of our feature from the existing domain

Cost of the second MVP — refactoring cost

On the happy path, the new domain becomes clearer, we understand the flow and requirements better and want to extend the feature capabilities. If we want our domain to be clearer and more robust, we need to move it to its own microservice.

Opening a new microservice in the 2nd iteration was more costly, we’d need to migrate our code and data into the new service. Opening a new microservice in the first phase would eliminate this overhead.

Cost of technical debt

Adding complexity to already complex areas and services, usually leads to technical debt — extending existing models and flow without clear boundaries can cost us in dev velocity:

• New hires learning a new system have a lot on their plate, mixing logic between flows/domains can be very unclear and consume more learning time
• Harder to expand in second iterations

Domain autonomy power

Working in a separate domain can give you

• More power and enable velocity
• Autonomy and flexibility

New service for a new feature domain — Win-Win

• If your company is scaling up
• If there are multiple developers working closely
• If there is a solid infrastructure

Then you might want to consider starting using microservices in MVPs. Leveraging the autonomy and flexibility they bring without the overhead of migrations and for quick removal.

Using Microservices as a mindset

Microservices architecture has benefits, but you can’t always afford a full-blown microservices infrastructure.

When you’re at the early stages, and you don’t have the resources to create and orchestrate microservices, you can still follow some of the mindset in order to improve your MVPs, and more.

Think about the domain autonomy, the cost of deletion and the cost of second iterations — separation of routers, logic and creating a new data collection without re-using existing ones.

This might cost you a little more, but it’ll enable self-contained areas that help you extend and remove code faster and more efficiently.

And the best part, when you reach a certain product and infra maturity you’ll be able to migrate it to microservices!