O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
“Task Based User Interface” also known as an “Inductive User Interface” (побуждающий) in the Microsoft world. https://cqrs.wordpress.com/documents/task-based-ui/
The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations. Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.
component is a unit of software that is independently replaceable and upgradeable.
Magento Developer Talk. Microservice Architecture and Actor Model
• Task Based UI
• Service Oriented Architecture
• Micro services
• Actor Model
• Three parts
oClient-side user interface
o Server-side application
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.
• 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
• Do one thing and do it well”
• 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
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
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.
• Remote calls are more expensive than in-process calls, and thus
remote APIs need to be coarser-grained
oFine Grained Services
oCoarse Grained Services
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
REST API and Asynchronicity
Please, repave the street
Server’s response ‘202 Accepted’
SOA vs Microservices
Microservices must be
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
• 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.
• 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
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.
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