Magento Developer Talk. Microservice Architecture and Actor Model https://www.youtube.com/watch?v=0S7LJQ98Fz4

1. Agenda
• Task Based UI
• Service Oriented Architecture
• Micro services
• Actor Model

2. CRUD Based UI
Forms over data

3. Task Based UI

4. Task Based UI

5. CQRS и REST API

6. Monolithic Architecture
• Three parts
oClient-side user interface
o Server-side application
oDatabase
This server-side application is a monolith. Any changes to the system involve building and
deploying a new version of the server-side application.
All your logic for handling a request runs in a single process
You can horizontally scale the monolith by running many instances behind a load-balancer.

7. Micro services
• Single application as a suite of small services
• Each running in its own process and communicating over HTTP
• Services are built around business capabilities and independently
deployable
• Do one thing and do it well”

9. • Each Micro service belongs to own Bounded Context (DDD)
o A Bounded Context encapsulates the details of a single domain and defines the
integration points with other bounded contexts/domains.
• As decoupled and as cohesive as possible

10. Any organization that designs a system (defined
broadly) will produce a design whose structure is a copy
of the organization's communication structure.
-- Melvyn Conway, 1967

13. Smart endpoints and dumb pipes
• REST API over HTTP
• Message bus (RabbitMQ)
The biggest issue in changing a monolith into microservices lies in
changing the communication pattern. A naive conversion from in-
memory method calls to RPC leads to chatty communications which
don't perform well. Instead you need to replace the fine-grained
communication with a coarser -grained approach.

14. • Remote calls are more expensive than in-process calls, and thus
remote APIs need to be coarser-grained
oFine Grained Services
oCoarse Grained Services

18. Synchronous calls considered harmful
Any time you have a number of synchronous calls between services you
will encounter the multiplicative effect of downtime.
Simply, this is when the downtime of your system becomes the product
of the downtimes of the individual components.
You face a choice, making your calls asynchronous or managing the
downtime. At www.guardian.co.uk they have implemented a simple
rule on the new platform - one synchronous call per user request while
at Netflix, their platform API redesign has built asynchronicity into the
API fabric.

19. REST API and Asynchronicity
Please, repave the street
Server’s response ‘202 Accepted’

21. SOA vs Microservices
Microservices must be
independently deployable,
whereas SOA services are often
implemented in deployment
monoliths. So, SOA is an
architectural pattern in which
application components provide
services to other components.
However, in SOA those
components can belong to the
same application.

22. Actor Model

23. http://www.reactivemanifesto.org/
Reactive is

24. • Responsive: The system responds in a timely manner if at all possible.
Responsiveness is the cornerstone of usability and utility. Responsive
systems focus on providing rapid and consistent response times.
• Resilient: The system stays responsive in the face of failure. This
applies not only to highly-available, mission critical systems — any
system that is not resilient will be unresponsive after a failure.
Resilience is achieved by replication,
containment, isolation anddelegation.
• Elastic: The system stays responsive under varying workload. Reactive
Systems can react to changes in the input rate by increasing or
decreasing the resources allocated to service these inputs.
• Message Driven: Reactive Systems rely on asynchronous message-
passing to establish a boundary between components that ensures
loose coupling, isolation and location transparency.

25. Actor
• An actor is the primitive unit of computation. It’s the thing that
receives a message and do some kind of computation based on it.
• The idea is very similar to what we have in object-oriented languages:
An object receives a message (a method call) and do something
depending on which message it receives (which method we are
calling).
The main difference is that actors are completely isolated from each
other and they will never share memory. It’s also worth noting that an
actor can maintain a private state that can never be changed directly
by another actor.

27. What actors do
When an actor receives a message, it can do one of these 3 things:
• Create more actors;
• Send messages to other actors;
• Designates the behavior to be used for the next message it
receives (implies state).
oKeep mutable state internal and communicate with each
other through asynchronous messages

31. Small Demo

43. Actors vs Micro services