Microservices architecture: Characteristics and benefits

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.

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.

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.

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.