• Microservice Architecture is when you break your system/problem down into a set of independent, cohesive, low-coupled services.
  • These services are often web services, but they don’t have to be. They just need to communicate over a network or IPC mechanism to be considered microservices. In essence, they just need to be seperate processes.
  • Each service can be developed in a different tech stack, and can be scaled independently.
  • If one service goes down, the entire system doesn’t go down with it.
                                                        
  Service1                                    Service2  
 (Process1)    ◄─────────────────────────►   (Process2)                         
                          IPC                           
                       Mechanism
                    (usually HTTP)

Introduction

Microservice Architecture is basically when you make each of your components a cohesive, low-coupled, independent service. The service is used by other services often via HTTP calls, however other inter-process communication mechanisms can be used as well.

Advantages

When each of your components is a service:

  • You can implement each in a different programming language, use different libraries, and just a different tech stack in general.
  • You can scale each service independently. If one service is getting more traffic than others, you can scale that one more.
  • If one service goes down, it doesn’t take the entire system down with it. This is an increase in resilience.
    • This is assuming there are multiple instances of the downed service.

Furthermore, you get the following quality stemming from the fact that microservices are small, cohesive, low-coupled components:

  • You can develop and test each service independently.

Vs Monolithic Architecture

In a Monoithic Architecture, all components are in one big process/program/service. Sometimes, especially in the beginning of a project, it is just easier to have all components go into the same process/service. It often makes deployment easier (though tools/concepts like IaC make deploying microservices quite easy as well).

However:

  • You cannot develope different components in different tech stacks.
  • You cannot easily scale different components independently. I say “easily” because you can implement your own scaling system within your monoithic application, however using microservices provides re-usuable scaling solutions (Kubernetes, Amazon EC2, Amazon Lambda, etc).
  • If one component goes down, and you have not implemented your own auto-scaling/redundancy system, the entire system goes down.

Non-Web Applications

You can use a Microservice Architecture for apps that aren’t web/cloud based. Imagine a desktop app. You split each component into a process, and the components/processes communicate via some sort of an IPC mechanism.