Skip to main content

Microservices

Description​

The Microservices pattern involves breaking down a monolithic application into smaller, independent services that communicate with each other over a network. Each service is responsible for a specific task and can be developed, deployed, and scaled independently. This pattern allows for greater flexibility, scalability, and resilience compared to monolithic architectures.

In order for a set of systems to be considered microservices, they must adhere to the following principles:

  • Independently deployable: Each service can be deployed independently of the others.
  • Independently built: Each service can be developed by a separate team.
warning

If your systems are not independently deployable or built, they are not microservices. What you have is called a distributed monolith, which is an extremely complex and difficult-to-maintain system. More organizations get this wrong than you might think. Be sure to understand the principles of microservices before you start breaking down your monolith.

It is my opinion that no startup should start with microservices. The complexity is not worth it until you have a large enough team to manage it. Start with a monolith and break it down as you grow.

Diagram​

Microservices are clearest when compared against monolithic architectures.

Monolithic vs Microservices Architecture

The combined functionality of a monolithic application is broken down into smaller, independent services that communicate with each other over a network. The set of microservices can be developed, deployed, and scaled independently, but deliver equivalent functionality.

When to Use​

Microservices are best suited for large, complex applications that require flexibility, scalability, and resilience. They are particularly useful in the following scenarios:

  • When you need services to be independently deployable and scalable because of highly variable loads.
  • When you have multiple teams working on different parts of the application and want to avoid conflicts.
  • When you are no longer able to scale your development team because of the complexity of the monolithic codebase.

That last point is the main reason why organizations switch to microservices. As the codebase grows, it becomes increasingly difficult to maintain and scale. Microservices allow you to break down the application into smaller, more manageable parts that can be developed and scaled independently. This pattern has a lot more to do with organizational decoupling than it does with technical requirements.

Advantages​

When done correctly microservices are extremely powerful and flexible. They allow you to:

  • Independently build, deploy, and evolve services.
  • Scale independently based on demand.
  • Simplify development by breaking down complex applications into smaller, more manageable parts. Each service tends to be simple and easier to build and maintain.

Disadvantages​

When done badly microservices can be a nightmare that is impossible to maintain. Even when done correctly, microservices are more complex than monolithic architectures. Some of the disadvantages include:

  • Managing the network layer can get complex. Especially when you have a lot of services communicating with each other.
  • Correctly decoupling the services so that they can be updated and deployed completely independently of each other requires significant architectural expertise. This is not a pattern for junior developers.