Micro-services Architecture

Origin: Natural evolution of service-oriented architectures (SOA)

Breakdown: the services are small, independent and very weakly linked business modules. They can be deployed independently, and are responsible for their own persistence.

API Orchestrator (Gateway): This is the entry point for all customer calls. In other words a service router.

When to use this style of architecture:

  • Large applications that require fast deployment.
  • Complex applications that require high scalability.
  • Applications with large domains or a large number of sub-domains.
  • An organization made up of small development teams.

Big advantages of this architecture :

  • Independent deployments: you can update a service without having to redeploy the entire application and perform a restore or restore in progress if an update is a problem. Bug fixes and feature releases are easier to manage and less risky.
  • Independent development: A single development team can create, test and deploy a service. As a result, innovation is continuous and the rate of releases is higher.
    Small, specialized teams: Teams can focus on a single service. Because each service is more limited in scope, the code base is easier to understand and new team members can integrate more easily.
  • Error isolation: If a service fails, it does not impact the entire application. However, that doesn’t mean you get resilience from scratch. You should always follow good resilience practices and design models.