Presentation "Extracting Microservices from a Modular Monolith" at Embedded Online Conference 2025

A modular monolith based on the ports-and-adapters architecture is an excellent starting point for extracting microservices. A microservice shares the same traits as an adapter together with its port – and additionally runs in its own process. Introducing a microservice should have a good reason, because it comes with some extra complexity. We extract an update and diagnostic service from a driver terminal of a harvester.

1. Extracting Microservices from a Modular Monolith Burkhard Stubert

2. Specialist for Usage-Defined Devices Mission: Free smart devices from dumb user interfaces Burkhard’s marquee projects include infotainment systems for cars and driver terminals for sugar beet harvesters, forage harvesters and excavators. As a solo consultant, Burkhard enables his customers to build usage-defined devices. He provides subsystems like UI, machine or cloud communication, OTA updates and secure boot on top of custom-built embedded Linux systems. Newsletter: burkhardstubert.substack.com Web: www.embeddeduse.com Mail: [email protected] Burkhard Stubert

3. 1 Ports-and-Adapters Architecture 2 Definition of a Microservice Reasons for Introducing Microservices 4 Extracting the Microservice for Updating the System 5 Extracting the Microservice for Diagnosing the Machine 3 6 Towards Solutions on Modules ( SoMs )

4. Ports-and-Adapters Architecture A modular monolith based on the ports-and-adapters architecture is an excellent starting point for extracting microservices. 1

5. Modular Monolith: Ports-and-Adapters Architecture Core = implements busines rules Unaware of technology used in adapters Ports = high-level interfaces behaviour-driven t echnology-agnostic always w ith production and test adapter Adapters = convert high-level port into low-level interface to external actor t echnology-specific Secondary external actors kicked into action by Core Primary external actors k ick Core into action

6. Modular Monolith: Ports-and-Adapters Architecture Excellent starting point for extracting adapters as microservices Which adapters are best suited and why?

7. Definition of a Microservice A microservice shares the same traits as an adapter together with its port – and additionally runs in its own process. 2

8. Definition: Microservice James Lewis, Martin Fowler: Microservices – a definition of this new architectural style , 2014: “In short, the microservice architectural style is an approach to developing a single application as a suite of small services , each running in its own process and communicating with lightweight mechanisms […]. These services are built around business capabilities and independently deployable by fully automated deployment machinery.” Microservice : Single purpose Clear business value Running in its own process with lightweight communication Minimal, behaviour -driven, technology-agnostic interface Independent deployment

9. Traits: Microservice vs. Ports-and-Adapters Trait MS P&A Single purpose Clear business value Running in own process with lightweight communication Minimal, behaviour-driven technology-agnostic interface Independent deployment Makes extracting adapters as microservices easier Migrate big ball of mud into modular monolith before extracting microservices

10. Reasons for Introducing Microservices Introducing a microservice should have a good reason, because it comes with some extra complexity. 3

11. Reasons Not core business : Team or company lack time or expertise Scalability : Outsource development to other team or company; buy from third party User privileges : normal vs. root privileges User types with specific usage patterns : e.g., driver, dealer, technician, developer Resilience : Rest of system not affected, if microservice crashes, freezes or runs amok Performance : run resource-critical task in separate process with higher priority or on separate core More… Reduced time-to-market Increased quality More reasons are better

12. Extracting the Microservice for Updating the System Smart OEMs buy a microservice for system updates and save a fair amount of time and money 4

13. Reasons for Extracting UpdateService Reasons for extraction: Root privileges needed Not core business for any OEM Source from third party

14. Call Sequence in HarvestApp Function Calls

15. Applying Remote Proxy Generate from XML spec of port ForUpdatingSystem Forward function call from monolith to microservice synchronous function call -> asynchronous inter-process message

16. Call Sequence between HarvestApp and UpdateService UpdateProxy is another adapter implementing port ForUpdatingSystem ForUpdatingSystem and UpdateProxy deployed with UpdateService Moved from HarvestApp

17. Extracted UpdateService from HarvestApp Run HarvestApp as normal user Run UpdateService as root user Best provided by third party

18. Extracting the Microservice for Diagnosing the Machine Example for microservice with HMI: an application with a single purpose. 5

19. Reasons for Extracting DiagnosisApp Reasons for extraction: Used by Technician sporadically Problems in DiagnosisApp leave other apps/services unaffected But: HarvestApp not ready for extraction! No diagnosis module

20. Preparing Extraction of DiagnosisApp Create port and adapter for diagnosis functionality Apps share same queue for CAN messages in kernel Filtering of CAN messages avoids flooding GUI with 1500+ value changes per second Increase abstraction level of ports Change in Machine must not imply change in ports

21. Extracting MachineService D-Bus communication on low-level instead of high-level side of adapter Not ideal: more small functions But: filtering and sending in groups helps Can be generated from message and filter specifications

22. Extracting DiagnosisApp Not a microservice: Multiple responsibilities App = Microservice + GUI Window manager can make GUIs of two apps look like one

23. Towards Solutions on Modules ( SoMs ) OEMs could buy microservices as third-party solutions. 6

24. SoM = Solutions on Module OEM’s world World of hardware & software vendors Microservices = Solutions with clean API OEMs only know API Hardware vendor with most complete solutions platform wins!