Visionary. Value focused.

Microservices – when NOT to use?

For the last few years, Microservices has become a hot topic and many business are making their choice of moving into this software architecture.

Microservices is a major architectural pattern in the software industry. This architectural model can optimize your team’s speed by adjusting how they design and ship code.

That’s why, developers and business leaders can accomplish their projects in no time.

In my previous blog post, we have discussed briefly about microservices and what they can offer. But not all things are always the 100% right solution and microservices is not an exception. Here’s why.

Tl; dr;

Source Open Source For You

Microservices is a discrete software service, typically defined as breaking up a complex system into more manageable, smaller units of work that can be independently developed and deployed.

That’s why developers and business leaders who implemented the model can be able to solve complex system level problems easier by breaking it into smaller ones.

Microservices

Source: microservices.io

Microservices develop applications through small interlocking pieces of one giant whole. These are split into decoupled components that interact with each other via Application Programming Interfaces (APIs) and is developed and maintained “separately” from one another so updates don’t require re-doing the entire codebase.

Upon implementation, the model enables an organization to evolve its technology stack with continuous delivery or deployment of large, complex applications.

Though the key benefits of microservices are loosely coupled, independently deployable, highly maintainable and testable, and organized around business capabilities, it is also poses certain challenges:

• It is hard to design correctly. Takes you a lot of iterations to land on satisfying domain design and boundaries.
• It comes with a host of technical complexities.It multiplies the number of APIs, has complex transactions across several services and debugging distributed systems, and introduces network latency.
• It requires an organization shift to autonomous, cross-functional teams. Meaning frontend and backend developers, data platform engineers, QAs, product managers, and ops are all in a single team.
• It requires a change of process and practices. Microservice architecture’s success depends upon the capacity of organization and process to change.

When NOT to use it?

Microservices is not always 100% right solution for your products or fit for your team.

As it turns out, what works for largely complex programs doesn’t always work at a smaller scale.

In an interview, Daniel Bryant, a Chief Scientist at OpenCredo and a JAX London speaker, gets asked about this and he said:

“I get asked this question quite a lot, and it is difficult to give a definitive answer. However, situations where microservices may not be beneficial include:
– Working with a simple application domain
– Developing software with a small number of people in the team
– No problem/solution or product/market fit e.g. you are a startup that is still exploring your business domain and how to make money
– When the organisation is not embracing DevOps principles (i.e. see Martin Fowler’s Microservice Prequisites article).”

In addition, you also need to ponder on these practical points

• Don’t go full with microservices if you are uncertain of what you are doing. It can have unsuspected difficulties along the way. Next thing you know, you are grinding your development to a HALT.
• Don’t go for microservices when you don’t want to invest in more extensive logging and monitoring. Developers need to prepare for unfindable bugs or performance issues.
• Don’t go for microservices when you don’t know: where your bounded context boundaries lie; which parts of your application need to be scalable; or which modules will be very chatty.

Summary

Microservice architecture is an approach in designing software applications wherein some types of applications become easier to build and maintain when they are broken down into smaller parts which work together – each component is continuously developed and separately maintained.

The model enables an organization to evolve its technology stack with continuous delivery or deployment of large, complex applications upon implementation.

But it poses certain challenges:

• It is hard to design correctly.
• It comes with a host of technical complexities.
• It requires an organization shift to autonomous, cross-functional teams.
• It requires a change of process and practices.

You DON’T use microservices if:

• you are working with a simple application domain;
• you are developing a software with a small number of people in the team;
• you have no problem/solution or product/market fit – if you are a startup who’s still exploring your business domain and how to make money;
• the organization is not embracing DevOps principles;
• you are uncertain of what you are doing;
• you don’t want to invest in more extensive logging and monitoring;
• you don’t know where your bounded context boundaries lie;

By Tuan Nguyen