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
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
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
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
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
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
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
Books:
Building Microservices, Sam Newman, 2015
Reactive Microservices Architecture, Jonas Bonar, 2016
Microservices - Flexible Software Architectures, Eberhard Wolff, 2016
Release It! Design and Deploy Production-Ready Software, Michael T. Nygard
Web:
Martin Fowler web site: http://martinfowler.com/articles/microservices.html
The Netflix OSS: https://netflix.github.io
Twitter:
@HystrixOSS
@samnewman
@crichardson
@martinfowler
12 juillet 2016
Ressources