Introduction to Reactive Microservices Architecture

The architecture style based on Microservices is an approach where an application is developed as a suite of several small services, each of them executing in their own environment. Those services accomplish a single business task, and their deployment is automated. The big players in this world (e.g. Netflix, LinkedIn, Amazon, and Google) are already using this type of architecture successfully, since several years now.

Transcript

1. Introduction to Reactive Microservices Architecture Richard Langlois P. Eng. Solutions Architect 12 juillet 2016
2.  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
3.  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
4.  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
5. 12 juillet 2016 Monolith versus Microservices
6.  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
7.  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
8.  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
9.  Web page Amazon.ca composed of 11 microservices 12 juillet 2016 Amazon.com using Microservices
10. 12 juillet 2016 Services serving up UI components
11. 12 juillet 2016 API Gateway
12. 12 juillet 2016 Backends for Frontends (BFF)
13.  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
14. 12 juillet 2016 Vertical vs Horizontal Scaling
15.  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
16.  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
17. 12 juillet 2016 Bulkhead (Continued)
18. 12 juillet 2016 So why Titanic sank?
19.  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
20. 12 juillet 2016 Circuit Breaker (Continued)
21.  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
22. 12 juillet 2016 Back Pressure (continued)
23.  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
24.  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
25. 12 juillet 2016 Versioning (Continued)
26. 12 juillet 2016 Netflix stack (OSS)
27.  Dashboard 12 juillet 2016 Monitoring (Netflix)
28.  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
29.  Questions? 12 juillet 2016 Merci