Thomas Bøgh Fangel gave a presentation on Lunar Way's transition to a microservices architecture and lessons learned. Some key points included: 1) Lunar Way started with a monolithic backend and tightly coupled mobile apps. They broke this into microservices for improved scalability, resilience, autonomy and independent deployments. 2) Inter-service communication is best done asynchronously using events instead of synchronous requests to reduce coupling. This allows services to independently determine their own behavior. 3) The transition occurred gradually, starting with one microservice and learning lessons along the way about data access, technology choices, deployments, and paying off technical debt. 4) Use cases showed how events can be

1. Cloud Native Aarhus 2018
Lunar Way’s road to microservices
OR
How we learned to love async events
Cloud Native Aarhus April 2018
Thomas Bøgh Fangel

2. Cloud Native Aarhus 2018
• Started programming on the C64 and the Amiga back in 80s
• M.Sc. in Maths
• Professional software developer since 2004
• Started my career in Java
• Left Java in favour of Scala and FP
• Now primarily working in Go and Typescript
• Joined Lunar Way in June 2016
About me
Thomas Bøgh Fangel
Web Architect @ Lunar Way
@tbfangel

3. Cloud Native Aarhus 2018
• Setting the Scene
• Microservices and Inter
Service Communication
• Our Road to Microservices
• Use Cases of Async
Message Passing
AGENDA

4. Video
Cloud Native Aarhus 2018

5. Cloud Native Aarhus 2018
The Lunar Way
platform of
Summer 2016

6. Cloud Native Aarhus 2018
NemID Integration
NemID
Native iOS
and Android
apps
Bank Integration
DK Bank
Backend

7. Platform assessment
Cloud Native Aarhus 2018
• Well structured REST API for
the app
The Good
• Tightly coupled data model on
the backend
• App and backend tightly coupled
• One data entity all over the place
• Big Bang deployments
• Hard to do fast experiments
• Hard to scale
The Bad

8. Change required!
Cloud Native Aarhus 2018
• Scalability
• Resilience
• Autonomy
• Decoupling
• Fast experiments
• Small, independent and fast deployments
Goals

9. Cloud Native Aarhus 2018
Microservices
and inter service
communication
https://pixabay.com/en/team-motivation-teamwork-together-386673/

10. So, what is a microservice?
Cloud Native Aarhus 2018
– Sam Newman
Microservices are small,
autonomous services that
work together.
– Martin Fowler
…a single application as a suite of
small services, each running in its
own process and communicating
with lightweight mechanisms…
…services are built around business
capabilities and independently
deployable by fully automated
deployment machinery

11. Why microservices – or why not?
Cloud Native Aarhus 2018
• Modularity
• Coherence and low coupling
• Fault tolerance
• Fast development
• Autonomy
• Independent deployment
Benefits
• Sharing data across services
• Debugging and tracing
• Orchestration
• Deployment
• Increased overall complexity
• Insight across service boundaries
Challenges

12. Inter service communication
Cloud Native Aarhus 2018
• Closed communication
• Trusted/ “secure”
• High coupling (code/space/time)
• Works good when synchronous
app request involved
Synchronous req/resp
• Open ended communication (pub/sub)
• Low coupling (data only)
• “Insecure” from a dev perspective
Flow orchestration is complex
• Works bad when synchronous app
request involved
Async messages

13. Communication shapes coupling
Cloud Native Aarhus 2018
Synchronous req/resp
Service A Service B
Request
Response
Temporal coupling
Spatial coupling
Behavioural coupling - Service A
commands the behaviour of Service B
Example: Signup commands user service
to CreateUser
Async messages
No spatial and temporal coupling
No behavioural coupling - Service B
determines its own behaviour based on the
behaviour of Service A
Example: Signup publishes UserApplied. User
service consumes event, creates user and
publishes UserCreated. Signup service
consumes and changes state
Service A Service B
Q
U
E
U
E
https://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/

14. Event driven systems
Cloud Native Aarhus 2018
• All changes published as events
• Events drive behaviour
• Traditional system design focus on only the state
changes - events disappear after they happen
• Event driven systems complete the picture
Service C Service D
Service A Service B
Event
Event Event
https://hackernoon.com/events-as-first-class-citizens-8633e8479493

15. Cloud Native Aarhus 2018
Our Road to
Microservices
https://pixabay.com/en/road-winding-street-bridge-1030789/

16. The first microservice
Cloud Native Aarhus 2018
Backend Backend
Feed

17. Cloud Native Aarhus 2018
Learning 1 Never allow microservice
A to access the data of
microservice B directly

18. Cloud Native Aarhus 2018
Learning 2 Reduce the number of
new technologies
introduced in one go
http://mcfunley.com/choose-boring-technology

19. Microservice 2, 3 and 4
Cloud Native Aarhus 2018
Backend
Feed
Backend
Feed
Goals
Signup
Support

20. Cloud Native Aarhus 2018
Learning 3 Prioritise your
deployment pipeline
and runtime platform

21. Microservice X, Y and Z
Cloud Native Aarhus 2018
vs

22. Cloud Native Aarhus 2018
Learning 4 Choose your
toolbox wisely

23. Cloud Native Aarhus 2018
Learning 5 Insist on paying
off technical debt

24. Microservice N,
N+1, N+2…
Cloud Native Aarhus 2018
Beyond
counting…

25. Cloud Native Aarhus 2018
Learning 6 Be systematic!

26. Cloud Native Aarhus 2018
Learning 7 DRY up your services
– factor out common
functionality into
new services

27. Cloud Native Aarhus 2018
Learning 8 Appreciate the value
of publishing all
business model
changes as events

28. Cloud Native Aarhus 2018
NemID
Bank
Integration
DK Bank
Native iOS
and Android
apps
Legacy API
Auth
User
Feature
Feed
Stream
Goals
Travel
Card
Signup
Social
Move
Money
Referral
Topup
Push Credit
Tracking
Appsync
User
Settings
Time
Rules
KPI
Support
NemID
Integration
Partner 1
Integration
Parter 3
Integration
Insight
Locali-
zation
Split
Intercom
Sync
Promo
TC
Support
Houston
(Support)
Partner 3
Integration
Partner 1
Partner 2
Partner 3
KPI
CLI
App Facing Internal Integrations
Sync

29. Cloud Native Aarhus 2018
Use Cases of
Async Message
Passing
https://pixabay.com/en/message-in-a-bottle-bottle-post-1694868/

30. Data enrichment
Cloud Native Aarhus 2018
AggregateSource
Enrichment 1
Enrichment 2
One source of data, multiple
enrichments
1. Source publishes event
2. Aggregate stores entity
3. Enrichments runs and publishes
event
4. Aggregate updates aggregate with
enrichment

31. Business insight
Cloud Native Aarhus 2018
Business requires insight across
services
1. Sources publish events
2. KPI subscribes on events and
converts to own model
3. Tooling on top to provide insight
KPI
Source 1
Source 2
Source 3
DB

32. External APIs and web hooks
Cloud Native Aarhus 2018
3rd parties require access to your
data
1. Sources publish events
2. External API subscribes on events
and converts to own model
3. 3rd parties access external API
and may register web hooks
External API
Source 1
Source 2
Source 3
DB
External 1
External 2

33. From pull to push
Cloud Native Aarhus 2018
AppSync
Rails
DK
Partner
Native iOS
and Android
app DB
DK
PartnerRails
DB
Native iOS
and Android
app
App triggers a pull (3-5 requests ~ 1-2
seconds) from partner bank with a DB
transaction open
Queue
Never let an app request trigger a sync! Control
the sync process and use async events to push
data to the app on a web socket

34. Wrapping up
Cloud Native Aarhus 2018
Adapt to the size of your team
Use asynchronous communication
between services… preferably
event driven
Prioritise your deployment pipeline
and runtime platform from the
start
Be systematic!
Key takeaways
if entering
microservice
land

35. Cloud Native Aarhus 2018
?