Is Microservice design pattern or architecture?

Question

After doing rigorous research and analysis I finally arrived to a point which is confusing me "Is Microservice a design pattern or architecture". Some say it's a pattern evolved as a solution to monolithic applications and hence design pattern And some confirms no doubt it's an architecture which speaks about their development, management, scalability, autonomous & full stack. Any thoughts or suggestions I welcome to get myself clarified.

Answer 1

Microservices can be best described as an architectural style. Beside architectural decisions the style also includes organizational and process relevant considerations.

The architectural elements include:

1. Componentizing by business concern.
2. Strict decoupling in terms of persistence.
3. Well defined interfacing and communication.
4. Aim for smaller service sizes.

The organizational elements include:

1. Team organization around components (Conway's Law).
2. Team size limitations (two-pizza team).

The process relevant elements include:

1. Less centralized governance.
2. Smaller, more frequent releases.
3. Higher degree of freedom for technology decisions.
4. Product oriented development (agile, MVP, lean, etc).

For more details I recommend reading the articles from Martin Fowler.

Answer 2

I would describe it as a software architectural style that require functional decomposition of an application.

Usually, it involves a monolithic application is broken down into multiple smaller services, each deployed in its own archive, and then composed as a single application using standard lightweight communication, such as REST over HTTP or some async communication (of course, at some point micro services are written from scratch).

The term “micro” in microservices is no indication of the line of code in the service, it only indicates the scope is limited to a single functionality.

Each service is fully autonomous and full-stack. Thus changing a service implementation has no impact to other services as they communicate using well-defined interfaces. There are several advantages of such an application, but its not a free lunch and requires a significant effort in NoOps.

It's important to focus on that that each service must have the properties of:

• Single purpose — each service should focus on one single purpose and do it well.
• Loose coupling — services know little about each other. A change to one service should not require changing the others. Communication between services should happen only through public service interfaces.
• High cohesion — each service encapsulates all related behaviors and data together. If we need to build a new feature, all the changes should be localized to just one single service.