What we need is a hybrid solution that keeps the advantages of both architectures.

Motivation

Some projects are currently moving back from a Microservice architecture to a Monolith architecture ( Segment, Istio, InVision, …). Furthermore, greenfield projects ask themselves if they have to start with a Monolith or with a fleet of Microservices. The  Microservice Architecture adds a lot of complexity that most of us can’t easily manage, and Monoliths can’t follow the growth of an organization.

Advantages of Monoliths

  • Better availability (in-process inter-service communication)
  • Debugging
  • Testability
  • Observability
  • Cheaper to develop
  • Simpler to deploy

Advantages of Microservices

  • Simpler team partitioning
  • Better team autonomy
  • Faster maintenance
  • Tailored scalability
  • Faster release of new features

The goal of this article is to describe a Solution for an architecture that is both easy to grow and higly available, something between a Microservice and a Monolith.

Forces

According to the  Reactive Manifesto :

We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

#microservices #monolith #kubernetes #patterns

Monolith or Microservices? Neither, Combine Both With Integrated Microservices
1.05 GEEK