Microservices architecture: Characteristics and benefits

cloud native

The ability of companies to adapt applications to changing business needs depends largely on the underlying architectural framework. A rigid and outdated architecture does not allow for the necessary flexibility to make changes for greater scalability, speed and performance of enterprise applications. For this reason, the traditional approach to application design is increasingly being replaced by a distributed architectural pattern: the microservices architecture.


A microservices architecture is an architectural model used for the software design of a single application. This paradigm allows the application's functionalities to be subdivided into small, independently distributable units, called microservices, which communicate with each other via 'lightweight' protocols. Thus, each service manages a subset of application functionality and is responsible for a part of the domain that is independent of the global domain (bounded context). The microservice architecture allows teams to develop multiple independent services that can be upgraded, scaled and released separately.


The main characteristics of microservices are: 

  • Autonomy: The independence and decoupling of microservices allow teams to organise themselves independently and focus on a smaller domain with a smaller change surface. This allows the company to quickly change and evolve services according to business needs without having to rewrite the entire application. 
  • Scalability: microservices are extremely scalable and allow the company to quickly scale its resources to handle traffic peaks or user requests. They can also be distributed across multiple machines to ensure greater resilience and reliability in the network. 
  • Cloud Ready: this architectural model guarantees the elasticity of being able to decide over time, should the need arise, to move some software components to the Cloud or to integrate PaaS services into one's own domain. 
  • Business-oriented APIs: Microservices collaborate with each other via standardised application programming interfaces (APIs). This allows the use of different writing languages and the adoption of different technologies. 

    Microservices represent a model widely used by the largest high-tech companies, such as Netflix, Amazon Prime, Spotify, Airbnb and Twitter. In fact, these realities are based on thousands of microservices that handle billions of user requests on a daily basis. Each microservice is responsible for a single functionality of the platform, such as, for example, the monthly payment status, the algorithm that identifies the user's favourite content, the storage of watched TV series, and the classification of the most popular content of the moment.


To highlight the characteristics of microservices more clearly, it is useful to introduce the traditional approach with which companies have developed most enterprise-class applications to date: the monolithic architecture.  

The monolithic architecture places all the functions of an application in a large executable block, called a monolith. All functions are interdependent so that any changes made to one functionality must be tested so as not to adversely affect the other components.

The main weaknesses of a monolithic architecture are: 

  • In development: a large monolithic system has a complex and often unclear structure due to the lack of documentation of past interventions. The risk of functional regressions is high and causes fears in the team when functional evolutions are required. Inevitably, technical debt accumulates and slows down the entire development process. Furthermore, the evolution of a single component requires the deployment of the entire application. 
  • In terms of performance: the monolith is not designed to scale horizontally and vertically indefinitely. It is difficult to add computational resources and scale beyond a certain number of nodes. Therefore, it is clear that the monolithic system does not provide the flexibility today's companies need to expand and contract according to a greater or lesser load of demands. 
  • In the technology stack: A monolithic application is built on a single technology. While this results in less demand for specific skills limited to a single technology, there are also problems of generational scalability and heterogeneity. Indeed, it is difficult to adopt a new generation component or to switch to a newer version of the same because, as is often the case, the initially adopted version of a service is customised to such an extent that it becomes an integral part of the system. Moreover, the monolith, due to its single technology stack, is heavily dependent on a single vendor, preventing the company from getting rid of certain services that are no longer convenient without causing negative impacts on the entire IT system. 

    However, monolithic architecture has some positive characteristics that led it to be the primary choice for developing applications until a few years ago. Building a monolith as a single, cohesive object makes it possible to simplify the entire development process by using a single development environment and a single technology stack. This requires less in-house expertise than the use of microservices and allows for a smoother deployment by means of 'standard application packaging' and subsequent hand-over to the Ops team for deployment into production. 

    In addition, microservices architecture requires several points of attention, including: 
  • System complexity: with more distributed services, the interaction between them can become complex to manage and require the implementation of new collaborative practices, such as DevOps, to coordinate the development, testing, deployment and operation of microservices; 
  • Increased design and management skills: this architectural pattern requires specific skills and a balanced team organisation that can quickly grow junior figures;  
  • Greater complexity in managing transactional processes: a co-ordination mechanism is required to ensure data integrity and consistency of operations;  
  • Difficulties with an innovative domain: when bounded contexts are not 'stable', they can lead to overlaps or functional gaps between services, causing liability and coordination problems;


The adoption of microservice architectures presupposes agile management modes capable of supporting the entire lifecycle of each service. The increased degree of complexity of microservices architecture requires strengthened collaboration between Dev and Ops to fully support the multiplicity of services, the difference in development languages and the deployment process.

DevOps, with a set of practices and tools geared towards automating and speeding up the release of an application, is the approach needed to create an environment suitable for hosting, governing and managing hundreds of services. The continuous flow model of development and deployment reduces production time, guaranteeing the security and speed required for service evolutions.


The modernisation of legacy business applications, originally developed with a monolithic framework, often requires architectural refactoring. To free themselves from the limitations and constraints imposed by an outdated and inflexible architecture, companies opt for a radical move towards a microservices architectural model. Code and application architecture can be restructured and optimised to a more or less significant extent, up to a complete rewrite. In many cases, this approach is the only alternative to migrate custom legacy applications to the cloud, which are built with technologies that are not compatible with the IaaS and PaaS cloud service offerings and which cannot find SaaS alternatives with adequate functionality. 



Microservices are not always the optimal choice for developing an application. The decision whether or not to adopt a microservices architecture depends on the specifications of the application to be developed or modernised, and in particular its size and complexity.  

In this respect, the graph proposed by Martin Fowler, which highlights the trade-off between productivity and the complexity of an application, gives a general indication of when it is advisable to move to a microservices architecture.  

With low application complexity, microservices require an extra expenditure of resources compared to a monolithic structure, as they have an overhead of setup, preparation of environments and tools, such as the development pipeline. In this case, the monolithic architecture continues to be the ideal option for designing and developing an application.  

As the complexity increases, the monolith inevitably begins to accumulate a technical debt such that modifying it and moving it from its position to perform evolutions or solve problems becomes much more complex. In this case, thanks to their characteristics, microservices are suitable for projects of great complexity in which the time needed to release new versions and correct any bugs is to be reduced to a minimum.


On the subject of architectural trade-offs, a case study by Amazon Prime Video on the transition from microservices to monoliths was recently published, creating debate in IT circles. Microservices architecture, widely recognised as a best practice for application development and modernisation, was considered from a different perspective: that of its impact on infrastructure costs. It was shown that it is possible to reduce costs by 90 per cent by switching from microservices to a monolithic application. In particular, the team had originally used serverless components (e.g. AWS Step Functions or AWS Lambda) to create a monitoring functionality for videos displayed with distributed components. However, they realised that this architecture could be simplified by reverting to a monolithic rather than a distributed approach. Consequently, they decided to package all components into a single logical unit and use orchestration to control the components, thereby achieving a drastic reduction in infrastructure costs.

We can find an explanation for this case in the principles expressed by Martin Fowler, which point in the direction of considering the use of microservices or monolithic architecture according to specific use cases, after analysing the costs and benefits both in the short term and in the long term, as the two solutions are not inherently good or bad, but each has its trade-offs. In this context, it is experience in the use of microservices that makes the difference, as it allows one to make informed and valuable choices for current and future business, without falling into the trap of blindly following big tech.


Fill in the form to talk to one of our experts!