Microservices are a collection of small monoliths

A Microservice is a small monolithic application 💥💥

This post is originally posted at petran.substack.com

In this post, we’ll talk about microservices architecture and specifically what is a single microservice unit.

Let’s dive 🥽🥽

Microservices pattern are on hype these days.

With all the latest technologies like Docker, Kubernetes, CI/CD tools, and many more, we can easily implement, monitor, scale and deploy Microservices.

Microservices are here to solve issues that Monolithic pattern was not so good like independent deployable, modularity, scaling, cohesion, coupling, and many more.

Despite the help of the latest technologies, the art of designing and building monolithic applications is essential and relevant.

The truth is that Microservices are Small Monoliths

If we can’t build proper Monolithic Applications we can’t build a successfully implemented Microservices architecture.

The best quote I have read in the last few days :

If a team can’t build a proper monolith modular application Microservices pattern is not the solution to team issues

Design And Create Modules on Code Base

✒️ Design and Build Monolithic Applications On a Microservices Environment

Bounded Context

Every Microservice must be built around a well-defined bounded context

A bounded context is the boundary that surrounds all Microservice functionalities.

Architecture

Select and constantly bind your code base with an architectural pattern such as:

• 3 Layer Architecture

Design an Application with 3 Layer Architecture

• Hexagonal architecture. The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters. This makes components exchangeable at any level and facilitates test automation (Source wiki)

Code reviews

Add code reviews to the team’s process. We can catch functional and domain issues with code reviews before the code goes into production.

Inspection is up to 20 times more efficient than testing

Overall Code Base Design and Structure review

1. Review the overall design and structure of your codebase based on your chosen architecture on a regular basis, such as every 2 weeks, 1 month, or every sprint.
2. Check and document if and why your code base is getting a better shape or not.
3. Make adjustments that are needed to evolve your code base to a better shape.