Should I go for microservices or a monolithic application?

Building a product that works is like climbing a mountain. You go step by step, and enjoy the journey.

Intro to microservices

Microservices have been around for some while, and are a pretty well known pattern to build applications and digital services. To put it in simple terms, a microservices architecture decouples individual components of a service, basically each component becomes an application of its own. All microservices are connected using defined APIs, making it possible to have autonomous teams work on individual pieces of the application, mostly without breaking each others functionality. Netflix for example states that it uses about 700 microservices to provide their streaming service.

A lot has been written about the options to convert from an existing monolithic application to microservices, e.g. using self-contained systems, or the strangler application pattern as described by Martin Fowler, as well as the benefits of microservices, and books have been written about how to build and design microservices.

While microservices might now sound like the holy grail to an architecture that supports agile practices (and to some extent it does), you should apply it in the right situation for the right problem, with the target outcome and environment in mind. Hence this article brings in the perspective of product development and the lifecycle of your product from idea to scalability.

On the Journey to Microservices

When you read about success stories of converting to microservice architectures, you will realize that most of them stem from product companies, which all have a business model, where the core relies on a digital product/asset that is responsible for the majority of their revenues.

With this in mind, we shall remind ourselves that these companies have been on a journey of hundreds of iterations in their product and business model.

They then arrived to this architecture as it solved some of their needs. In most cases you start to switch from monolithic to microservices when you have proven that you’re solving a problem. When they did hit product market fit. “Product/market fit means being in a good market with a product that can satisfy that market”, as Marc Andreessen puts it.

This allows them to have independent teams, that work on individual services, scale team and product without compromising too much on speed (think Bezos’ two pizza rule).

They all share common goals and a vision which is closely tied to the success of the product and hence to thebusiness model. Since the work and effort is tightly connected to the success of the business, it is natural to continuously invest in the product and the team that delivers it as you thrive towards delivering maximum business value per product iteration.

Then all the decoupling, autonomy, scalability of microservices can bring more value in shorter time. It is an investment in a long-run game.

Microservices are not a free lunch — Benjamin Wootton

Microservices and the early state company

On the other hand, microservices inherently introduce added complexity, and operational overhead. You need to have the right people, stable teams working with a DevOps mindset and the right skills. ”Microservices are not a free lunch”, as said by Benjamin Wootton. Martin Fowler rightly says: “you must be this tall to use microservices”, basically advocating an approach where you slowly transition into microservices, as you build internal expertise and team.

All this overhead can slow you down in the initial phase, in the search for a scalable business model, in the phase where you try to reach the MVP, and get customers excited about your product.

In this phase, speed is key. First to market means early customer access. And even more important: the shorter your build, measure, learn feedback cycle is, the more you reduce the risk of building something nobody wants.

In an early product phase, try to reach product market fit first. Take shortcuts. Do things that don’t scale. Do things manually. Premature optimisation binds resources that could deliver more direct customer value. Ask yourself whether you rather want a working business model that does not scale yet, or whether you want to scale a business model that doesn’t work.

Do things that don’t scale — Paul Graham

So what shall I do now?

First, make sure you understand the benefits and drawbacks of microservices, and consider the investment you need to make. Make a plan and answer the following questions for yourself:

1. Are you building a product that is the core of your business model? If it is a project that you hand off to someone else later, that you deliver to someone else, make sure you agree with them on your strategy.
2. Do you have a stable team/stable teams, which will continue working on the product until you sunset it? If not, the added complexity will slow you down and the investment in the teams will most likely not pay off, if you reshuffle them, and assign them on other projects or tasks.
3. Do you plan to expand your team and product, because the market demands your product to grow and scale? If you plan to just launch it, and then see what comes, without a plan on how you grow your product beyond launch day, why would you prematurely optimize.
4. Do you have the right people with the right skills? You will need people who bring all the high-class skills to manage, build, design, operate complex distributed systems. If you’re not willing to build a stable team around the product, most likely you will not invest in the team.
5. Do you have a business model that works and your product at the core? If your business model is not proven yet, consider that you are trading scalability for speed at a stage, where speed is key, where you want to learn fast, iterate quickly. A complex architecture might be adaptable to change, but bringing it there might be an initial investment that slows you down.

Thoughts, Ideas, Comments?

I tried bringing in the perspective of business building into the discussion of microservices. As developer and entrepreneur, I am passionate about building products people love. I think that a lean and agile approach to building products, services and companies is a way to deal with the inherent complexity of today’s business challenges. Leave your thoughts and ideas in the comments.