Microservices: What They Are, How They Work, and Best Implementation Practices

To start, many will know the concept of microservice, others have simply heard about them, but what are they? Microservices are software components at their smallest possible level of functionality. They are components that can have isolated functionality and achieve great decoupling. This contrasts with traditional monolithic software that compiles all components into a single piece.

Microservices are independent, meaning they only need to be hosted in containers with minimal requirements for their execution and can interact with other microservices as needed.

Why or when to use microservices?

Microservices allow functions to run separately, and if for some reason a service fails, the rest will continue to operate without being affected by the microservice that has problems. 

In the case of monolithic applications, if we have a problem with a component, we must stop execution, fix it, and deploy a new version with the fix applied. This would mean having to stop the entire system, affecting other components that were working correctly and are unrelated to the component that failed!

Now that you know what microservices are, you may wonder how they make each one work and how they communicate with each other.

Well, to implement microservices there are reference models we can follow. These models guide you to ensure that when separating a set of functions into microservices, they are perfectly decoupled and there is no dependency between them.

Reference Models

To implement a microservices architecture, you must consider the following aspects:

• Conduct a prior analysis and define why a microservices architecture is necessary.
• Define which reference model is appropriate to solve the need (reference architectures).
• An implementation model with which you can concretely implement the components of the reference model. For example, if you use Java and Spring, you must have all the necessary components of this framework that support this architecture.
• A deployment model that allows you to define how the architecture components will be deployed. For example, if you use containers, Docker, and what is necessary to use the applications of these containers.

Given the above, to have a good microservices architecture model, you should at least consider the following necessary components and concepts:

• Central configuration server (centralized source repository, versioning, and software lifecycle).
• Service registry/discovery (microservices registry, endpoint disposition).
• Load balancing (service orchestrator).
• Fault tolerance (work on solving faults in isolation without affecting other calls).
• Service exposure (Gateway).
• Authorization component (implementation of a security layer).
• Monitoring (tools that allow monitoring pod health, workload, failures).

Once you have considered these components, it is time to think about how to structure each microservice. To start, you must have a prior analysis related to the business domain to model the microservices.  Knowing and managing the company's domain, objectives, and requirements is one of the great challenges, since there is no mechanical process that guides us to a perfect design. But what you can do is follow architectures that separate by layers and isolate the domain in a way that other components communicate with each other without being affected or mixed.

Hexagonal Architecture

Hexagonal architecture is a software design pattern that seeks to decouple the application by components. These components form a series of layers that will be easily connectable to each other through ports and adapters. A port is the definition of a public interface, and an adapter is a specialization of a port for a specific context. Thus, components can be interchangeable at any level or layer. Additionally, we can isolate automated tests without needing to go through several layers to test a specific functionality.

This architecture is represented by a hexagonal shape, where the sides represent the ports, which allow going to an inner or outer layer of the application. Each component can connect with another component through these ports. Communication between ports will always follow a specific protocol (for example, an API) depending on the objective or function it has. 

Hexagonal Architecture

Infrastructure Layer

This layer contains components related to the integration of other microservice components, for example, an external service component like user authentication or a messaging service (email sending), which is not a core domain component.

Application Layer

This layer contains, for example, a component like Spring in Java and includes the different use cases.

Domain Layer

This layer contains the entire business domain of the application, that is, entities, repositories, model, events, services.

DDD Architecture (Domain-Driven Design)

It is a software architecture design where business logic is the determining factor in software construction. It allows mapping the business into software artifacts and organizing them in such a way that it solves business problems. 

Modeling is based on business use cases. There is a context created from the need to solve a problem. We must establish boundaries for solving this problem, limiting requirements so they are not redundant or do more than necessary for the solution. This helps us have an idea of the ideal size a microservice should have. This point is important because not setting boundaries leads to having a microservice that is too large and generates unnecessary coupling. Cohesion is a key concept in delimiting each component.

DDD Levels or Layers

The structure is composed of well-defined and structured layers or levels so that their components do not mix between layers. For example, we ensure that business entities are not in layers that do not belong to the business domain, or that persistence logic is in the infrastructure layer and not in the presentation layer.. 

The levels or layers interact with each other through their own interface, keeping their internal logic encapsulated.

The different layers are defined as follows:

Presentation Layer (UI): This is the layer that interacts with different clients. This layer displays and receives data. It can be represented by a graphical interface of a web or some device.

Application Layer: Coordinates the actions to be performed in the domain. Delegates business actions to the domain layer. It depends on the Infrastructure and Domain layers.

Domain Layer: Contains business rules and logic, entities, and persistence details. It is the core of the software. It has no dependencies on other layers of the model, but other layers depend on it.

Infrastructure Layer: This layer contains implementations and encapsulated functionalities that are not part of the business domain, for example, database connections, integrations with other external services, email notification services, etc. It depends on the domain layer.

Cohesion and Coupling

Well-designed monolithic applications tend to have high cohesion since all their components are integrated into the same context, making it easy to understand the relationship of each integrated component. For microservices, maintaining cohesion is a constant task because, being isolated and loosely coupled components, there are cases where there is so much separation between them that the cohesion of a service and how it relates to other microservices in a given context is lost.

Microservices should be designed around company functionalities, have flexible coupling, and also high functional cohesion. This means microservices should exhibit low coupling but also maintain high cohesion. 

If a component (microservice) requires a change, and this change does not affect the other microservices that interact with it, meaning they do not need to be updated because of this change, it means the microservice has high cohesion. It is designed with a unique and well-defined purpose that allows encapsulating domain knowledge so that it can be abstracted from the clients that consume it. If this design is not well defined and is decoupled more than necessary, cohesion between components may be lost.

Advantages

Agility: Being implemented independently, it is easier to manage them; in case of failure, only one service can be updated without having to redeploy the entire application.

Small and focused teams: Since microservices are small in size, managing them requires a small team. This speeds up productivity because communication flows better with small teams. Unlike larger teams where communication tends to be slower, resulting in less agility.

Small codebase: Monolithic applications tend to grow over time and have new functionalities, complicating code maintenance as multiple layers of the application need modification. Microservices architectures minimize this dependency, allowing new features to be added easily.

Mix of technologies: Microservices architecture allows flexibility in the language of each microservice, improving the implementation of a service according to the most suitable technology for a functionality. It also allows having experts in a specific technology without forcing a team to use a technology they are not accustomed to and must research.

Error isolation: Microservices being independent means if an error occurs, it does not prevent the functioning of other microservices, so it is not necessary to stop the entire application to fix errors.

Horizontal Scalability: There is no migration of the entire system to hardware with better performance since, being independent services, the concept of service replication is used. This scalability allows adding adaptable resources to workload growth.

Challenges

Management complexity: Having a distributed architecture across several microservices makes managing their integration more complex. Therefore, it is necessary to have tools that provide an overall view of all of them in case of possible failures.

High memory consumption: Microservices architecture works in a distributed manner, and each microservice is independent, so resources must increase, unlike a monolithic architecture.

Developer profile: Developers with high experience in development and versioning, knowledge of network latency, and load balancing are required.

Initial time investment: Implementing this architecture requires a greater time investment as it requires more analysis to correctly separate services and implement communication between them.

Personal View

When starting to design the architecture and its components, you must keep in mind that maintaining cohesion is key to achieving a well-defined architecture. Also, you must have a high level of business understanding and knowledge since the domain is the most important component and where you should focus the most. Without high business knowledge, implementing architectures like these will be more complex. 

Another important point is having the right team to implement this architecture. They must have the necessary expertise to handle the components and tools required to build an architecture like this, as well as additional tools such as monitoring all its artifacts.

Do you want to implement a scalable and efficient microservices architecture?

At Kranio, we design solutions based on microservices that adapt to your business needs. We use principles like DDD, events, containers, and CI/CD automation to help you scale sustainably.
👉 Contact us and let's take the next step together in your technological transformation.