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. w w w . e m b e d d e d o n l i n e c o n f e r e n c e . c o m
Extracting Microservices
from a Modular
Monolith
Burkhard Stubert

2. © E m b e d d e d O n l i n e C o n f e r e n c e . c o m A l l r i g h t s r e s e r v e d EmbeddedOnlineConference.com
THE SPEAKER
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: burkhard.stubert@embeddeduse.com
Burkhard Stubert

3. © E m b e d d e d O n l i n e C o n f e r e n c e . c o m A l l r i g h t s r e s e r v e d EmbeddedOnlineConference.com
AGENDA
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
• technology-agnostic
• always with production and
test adapter
Adapters = convert high-level port into
low-level interface to external actor
• technology-specific
Secondary external actors
• kicked into action by Core
Primary external actors
• kick 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 archit
ectural 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
• 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!

25. w w w . e m b e d d e d o n l i n e c o n f e r e n c e . c o m
THANK YOU