Issues with asynchronous interaction

Issues with asynchronous interaction

0069e8d5a1871d26b4338f8450215242?s=128

Anna Shcherbinina

September 30, 2017
Tweet

Transcript

  1. 3.
  2. 14.

    Axes of scale Split by Function, Service or Resource Horizontal

    duplication Lookups or Formulaic Splits
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 22.

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

    • Firewall activity, hack/spam relay attempts; • System bottlenecks • Application services.
  8. 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.
  9. 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.
  10. 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.
  11. 28.

    Failure Backups • Check your backups twice; • Store your

    backups away of your application; • Create backup for your backup.
  12. 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.
  13. 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.
  14. 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.
  15. 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/