• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
Codemotion Magazine

Codemotion Magazine

We code the future. Together

  • Discover
    • Live
    • Tech Communities
    • Hackathons
    • Coding Challenges
    • For Kids
  • Watch
    • Talks
    • Playlists
    • Edu Paths
  • Magazine
    • Backend
    • Frontend
    • AI/ML
    • DevOps
    • Dev Life
    • Soft Skills
    • Infographics
  • Talent
    • Discover Talent
    • Jobs
  • Partners
  • For Companies
Home » Backend » How to Transition from Monolithic Systems to Microservices with Hexagonal Architecture
Microservices

How to Transition from Monolithic Systems to Microservices with Hexagonal Architecture

Learn how WINDTRE has leveraged hexagonal architecture to transition from monolithic systems to microservices, while progressively merging several heterogeneous technologies and maintaining their UX and user-oriented functionalities unaltered.

June 30, 2021 by Vito Gentile

How to Transition from Monolithic Systems to Microservices with Hexagonal Architecture

In March 2020, two of the biggest telecom companies active in Italy, WIND and TRE merged into WINDTRE. As a result, the new company needed to be reorganized on several fronts, including in relation to software. 

The original companies used different technologies, approaches and legacy systems that needed to be integrated within a more complex single system.

The additional need for a redefinition of the entire software architecture aimed to provide a new system that could improve ease of maintainability and allow for robust system integration in the short and medium term. 

The company therefore transitioned from several software systems based on monolithic architectures to a new system based on microservices. The aim was to provide a unified user interface with a couple of ambitious goals: 

First, WINDTRE needed to provide users with a unified service despite continuing to use different legacy technologies ‘under the hood’. That meant reusing both companies’ original software code bases. Second, the new system needed to support a progressive integration of new unifying technologies that would end up replacing the old systems to form a unique software suite.

To address these challenges, the WINDTRE team leveraged an interesting architectural paradigm that fit perfectly with the need for a modular, microservices-based approach. This paradigm – hexagonal architecture – allows solid, modern, and effective systems to be built at the same time as merging heterogeneous technologies and legacy systems.

For those who may be interested, WINDTRE is on the lookout for experienced JAVA 8, GO, JAVASCRIPT, NODE.JS or REACT.JS developers. Potential candidates should accept their Software Developer Coding Challenge. The winner will be further evaluated by the company, and will also receive a prize of €500 worth of Amazon vouchers.

Table Of Contents
  1. Monolithic applications vs. microservices
  2. Hexagonal Architecture
    • Advantages of hexagonal architecture
  3. Lambada: putting hexagonal architecture into practice
  4. Conclusions

Monolithic applications vs. microservices

Before going into detail about the work WINDTRE has done, it is worth clarifying the differences between monolithic and microservices-based applications.

Monolithic applications represent the traditional way of building software. Applications are divided into several modules, such as a database, a front-end and a back-end. The latter is usually the foundation of the application, in which data and visualizations represent the communication aspect and most of the core business logic is implemented. This monolith is a single logical executable that governs the whole application’s logic.

Monolithic applications have the advantage of having relatively simple structures (given the low number of modules), but present several disadvantages. For instance, altering any part  of the system creates a need to re-build and deploy the whole application, irrespective of the size of the changes. 

This has implications for the development cycle, where new releases need to be scheduled according to a (usually) rigid schedule. Reuse of code is also often limited across monolithic applications. 

Other drawbacks include low scalability and several constraints relating to the software stack used to build the application.

Luckily, we can now solve many – if not all – of these issues by relying on microservices. A microservice is a single module that implements specific capabilities; these are also made available to other modules via Application Programming Interfaces (APIs). Each microservice usually encapsulates a particular business capability and might use specific technologies. These are completely hidden from the other modules by the only available interface, which is represented by the APIs.

Microservices offer several advantages: modular by nature, they are consequently good for high scalability and for code reuse. Introducing a change to a single microservice does not require restarting an entire system: the restart can be limited to a single module, allowing a more agile management of the development cycle.

However, there are some drawbacks to this model. Microservices orchestration is one of them. Many microservices demand the implementation of specific logics that can properly govern integration. Additionally, communication among microservices may introduce latency, which can be a problem in some contexts.

Solving microservices integration may be not straightforward. This is especially true when demand for such a solution arises from a process connected to transitioning from monolith to microservices. The use of a specific architecture to orchestrate microservices will significantly ease this process.

Hexagonal Architecture

As previously mentioned, WINDTRE’s integration needs demanded the combination of different technologies, including different data sources and management tools.  In the future, legacy systems would need to be replaced without affecting the UX.

To implement the required logic, the WINDTRE team opted for hexagonal architecture. As this model suggests, they used it to create loosely-coupled application components, interconnected through adapters.

A diagram representing the hexagonal architecture model
The hexagonal architecture model.

This produced a scheme in which the core business logic is protected from external interactions through specific adapters, thereby avoiding direct interaction.

A diagram representing how business logic is encapsulated in the context of hexagonal architecture.
Basic structure showing how business logic is encapsulated in the context of hexagonal architecture.

Implementing this basic concept involves creating one set of microservices for the business logic, and another set for the adapters, orchestrating each hexagonal microservices subset as a single logic unit. 

One alternative is to encapsulate the business logic and adapters in a single microservice, so that the logic unit matches the service. Here, it is important to ensure that the ‘inside’ (represented in the previous figure) remains independent of the ‘outside’, so that any replacement of the core logic is still workable.

The following image shows how logic units can communicate with each other by implementing the concepts described above.

Diagram depicting microservices' communication.
Diagram depicting microservices’ communication.

Advantages of hexagonal architecture

The WINDTRE team realised that an hexagonal architecture offered two major advantages. 

First, the possibility of isolating the core business logic from the interface (adapters), allowing easy replacement of modules without impact on the system as a whole. 

Considering the initial requirements of their heterogeneous systems, and the necessity of merging them, this operation perfectly matched the demands arising from a corporate merger.

Another significant advantage of such an architectural choice is testing. Since each logic unit is independent, designing a set of tests for a single hexagon becomes easy, whether for the adapters or the core features. Case testing is crucial for effective troubleshooting and debugging of microservices.

Lambada: putting hexagonal architecture into practice

Following their analysis, WINDTRE has subsequently used hexagonal architecture for microservices in many projects, including ‘Lambada’. This amusingly-named endeavour required implementation of what is described above with an additional lambda integration.

Basically, Lambada is a Java Spring container that acts as an orchestrator. It provides several micro-functionalities, implemented as Lambdas. In addition, Lambada makes it possible to implement more complex features as separate microservices, which are queried via HTTP when necessary. Such microservices are implemented singly as hexagons, containing a core business logic that communicates only with the adapters, which in turn provide the interface for other services, including the Lambada orchestrator.

Lambada is particularly interesting because it reduces system complexity by decreasing the number of microservices to just those that are strictly necessary, thus reducing the number of complex features to be implemented as Lambdas. This positively impacts maintainability, since it reduces troubleshooting quite significantly by limiting the number of independent services to be tested and monitored.

Another advantage is the ability to release and deploy specific modules (or microservices) without having to stop the orchestrator, thus offering an agile approach to the development cycle.

Conclusions

Transitioning from a monolithic architecture to microservices requires splitting several functionalities into logic-separated modules, and encapsulating those modules in microservices. As shown above, micro-functionalities allow this to be achieved through lambda functions and a tailor-made solution such as Lambada. 

In this case, the hexagonal architecture proved particularly effective in separating the business logic represented by legacy technologies (to be replaced in the near future) from the communication interface.

This clever approach provided flexibility, modularity and the chance to replace any module with a newer one while keeping the application running.

The WINDTRE case study offers an incredible insight into how a monolith-to-microservices transition is feasible even when combined with a complex merger if those responsible are open to investigating and exploring creative solutions.

We hope you have enjoyed this article. If you want to get in touch with WINDTRE and are an experienced software developer, have a go at their Software Developer Coding Challenge. WINDTRE is hiring; this coding challenge is an opportunity for you to demonstrate your skills and also win a prize of €500 worth of Amazon vouchers.

facebooktwitterlinkedinreddit
Share on:facebooktwitterlinkedinreddit

Tagged as:API Service Oriented Architecture

Understanding Xilinx Design Tools
Previous Post
17 JavaScript Frameworks that You Should Know About – A Comprehensive Guide
Next Post

Related articles

  • 10 Security Measures to Look Out for When Choosing a Cloud Vendor Contractor
  • Discover Leading Edge Front-end Technologies and Microservices Architecture that will enhance Digital Customer Experience
  • The AWS DevOps Toolset: CI/CD, Microservices, and More
  • Airbnb’s migration from monolith to microservices
  • How to Monitor Microservices
  • Develop Microservices in PHP: an overview from Enrico Zimuel’s talk
  • Design-first gRPC APIs for microservices: a sample workflow for parallel teamwork
  • 5 tips for Microservices good practices
  • Video: How to Use Python for Async Microservices

Primary Sidebar

Learn new skills for 2023 with our Edu Paths!

Codemotion Edu Paths for 2023

Codemotion Talent · Remote Jobs

Game Server Developer

Whatwapp
Full remote · TypeScript · Kubernetes · SQL

Back-end Developer

Insoore
Full remote · C# · .NET · .NET-Core · Kubernetes · Agile/Scrum

Full Stack Developer

OverIT
Full remote · AngularJS · Hibernate · Oracle-Database · PostgreSQL · ReactJS

Data Engineer

ENGINEERING
Full remote · Amazon-Web-Services · Google-Cloud-Platform · Hadoop · Scala · SQL · Apache-Spark

Latest Articles

Will Low-Code Take Over the World in 2023?

Frontend

Pattern recognition, machine learning, AI algorithm

Pattern Recognition 101: How to Configure Your AI Algorithm With Regular Rules, Events, and Conditions

AI/ML

automotive software

Automotive Software Development: Can Agile and ASPICE Coexist?

DevOps

programming languages, 2023

Which Programming Languages Will Rule 2023?

Infographics

Footer

  • Magazine
  • Events
  • Community
  • Learning
  • Kids
  • How to use our platform
  • Contact us
  • Become a Contributor
  • About Codemotion Magazine
  • How to run a meetup
  • Tools for virtual conferences

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • YouTube
  • RSS

DOWNLOAD APP

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • RSS

DOWNLOAD APP

CONFERENCE CHECK-IN