Dec 02, 2025

12 min read

Articles

What are Microservices? Monolith vs Microservices architecture.

Modern software development and IT operations

Cloud platforms and services form the essential infrastructure for DevOps and microservices, enabling the modern software development and IT operations ecosystem.

Before we get started, you might want to explore some related topics — they provide useful background that will help you get the most out of this post:

📺 Watch on YouTube: https://www.youtube.com/watch?v=JL3dHnlOZ8A&ab_channel=TelelinkBusinessServices

2. Monolith architecture

Overview

Most applications are built with a monolith design, meaning that all business logic, data layer, and UI (user interface) are integrated and deployed tightly together.

One of the biggest disadvantages of the Monolith design is scalability and reliability, more specifically, high availability. To set up the application in high availability, it needs to put another VM/container with all related services, business logic, data layer, and UI “under the same roof”.

Pros:

Easy to design and develop initially. Perfect for small and medium-sized applications.

Cons:

Complex for scale and maintenance. High availability and sizing complexity.
Feature development may cause stability and scaling issues. Complex change of schema and architecture.

A simple analogy

Let’s imagine a simple application with:

TIERING: two or three components: business logic (back-end logic), User Interface (front-end), and database.
RELIABILITY: The application is used by a team of 4–10 people.
AVAILABILITY: not mission critical and can be unavailable for more time than it’s available (meaning SLA is less than 50%).
AGILITY: nothing new has been added or updated (patched or hotfixes) for over a year or two.
RESILIENCY: data is easily recovered one way or another.

This will be a perfect example of an application designed with monolithic architecture.

Benefits of Monolith

Simplicity — Single codebase, easier to understand and navigate for developers
Easy deployment — Deploy one application instead of coordinating multiple services
Straightforward testing — End-to-end testing is simpler with everything in one place
Better performance — No network latency between components, faster internal communication
Easier debugging — A Single application makes it easier to trace issues and errors
Lower operational complexity — Fewer moving parts, simpler infrastructure management
Shared resources — Database transactions and data consistency are easier to manage
Faster initial development — Quicker to get started and build features early on
Better IDE support — Code completion, refactoring, and navigation work seamlessly across the entire codebase

3. Microservices architecture

Overview

Microservices — also known as microservice architecture — is an architectural style that structures an application as a collection of services that are:

Services are typically organized around business capabilities. Each service is often owned by a single, small team.

In a nutshell, “Microservices” is not a term we can define with a few words as a mathematical Lemma. Microservice-based application is a software design approach born from multiple requirements needed to design, operate, and sustain our applications in ever-growing demands.

A simple analogy

On the other hand, let’s imagine that we have another use case for an application or a stack of applications combined in one business platform where:

TIERING: Multi-tier process, application, service. For example, different UI for mobile users, web browsers, middleware stack, multiple back-end business logic for different use cases, and various large data layers.
RELIABILITY: Application stack is used by hundreds of companies, millions of users, teams, and services located all around the world, all require fast response and performance.
AVAILABILITY: Must be available 24/7 or SLA for more than 99.95% (meaning just a few hours in the entire year are not available).
AGILITY: Multiple services are constantly updated, hotfixes are applied with the latest security updates, and new technologies are integrated.
RESILIENCY: All sorts of data types and layers are critical and should be available for recovery, analysis, and archiving.

In that case, Microservices architecture is the way to go.

The microservice architecture enables an organization to deliver large, complex applications rapidly, frequently, reliably, and sustainably.

Each service handles a specific business capability and can be developed, deployed, and scaled independently. They communicate over well-defined APIs, as we said, which are sets of rules that allow different software entities to interact with each other.

API

Microservices key characteristics

Autonomous Services: Microservices consist of a collection of small, autonomous services. Each service is self-contained and implements a single business capability within a bound context. A bounded context defines a natural division within a business where a specific domain model exists.
Small and Independent: Each microservice is a separate codebase, managed by a small development team. These services can be deployed independently. Unlike traditional monolithic applications, where a bug fix or feature update might block the entire release process, microservices allow agility by enabling updates to individual services without redeploying the entire application.
Data Responsibility: Services are responsible for persisting their own data or external state. Unlike the traditional model with a separate data layer, microservices handle their own data storage.
API-Driven Communication: Microservices communicate with each other using well-defined APIs. The internal implementation details of each service are hidden from other services.
Polyglot Programming: Services don’t need to share the same technology stack, libraries, or frameworks. This flexibility allows developers to choose the best tools for each service.
Service Discovery: Microservices service discovery is a way for applications and microservices to locate each other on a network. Service discovery implementations within microservices architecture discovery include both a central server (or servers) that maintains a global view of addresses.

Benefits of Microservices

Agility: Independent deployment of services makes it easier to manage bug fixes and feature releases. Updates to a single service don’t impact the entire application.
Scalability: Microservices allow horizontal scaling of individual services based on demand.
Resilience: If one service fails, it doesn’t bring down the entire application.
Technology Diversity: Different services can use varied technology stacks.

4. Monolith vs Microservices

Monoliths are simpler to start with but harder to scale organizationally. Microservices offer more flexibility and scalability but add significant operational complexity.

A monolith architecture bundles the entire application — UI, business logic, and data access — into a single, tightly integrated codebase. It’s simple to build, test, and deploy early on, with strong performance because everything runs in-process. But as the system grows, the monolith becomes harder for large teams to evolve, and scaling is inefficient since you must redeploy or scale the whole application even when only one part needs more resources.

Microservices architecture breaks applications into small, independent services, each handling a specific function and communicating via APIs. Teams can work independently, scale only high-demand services, and isolate faults. The trade-off is added complexity: multiple deployments, inter-service networking, distributed data consistency, and the need for advanced monitoring and debugging.

Initial architecture considerations

The choice between these architectures often depends on your team size, application complexity, and operational maturity.

Get Hristo Stoychev’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

Monoliths work well for smaller teams and simpler applications, while microservices shine in large organizations with complex, high-scale applications where the operational overhead is justified by the benefits of independent development and deployment:

Easier design and initial development: Monolith
Scaling: Microservices (can scale horizontally easily).
Small size and single-tier application: Monolith
Large and multi-tier application/stack: Microservices
Fault Tolerance: Microservices (a single service part of the application stack may not cause downtime of the entire application stack).
Flexibility: Microservices (can develop, update, and change each service individually).
Internal communication: Monolith (faster internal communication between different components).
Software Development Life Cycle (SDLC): Microservices

5. Rapid, Frequent, and Reliable software delivery (CI/CD)

IT must deliver software rapidly, frequently, and reliably — as measured by the DORA metrics.

Rapid, frequent, reliable, and sustainable delivery requires a combination of three things:

Process — DevOps
Organization — a network of small, loosely coupled, cross-functional teams
Architecture — a loosely coupled, testable, and deployable architecture

Teams work independently most of the time to produce a stream of small, frequent changes that are tested by an automated deployment pipeline and deployed into production. Having all those ingredients, we can implement DevOps methodology and CI/CD approach (Continuous Integration and Continuous Delivery).

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

6. Components in a Microservices Architecture

Core Components of Microservices Architecture

The foundation starts with individual services that handle specific business functions, communicating through an API Gateway that acts as the single entry point for all client requests. Services discover each other through a Service Registry, while Load Balancers distribute traffic to prevent bottlenecks. Each service maintains its own database to ensure independence, and Message Queues or Event Buses enable asynchronous communication between services without tight coupling.

Services — Independent, business-focused applications that handle specific functions

API Gateway — Single entry point that routes requests to appropriate services

Service Registry — A Directory where services register themselves and discover other services
Load Balancer — Distributes traffic across multiple instances of services
Database per Service — Each service manages its own data storage

Message Queue/Event Bus — Handles asynchronous communication between services

Infrastructure Components

The infrastructure layer relies on Container Runtime environments like Docker to package services into portable units, managed by Orchestration Platforms such as Kubernetes that handle deployment and scaling automatically. A Service Mesh provides the communication backbone with built-in security and monitoring capabilities. Configuration Management systems centralize settings across all services, while comprehensive Monitoring and Logging tools track performance and collect data from the distributed environment. CI/CD Pipelines automate the entire development lifecycle, enabling rapid and reliable deployments across multiple services.

Container Runtime (Docker, CRI-O) — Packages services with their dependencies

Orchestration Platform (Kubernetes) — Manages deployment and scaling of containers

Service Mesh — Handles service-to-service communication, security, and observability
Configuration Management — Centralized configuration for all services
Monitoring & Logging — Distributed tracing, metrics collection, and log aggregation
CI/CD Pipeline — Automated testing and deployment for each service

7. Microservices Communication, Synchronous vs Asynchronous, Direct vs Brokers (Event Buses)

One of the complex and important topics when designing a Microservices architecture is the communication between internal components.

There are two models of Microservices communication: Synchronous and Asynchronous.

Sync vs Async

Synchronous: easy to implement and troubleshoot. Direct approach.

The client sends a request and WAIT for response.
Easier to implement and design. Intuitive code flow and design.
Easier to debug and troubleshoot.
Not resilient. Not performant.
REST API is a synchronous approach

Synchronous communication is like a phone call — the client sends a request and waits for a response. It’s easy to implement and debug, with intuitive code flow. REST APIs and gRPC are common examples.

REST API is using a standardized software communication protocol -API over the internet using HTTP methods.

Asynchronous protocols: scalable and resilient. Broker approach.

AMQP, MQTT, STOMP (protocols).
A client sends a request and does NOT wait for a response.
The destination is typically a message broker, message queues/buses. Not worrying about how one should receive the message.
Resilient.
Message broker usability.
Azure Service Bus is an asynchronous engine

Asynchronous communication is like sending email — you send a message and don’t wait for an immediate response.

The client typically sends to a message broker, not directly to the destination service.

Receivers

Single receiver
Multiple receivers

Transports

Message Brokers

RabbitMQ: dealing with complex routing, high availability, reliability, and flexibility.
Redis: Lightweight in-memory data store. Speed and performance, but no asynchronous. Single-threaded.
MQTT: Best for devices with low bandwidth and high latency.
NATS: Performance and ease of use. Can scale on the cost of delivery message percentage.

Event Streaming

Kafka: A distributed live event streaming platform for dealing with a high volume of messages.

Remote Procedure Call

gRPC: Google’s implementation of RPC. Used from all kinds of services to call the functions as they are local. Used with a direct approach of communication.