I presented this talk to Alithya, Montreal in July 2016, to an audience of 70 persons.

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