The document discusses Magento's plans to move away from a monolithic architecture to a microservices architecture with isolated and independent services. Some key points include: - Magento wants to improve evolvability and guarantee a stable API by isolating services and enforcing clean boundaries between domains. - The new architecture will separate the storefront and store management applications into independent services with their own APIs. - Communication between microservices introduces challenges around network reliability, latency, security and topology changes that must be addressed. - A service mesh will be implemented to help manage inter-service communication and address cross-cutting concerns like authorization. - The transition involves decomposing the monolith into modular services

1. Page | 1
Igor Miniailo,
Lead Architect, Magento
SOMETHING
ARCHITECTURE

2. Page | 2
• 2016 – Command/Query
Responsibility Segregation
(CQRS)
• 2017 – API design best practices
• 2018 – A long way from Monolith
to Service Isolated
Architecture
My previous years on MageConf

3. Page | 3
2019 – ???
• We are at Magento make a lot of decisions each
day / week / month / year
• Some of those decisions are wrong
• And it’s okay. No one can avoid making mistakes!
• But behind each decision, there is some motivation
• You should know it!
• I am here today to highlight our motivation for the
most ambitious project we ever started since
releasing Magento 2

4. Page | 4
Some of us like to gamble,
and those who like sometimes lose...
Serious topic with a silly face

5. Page | 5
No API deprecation today!
Spoiler (and this is serious now):

6. Page | 6
What are the main Magento flaws?

7. Page | 7
Problems:

8. Page | 8
Product Goals:

9. Page | 9
The Monolith

10. Page | 10
API vs SPI (Extension Points)
A PHP Interface in Magento can be used several ways by
the core product and extension developers.
• As an API. is a set of interfaces and their
implementations that a module provides to other
modules
• As a Service Provider Interface (SPI). is a set of
interfaces that a module uses internally and allows their
implementation by other modules
• As both. APIs and SPIs are not mutually exclusive

11. Page | 11
API Evolution

12. Page | 12
Evolvability of platform guaranteed by
Isolation of Services and Stable APIs

13. Page | 13
Storefront vs Store Management

14. Page | 14
Storefront and Store Management Applications:

15. Page | 15
Replaceability in action:

16. Page | 16
Storefront and Store Management Applications:

17. Page | 17
Desired State

18. Page | 18
• Evolvable API (Versionless)
• PATCH Support
Why GraphQL?

19. Page | 19
Multitier architecture of Storefront Application:

20. Page | 20
Backends For Frontends (BFF)
• Minimizes the number of requests to
the back end and reduces chatty
communication to multiple services
• Security issues. Services are not
available to the “external world”
• Handles cross-cutting concerns such
as authorization, data transformations,
service discovery
• Reduces coupling between client and
server
• Reverse proxy or gateway routing

21. Page | 21
Modules Decomposition
• Focus on Clean Boundaries over Perfect Models
• Subdomains for replacement rather than reuse

22. Page | 22
Storefront API

23. Page | 23
Storefront API

24. Page | 24
APIs must be fast

25. Page | 25
APIs must be fast

26. Page | 26
The most complex challenge in
implementation of isolated service
architecture is not building the services
themselves, but the communication
between services

27. Page | 27
• The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
• Topology doesn't change
• There is one administrator
• Transport cost is zero
• The network is homogeneous
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Network is a scary place to be

28. Page | 28
Service Mesh

29. Page | 29
BFF vs Service Mesh

30. Page | 30

31. Page | 31
MFTF coverage is not optional anymore:

32. Page | 32
Magento Administrative tools:

33. Page | 33
Independent component releases:

34. Page | 34
Implement business transaction that
spans multiple services as a saga
A saga is a sequence of
local transactions
Each local transaction
updates the database
and publishes a
message or event to
trigger the next local
transaction in the saga
https://microservices.io/patterns/data/saga.
html

35. Page | 35
Alternative Checkout Flow

36. Page | 36
UUID for Entities identity

37. Page | 37
Community interaction

38. Page | 38
New Magezine issue just landed!

39. Page | 39
Thank You