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

CRUD Based UI

Forms over data

Task Based UI

Task Based UI

CQRS и REST API

Monolithic Architecture• Three parts

oClient-side user interface o Server-side applicationoDatabase

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.

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”

• Each Micro service belongs to own Bounded Context (DDD)oA 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-grainedo Fine Grained ServicesoCoarse Grained Services

Synchronous calls considered harmfulAny 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.

REST API and Asynchronicity

Please, repave the street

Server’s response ‘202 Accepted’

SOA vs MicroservicesMicroservices 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.

Actor Model

http://www.reactivemanifesto.org/

Reactive is

• 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.

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.

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

Small Demo

Actors vs Micro services