Monolith Here are a few of the benefits you get when moving from Monolith to Microservices.

  • Decrease your release cycle from weeks to hours.
  • Scale your system without compromising your release velocity.
  • Increase resilience delivering impeccable customer-experience.

When considering the move to a Microservice architecture (aka Microservices), it’s important to consider its lineage--Service Oriented Architecture (aka SOA) and the Monolithic architecture (aka Monolith).

Microservices, Monolith and SOA

Monolith

Monolith

Monolithic architecture is a software architecture encompassing the entire application business logic in a single large codebase.

Although it's considered the traditional (and sometimes the less-advised) strategy, Monolithic architecture holds many benefits and may well be the right choice for some engineering teams.

SOA / Distributed Services

SOA

SOA, though a different style of software architecture than the Monolithic architecture, is very closely related. One can consider SOA the duplication of a Monolith across a handful of services. SOA is usually the first step when breaking away from a Monolithic architecture en-route to a Microservice architecture.

While there are differences between the two styles, it is the author's opinion that they do not merit a deep discussion. When we reference a Monolithic architecture style in this article, we also include SOA and sometimes use both interchangeably.

Microservices

Microservices

Microservice architecture was born from the pitfalls of the Monolithic architecture.

Microservices--also known as the Microservice architecture--is an architectural style that structures a system as a federation of a relatively high number of typically smaller services. The nature of the architecture makes individual services highly maintainable, testable, loosely coupled and independently deployable.

Each service is organized around a well defined business logic. Often located on different machines, they communicate via either synchronous and/or asynchronous messaging, based on protocols such as REST, , Protobuff and the like.

Microservice gRPC, REST

The Microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications as well as independent roadmaps and deployment schedules.

Conway’s law1 usually works well in organizations that practice Microservices, when teams are mapped to services.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

— Melvin E. Conway

An organization that espouses the concepts of extreme ownership and communication will succeed with the microservice architecture, as each individual remains accountable for their service.

Monolith Vs Microservices

While Monolithic architecture provides agility and simplicity in the early days of the software life cycle when the architecture is simple, it becomes a nightmare to maintain and evolve as the software matures and architecture becomes more complex and rich with features.

Microservices on the other hand, can be overkill to start with, but become beneficial once the software becomes feature rich, enabling agility and making the software easy to evolve.

Microservice Vs Monolith Vs SOA

SOA Vs Microservices

There are many similarities between SOA and a Microservice architecture. While each service in SOA looks very similar to a Monolith, it also shares many of the characteristics of a service in a Microservice architecture.

It is the author's opinion that the key difference between the architecture is the number of services that impose a different set of challenges. As the invisible rule, a human can manage up to ~10 elements in their head or in a spreadsheet, but when the number grows higher than 10, manageability becomes a challenge.

Microservice Orchestration

When 'manageability' becomes challenging, is where Microservice orchestration tools like Kubernetes, Docker Swarm, Docker Compose, AWS ECS and others come into play. Once you can’t manage the services and have to rely on a third party software (e.g. Kubernetes), quite a few other challenges are introduced.

If you consider the overhead of 'manageability' compared to the benefits of scalability and velocity at scale, it is worth it (if in fact, you do have as many services to manage).

Microservices and Monolith side-by-side

The are some of the more important architectural properties that may influence an architecture choice:

     MicroservicesMonolith
Early velocityPoor        ExcellentRead More
Velocity in maturityExcellentPoor  Read More
Future proofExcellentPoor Read More
High availability & resilienceExcellentPoor  Read More
TestabilityChallengingExcellent   Read More
ManageabilityChallengingExcellent  Read More
PerformanceExcellentGood  

Summary / Conclusion

There really aren’t as many architecture choices as it may seem. Microservices are overkill and can even inhibit velocity in the early stages. This is especially true for new teams and projects with no pre-existing infrastructure. It's better to go with a Monolith to get to the first prototype.

However, engineering teams can save themselves trouble down the road by starting with a microservice-ready monolith. Early on, you’ll start chopping off pieces to parallel services (essentially the SOA route), quickly moving to a Microservice architecture. Here, the overhead becomes smaller when compared with the benefit you earn when the software matures. Start with Monolith and gradually move to Microservices