Issues with asynchronous interaction

Transcript

1. 1.

   Issues with asynchronous interaction @gaar4ica
 Anna Shcherbinina

2. 2.

   I like Ruby, Arch & Artec3D

3. 3.

   None
4. 4.

   Downtime? Never heard of…

5. 5.

   Service Interaction Patterns

6. 6.

   Interaction Patterns Asynchronous Request-Reply with Timeout

7. 7.

   Interaction Patterns Asynchronous Request-Reply with a Notification Timer

8. 8.

   Interaction Patterns One Request, Multiple Responses

9. 9.

   Interaction Patterns One Request, Mandatory Response, and Optional Response

10. 10.

    Interaction Patterns Subscription

11. 11.

    Interaction Patterns Unsolicited Notification

12. 12.

    Scaling from old time to now-days

13. 13.

    Be ready for capacity

14. 14.

    Axes of scale Split by Function, Service or Resource Horizontal

    duplication Lookups or Formulaic Splits
15. 15.

    • What: Typically called horizontal scale, this is the duplication

    of services or databases to spread transaction load. • Why: Allows for fast scale of transactions at the cost of duplicated data and functionality. X-axis Clone things
16. 16.

    • What: Sometimes referred to as scale through services or

    resources, focuses on scaling data sets, transactions and engineering teams. • Why: Allows for efficient scaling of not only transactions, but very large data sets associated with those transactions. Y-axis Split different
17. 17.

    • What: This is very often a split by some

    unique aspect of the customer such as customer ID, name, geography and so on. • Why: Rapid customer growth exceeds other forms of data growth or you have the need to perform fault isolation between certain customer groups as you scale. Z-axis Split similar
18. 18.

    What prevents us from successful scaling?

19. 19.

    Stateless - is the common guide

20. 20.

    Be ready for failure

21. 21.

    Failure Monitoring Monitoring: • All server event logs; • Monitoring

    for proper updates; • Backup status; • Firewall activity, hack/spam relay attempts; • System bottlenecks (system processes, processor/ram utilisation, etc.); • Application services; • Real-time Inventory collection and web-based reporting; • Remote support for most issues.
22. 22.

    Failure Monitoring Monitoring: • All server events; • Backup status;

    • Firewall activity, hack/spam relay attempts; • System bottlenecks • Application services.
23. 23.

    Failure Log aggregation How to understand the behaviour of an

    application and troubleshoot problems? • All Use a centralised logging service that aggregates logs from each service instance. The users can search and analyse the logs. They can configure alerts that are triggered when certain messages appear in the logs.
24. 24.

    Failure Distributed tracing

25. 25.

    Failure Exception tracking How to understand the behaviour of an

    application and troubleshoot problems? • Report all exceptions to a centralised exception tracking service that aggregates and tracks exceptions and notifies developers.
26. 26.

    Failure Learn from failure Leverage every failure to learn and

    teach important lessons
27. 27.

    Failure QA • QA does not increase quality of your

    system; • QA decrease risks; • Use QA team to learn from past mistakes; • QA helps to decrease a number of repeated defects.
28. 28.

    Failure Backups • Check your backups twice; • Store your

    backups away of your application; • Create backup for your backup.
29. 29.

    Failure Deployment

30. 30.

    Failure Deployment • Set up your deployment process to be

    ready for rollback; • Avoid irreversible releases; • Monitoring and metrics helps to measure and analyse result of the release; • Set up partial deployment.
31. 31.

    Autoscaling

32. 32.

    Autoscaling Monitoring • Monitoring is the key feature of autoscaling;

    • Metrics should be re-estimated once a quoter; • Use complex metrics to avoid wasting resources.
33. 33.

    Autoscaling Dashboard example

34. 34.

    Autoscaling Scale down • Top and bottom limits are vital

    to avoid money loss; • Do not forget to empty resources your app does not need anymore.
35. 35.

    Interaction SPoF Single points of failure

36. 36.

    Interaction SPoF Evolving application in it’s natural way

37. 37.

    Interaction Interaction patterns

38. 38.

    Be competent

39. 39.

    Thank you https://twitter.com/gaar4ica https://github.com/gaar4ica Scalability Rules: 50 Principles for Scaling

    Web Sites (Martin L. Abbott, Michael T. Fisher) Practical Object-Oriented Design in Ruby (Sandi Metz) Eloquent Ruby (Russ Olsen) Ruby Performance Optimization: Why Ruby is Slow, and How to Fix It (Alexander Dymo) Design Patterns in Ruby (Russ Olsen) Implementing SOA: Total Architecture in Practice By Paul C. Brown http://microservices.io/patterns/