Macro-services to Nano-services: Evolution of Software Architecture

Published in

Design Microservices Architecture with Patterns & Principles

5 min readFeb 14, 2023

In this article, we are going to learn our Architecture Design Journey which will be Evolution of Architectures; Monolithic, Microservices and Serverless.

With this article we will design application a step-by-step process for software system design and evolve from monolithic to microservices following the patterns & principles. And Refactor architectures with different aspects of microservices pillars.

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

Architecture Design Journey

Over the years, software development moved away from traditional monolithic architectures, because of the complexities with tightly coupled, interconnected code. In a monolithic architecture, the entire software application is built as a single, tightly-coupled unit, making it difficult to scale, maintain and deploy.

In contrast, microservices architecture breaks down the application into small, independent services that communicate with each other through APIs. Each microservice focuses on a specific business capability and can be developed, deployed and managed independently. This makes it easier to scale and maintain the application, as well as to implement changes without affecting the entire system. So, Microservices are adopted many projects with using cloud-native approaches that enable distributed computing through multiple smaller services.

Recently, the trend has moved further towards Nano-services, which are even smaller and more fine-grained services that provide a specific functionality. This approach allows for more granular control and management of the services, but it also introduces new challenges such as increased network communication overhead and the need for sophisticated orchestration.

If we follow a step-by-step process for software system design and evolve from monolithic to microservices, you can see our architecture design journey will be:

Monolithic -> Modular Monolithic -> Microservices -> Serverless

And Refactor architectures with different aspects of microservices pillars. You can find steps that we are going to follow:

• Iterate Design Architecture from On-Premises to Cloud Serverless
• Evolves architecture Monolithic to Event-driven Microservices
• Refactoring System Design for handling million of requests
• Apply best practices with microservices design patterns and principles

Macroservices to Nanoservices

If we look at the different perspective, we will breaking down services our architecture from Macro-services to Nano-services. You can see the image at below;

This starts with Monolithic which is Macro-services where all business services are deployed as a single package in the application server and share the same database.
It continue with Microservices which is independently developed, deployed, and managed communications with loosely coupling services.
And lastly we will evolve Nano-services. Nano-services are designed to perform a single function, so the output is exposed through a specific API endpoint and perform a specific task.

Which architecture approach we should choose ?

So now we can ask a question to ourselves. The question is:

When we start a new application, which architecture approach we should choose ? Monolithic ? Microservices ? Serverless ?

The choice of architecture approach depends on various factors, including the size and complexity of the software system, the level of scalability and maintainability required, the development and deployment processes, and the technical and business constraints.

There is no default answer for this question, it always depends on your project. Software architecture is always considering tradeoffs. So you should think benefits and drawbacks and calculate design benefits.

In general, we can say that for smaller or less complex systems, a monolithic architecture may be sufficient and simpler to manage. For larger and more complex systems, a microservices-based architecture can provide the necessary scalability, maintainability, and agility.

But one of the best practices that you can also set up your architecture in a transitional way and use mixed architectures with together. You can make microservices and make some parts macro-service and some parts Serverless. Or we can call this approach as a hybrid approach that combines elements of both monolithic and microservices architecture may be appropriate. For example, some parts of the system may be developed as microservices while others are integrated into a monolithic architecture. You can find Mixed Architecture (hybrid approach) as image bellowed:

When you develop large scaled software architecture, you should consider to maximize benefit for all different architecture approaches like Macroservices, Microservices and Serverless functions. The important thing is you should carefully implement these architectures in right use cases of your project requirements.

Vertical Considerations of Software Architecture Design

We can also discuss Vertical Considerations of our architectures. We will discuss microservices architectures with all aspects, These are Microservices Building Blocks :

Microservices Decomposition — Breaking Down Microservices
Microservices Communications (Sync / Async Message-Based Communication, API Gws)
Microservices Data Management (Databases / Query / Commands)
Microservices Transaction Management
Microservices Distributed Caching
Microservices Deployments with Containers and Orchestrators
Microservices Resilience with Distributed Logging, Tracing and Health

with applying microservices design patterns and practices. Refactor architectures with different aspects of microservices pillars; decomposition, communications, data management, deployment and so on. You can find Vertical Considerations as image bellowed:

According to this image, we can evaluate and verify any architecture with checking all these vertical considerations. For example, If we design microservices architectures, we should also consider database choose, data consistency and distributed transaction management for E2E use cases.

Conclusion

The right architecture approach depends on the specific needs and goals of the software system, as well as the organization’s technical capabilities and culture. It is important to carefully evaluate the trade-offs and requirements before making a decision.

What’s Next ?

Step by Step Design Architectures w/ Course