This document discusses refactoring a monolithic application into microservices using a serverless approach. It describes a scenario where an investment application has separate databases for the web app and investments that require manual updates. The proposed solution is to extract services from the monolith piece by piece using APIs and event-driven architecture. Guidelines are provided around defining service boundaries, data modeling, integration patterns, testing, and monitoring distributed systems. Potential limitations of serverless computing are also outlined.

1. Python & Serverless
Refactor your monolith piece by piece
With @giuseppe_valla

2. 500
Internal server error
Mmm.. That fresh fragrance of production bugs (*)
* Said nobody ever

4. Problem scenario
Each customer can check the perf. of
their own investment, with a private
dashboard.
Each investment is composed of
different financial instruments which
are categorised by a specific asset and
sub-asset class

5. Problem scenario
WebApp
DB
Investment
DB
Team
Finance
Lots of Read/Write Ops Mostly Read Ops
Team
IT

6. Problem scenario
The Investment DB and WebApp DB have similar db tables
related to the financial instruments (taxonomies and perf.
tracking).

7. Problem scenario
The Investment DB and WebApp DB have similar db tables
related to the financial instruments (taxonomies and perf.
tracking).
Databases are handled by two different teams and the update
of investment portfolios require human intervention.

8. Problem scenario
The Investment DB and WebApp DB have similar db tables
related to the financial instruments (taxonomies and perf.
tracking).
Databases are handled by two different teams and the update
of investment portfolios require human intervention.
Although the UI shows a hierarchical structure, data is
organised differently and the web servers rebuild this
structure for frontend consumption.

9. What can go wrong ?

10. The solution we adopted
WebApp
DB
Investment
DB
Border
DB
WebApp
Team
Finance
Team
IT

11. Command Query
Responsibility Segregation
“At its heart is the notion that you can
use a different model to update
information than the model you use to
read information…” (Martin Fowler)

12. The end ?

13. About me and…
• Software developer with an interest in
distributed systems and cloud computing
• Working in the finance domain for the past
5 years
• @giuseppe_valla / giuseppe.vallarelli@pm.me

14. Professional grade investment
portfolios for everybody, regardless
of the amount of capital invested
Transparent pricing, first company in Italy
publishing Mifid2 compliant report on
costs in April 2019

15. Ser󰉏󰈩󰈹l󰇵󰈻󰈼 In󰉃󰈹o
Fro󰈚 󰈀 󰈛󰈢no󰈗󰈎󰉄h 󰉃󰈢 󰈛ic󰈸󰈡 󰈼󰇵r󰉏i󰇸󰈩s ?
Ex󰉃󰈹ac󰉃󰈎󰈞g 󰈻󰈢󰈛e m󰈡󰇷󰉊󰈘es 󰈎󰈝󰉄󰈢 in󰇷󰈩󰈦󰇵n󰇷e󰈞t 󰈻󰈩󰈹v󰈏󰇹e󰈼
Usi󰈝󰈈 󰈩v󰇵󰈝󰉄s a󰈻 󰉄r󰈎󰈇󰈈󰇵r 󰉃o 󰈡󰉊󰈹 Fa󰈀󰈠
Tes󰉃󰈎󰈞g & Mo󰈝󰈎󰉄󰈢ri󰈝󰈈

16. Serverless simply explained

17. Serverless simply explained again!
Any technology that cost you nothing to run if no one is using it.

18. Serverless simply explained again!
Any technology that cost you nothing to run if no one is using it.
Uptime of a Serverless solution is completely delegated to third party
providers, we are free from managing, scaling cloud resources and all
kind of security concerns

19. What if…

20. Are we there yet ?Are we there yet ?

21. Current limitations

22. Current limitations
Limited
Lifetime

23. Current limitations
Limited
Lifetime
I/O
Bottlenecks

24. Current limitations
Limited
Lifetime
I/O
Bottlenecks
No
Specialized
HW

25. Current limitations
Limited
Lifetime
I/O
Bottlenecks
No
Specialized
HW
“Serverless Computing: One Step Forward, Two Steps Back” (UC Berkley Paper)

26. FaaS a data-shipping architecture
https://aws.amazon.com/blogs/machine-learning/build-your-own-text-to-speech-applications-with-amazon-polly/

27. Ser󰉏󰈩󰈹l󰇵󰈻󰈼 In󰉃󰈹o
Fro󰈚 󰈀 󰈛󰈢no󰈗󰈎󰉄h 󰉃󰈢 󰈛ic󰈸󰈡 󰈼󰇵r󰉏i󰇸󰈩s ?
Ex󰉃󰈹ac󰉃󰈎󰈞g 󰈻󰈢󰈛e m󰈡󰇷󰉊󰈘es 󰈎󰈝󰉄󰈢 in󰇷󰈩󰈦󰇵n󰇷e󰈞t 󰈻󰈩󰈹v󰈏󰇹e󰈼
Usi󰈝󰈈 󰈩v󰇵󰈝󰉄s a󰈻 󰉄r󰈎󰈇󰈈󰇵r 󰉃o 󰈡󰉊󰈹 Fa󰈀󰈠
Tes󰉃󰈎󰈞g & Mo󰈝󰈎󰉄󰈢ri󰈝󰈈

28. A Monolith, a microservice
“Software whose design, information
model and interface combine multiple
competing and interfering domains into
a single application and data model”
(Jimmy Bogard)

29. A Monolith, a microservice
“A service with a design focus towards
the smallest autonomous boundary”
(Jimmy Bogard)

30. Who uses microservices ?

31. Why ?

32. Should you ?

33. Pros / Cons Microservices
PROS CONS
Independent *
* deployment, scalability,
technology stack,
reusability
Increased Effort *
* monitoring, operations,
coordination, higher
complexity, requires serious
expertise

34. Distributed Systems are
everywhere…
Better get ready

35. Ser󰉏󰈩󰈹l󰇵󰈻󰈼 In󰉃󰈹o
Fro󰈚 󰈀 󰈛󰈢no󰈗󰈎󰉄h 󰉃󰈢 󰈛ic󰈸󰈡 󰈼󰇵r󰉏i󰇸󰈩s ?
Ex󰉃󰈹ac󰉃󰈎󰈞g 󰈻󰈢󰈛e m󰈡󰇷󰉊󰈘es 󰈎󰈝󰉄󰈢 in󰇷󰈩󰈦󰇵n󰇷e󰈞t 󰈻󰈩󰈹v󰈏󰇹e󰈼
Usi󰈝󰈈 󰈩v󰇵󰈝󰉄s a󰈻 󰉄r󰈎󰈇󰈈󰇵r 󰉃o 󰈡󰉊󰈹 Fa󰈀󰈠
Tes󰉃󰈎󰈞g & Mo󰈝󰈎󰉄󰈢ri󰈝󰈈

36. Meet Euclidea Monoliths
Onboarding
Digital Signature *
Order Mgmt Finance *
Backoffice
Private Area
* Third party integration
Fund Selection
Portfolio Optimization
Risk Management
Portfolio Analytics

37. A service extraction recipe
Start by defining the APIs for the
service “A” to be extracted,
update the code to depend on this
new wrapping APIs.A

38. A service extraction recipe
Start by defining the APIs for the
service “A” to be extracted,
update the code to depend on this
new wrapping APIs.A
Create a new DB containing the
tables of interest for the service A.
Later switch the datastore from D1
to D2 (consider data migration).
D1
D2

39. A service extraction recipe
Start by defining the APIs for the
service “A” to be extracted,
update the code to depend on this
new wrapping APIs.A
Create a new DB containing the
tables of interest for the service A.
Later switch the datastore from D1
to D2 (consider data migration).
D1
D2
A
Extract the API and expose it
through a REST and Event
Interface.

40. But let’s not forget the spices…
Each service should be
autonomous depending
only on his own data to
avoid unnecessary coupling.
Data dependencies

41. But let’s not forget the spices…
Each service should be
autonomous depending
only on his own data to
avoid unnecessary coupling.
Data dependencies
Some data duplication is
allowed provided the
existence of a single source
which is deemed as
authoritative for the data.

42. And the main course!
• Synchronous/asynchronous
interaction
• Message observed/consumed
• Patterns: Request/Reply,
Request/Reaction, Inversion
of Communication, Saga and
more…
Integration patterns

43. Failure is the new happy path

44. Things we need to think about
• What if a service is a down ? Hint: fallbacks, idempotent
behaviour for consumer services.
• How do we keep evolving a service ? Hint: consumer contracts.

45. Migrate in small safe steps

46. Ser󰉏󰈩󰈹l󰇵󰈻󰈼 In󰉃󰈹o
Fro󰈚 󰈀 󰈛󰈢no󰈗󰈎󰉄h 󰉃󰈢 󰈛ic󰈸󰈡 󰈼󰇵r󰉏i󰇸󰈩s ?
Ex󰉃󰈹ac󰉃󰈎󰈞g 󰈻󰈢󰈛e m󰈡󰇷󰉊󰈘es 󰈎󰈝󰉄󰈢 in󰇷󰈩󰈦󰇵n󰇷e󰈞t 󰈻󰈩󰈹v󰈏󰇹e󰈼
Usi󰈝󰈈 󰈩v󰇵󰈝󰉄s a󰈻 󰉄r󰈎󰈇󰈈󰇵r 󰉃o 󰈡󰉊󰈹 Fa󰈀󰈠
Tes󰉃󰈎󰈞g & Mo󰈝󰈎󰉄󰈢ri󰈝󰈈

47. Testing & Monitoring (1/2)
Unit
Integration
End-to-end
Test in
production
Contract
testing
Unit

48. Testing & Monitoring (2/2)
• Log Aggregation and the ability to trace a user’s request
through different subsystems
• Metrics of different kinds: system, application.
Very important to invest in tooling to analyse and understand
the distributed system’s whole behaviour.

49. Ser󰉏󰈩󰈹l󰇵󰈻󰈼 In󰉃󰈹o
Fro󰈚 󰈀 󰈛󰈢no󰈗󰈎󰉄h 󰉃󰈢 󰈛ic󰈸󰈡 󰈼󰇵r󰉏i󰇸󰈩s ?
Ex󰉃󰈹ac󰉃󰈎󰈞g 󰈻󰈢󰈛e m󰈡󰇷󰉊󰈘es 󰈎󰈝󰉄󰈢 in󰇷󰈩󰈦󰇵n󰇷e󰈞t 󰈻󰈩󰈹v󰈏󰇹e󰈼
Usi󰈝󰈈 󰈩v󰇵󰈝󰉄s a󰈻 󰉄r󰈎󰈇󰈈󰇵r 󰉃o 󰈡󰉊󰈹 Fa󰈀󰈠
Tes󰉃󰈎󰈞g & Mo󰈝󰈎󰉄󰈢ri󰈝󰈈

50. References & Credits
• The Serverless Sea Change
• Serverless Computing: One Step Forward, Two Steps Back
• Serverless Best Practices
• Build Your Own Text-to-Speech Applications with Amazon Polly
• The Tao of Microservices
• Soa Patterns
• Honeycomb’s Charity Majors: Go Ahead, Test in Production
Photos credits: Vangelis Batsikostas, Ardian Lumi, Miguel Andrade, Louis Hansel,
Quino Al, Michal Parzuchowski

51. 500 times
Thanks!