introduction to reactive microservices architecture

29
Introduction to Reactive Microservices Architecture Richard Langlois P. Eng. Solutions Architect 12 juillet 2016

Upload: richard-langlois

Post on 16-Apr-2017

136 views

Category:

Software


4 download

TRANSCRIPT

Introduction to Reactive Microservices Architecture Richard Langlois P. Eng. Solutions Architect 12 juillet 2016

Microservices / Reactive

Change in the organization

Amazon.ca using Microservices

Service Scalability

Failure Isolation: Circuit Breaker, Bulkhead, Back Pressure

Service Discovery

Versioning

Netflix Stack

12 juillet 2016

Agenda

Monolith:

Legacy enterprise applications are big monolith

If service fails, everything stops working.

Have to scale everything together

Hard to maintain

Hard to understand

Any change requires a scary big deploy

Service-Oriented Architecture (SOA):

Multiple services collaborate to provide some capabilities

Issue with communication protocol (SOAP), vendor middleware (ESB), service granularity, lack of guidance

12 juillet 2016

Monolith -> SOA -> Microservices

System composed of a set of small, isolated services

Services:

Have single area of responsibility, do one thing well

Autonomous, deployed as isolated service

Boundary is business boundary

Communication between services via network calls (e.g. REST over HTTP).

Exposes an Application Programming interface (API)

Golden rule: Able to make a change to a service and deploy it by itself without changing anything else?

12 juillet 2016

What is a Microservices based System

12 juillet 2016

Monolith versus Microservices

Reactive system is Responsive, Resilient, Elastic and Message Driven

Responsive: System responds in a timely manner.

Resilient: System stays responsive in the face of failure.

Elastic: The system stays responsive under varying workload.

Message Driven: Rely on asynchronous message-passing.

12 juillet 2016

What is a Reactive System

Technology Heterogeneity: right technology for each job

Resilience: failure does not cascade

Scaling: can just scale those services that need scaling

Ease of Deployment: change to a single service / deploy it

Organizational Alignment: architecture aligned to organization

Optimized for Replaceability: being small in size, the cost to replace them is small

12 juillet 2016

Key Benefits of Microservices

Monolithic:

organization built around functional team (QA, Dev, Product Owner)

Silo teams

Cons: communication problems, many meetings, dependencies, us vs. them

Microservices:

organization built around cross-functional team

Built around business needs, decision is made faster

Code is shipped faster

Team owns a product: create, maintain.

Effective communication: right information goes to right place, right time

12 juillet 2016

Changes in the Organization

Web page Amazon.ca composed of 11 microservices

12 juillet 2016

Amazon.com using Microservices

12 juillet 2016

Services serving up UI components

12 juillet 2016

API Gateway

12 juillet 2016

Backends for Frontends (BFF)

Scaling: transformation that enlarges or diminishes.

Vertical scaling (Scale Up):

increase the capacity of existing system by adding more powerful hardware

Cons: Additional investment, Single Point of Failure

Horizontal scaling (Scale Down):

Adds extra identical boxes to server

Cons: Requires Load balancer for managing connection

12 juillet 2016

Service Scalability

12 juillet 2016

Vertical vs Horizontal Scaling

keep a failure in one part of the system from destroying everything

Cascading failure : occurs when failure jumps from one system to another

Preventing cascading failure is key to resilience

Some patterns: Bulkhead

Circuit Breaker

Back-Pressure

12 juillet 2016

Failure Isolation

In ship building, bulkhead is a part of the ship that can be sealed off to protect the rest of the ship

Example of bulkhead:

Separate connection pools for each downstream connection

Physical redundancy : 4 independent servers for a service, then failure of one can’t affect the others

Logical redundancy: 4 application instances running on a server, one crash, system still running

12 juillet 2016

Bulkhead

12 juillet 2016

Bulkhead (Continued)

12 juillet 2016

So why Titanic sank?

Wraps a component that can circumvent calls when the component is not healthy.

Prevent operations rather than re-execute them.

Closed state: circuit breaker executes operations as usual.

Open state: calls to the circuit beaker fail immediately.

Half-Open state: next call is allowed to go through, if succeeds, returns to Close state, if fails, returns to Open state.

Automatic mechanism to seal a bulkhead

Protects the consumer from downstream problem

Protects the downstream service from more calls

Recommend circuit breakers for all synchronous downstream calls

Available products: Netflix Hystrix

12 juillet 2016

Circuit Breaker

12 juillet 2016

Circuit Breaker (Continued)

Mechanism ensuring that a fast system can’t overload its slower counterpart.

If a service gets overloaded, it does not become unresponsive, it sends “currently unavailable” messages so upstream clients and services can route around it.

Supported by Reactive Streams specification

Products: Akka Streams, RxJava, Spark Streaming, Cassandra drivers

12 juillet 2016

Back pressure

12 juillet 2016

Back Pressure (continued)

Service needs to know the other service’s address

1. A service registers itself to Service Registry

2. Client uses Service Registry to lookup the service address

3. Client uses this address to call the service

Products: Netflix Eureka, ZooKeeper, etcd

12 juillet 2016

Service Discovery

Happens when interface of a service changes

1. Coexist both the old and new interfaces in the service

2. Allows consumers to migrate gradually

3. Delete old interface when no longer used

Version number in request headers or in URL

E.g. /v1/customer or /v2/customer

12 juillet 2016

Versioning

12 juillet 2016

Versioning (Continued)

12 juillet 2016

Netflix stack (OSS)

Dashboard

12 juillet 2016

Monitoring (Netflix)

Questions?

12 juillet 2016

Merci