Upgrade to Pro — share decks privately, control downloads, hide ads and more …

.NET Day 2023: Fault Handling with retry and ci...

dotnetday
September 01, 2023

.NET Day 2023: Fault Handling with retry and circuit breaker design patterns

Polly can improve the customers' user experience in mobile and web applications. But do you know you can also use Polly in microservices communication? In this talk, I will show you a step-by-step process of building two simple .NET 6 Services and working with the Polly library to ensure we can handle any transient faults that may occur when one service calls the other. I will start with different types of exposing your microservices like direct, facade, and API gateway. Then what is Retry Policy? What is Circuit Breaker Policy? What is Infrastructure-based resiliency? And how to implement them in DotNET apps.

dotnetday

September 01, 2023
Tweet

More Decks by dotnetday

Other Decks in Technology

Transcript

  1. • Exposing Microservices • Retry Policy • Circuit Breaker Pattern

    • Demo of Retry Policy and Circuit Breaker Pattern in .NET 7 web apps Agenda
  2. • infrastructure upgrade • faulty network connection • null reference

    on someone else’s code • server unavailable • bad deployment • and more
  3. Option 1. Direct Access Pros: • No additional components –

    lazy approach • Backward compatibility is addressed in each microservice – a little less work
  4. Option 1. Direct Access Pros: • No additional components –

    lazy approach • Backward compatibility is addressed in each microservice – a little less work Cons: • Multiple entry points – extra complexity • The internal architecture is directly exposed to the world – evolution is difficult to impossible • There is no clear perimeter; every microservice must be secured, adding extra latency and complexity.
  5. FAÇADE Option 2-A. Single Universal Façade Pros: • The internal

    architecture is hidden – easy evolution • Single entry point – simpler and better security • Place to tailor and optimize external requests • Consistent development and delivery practices • Platform agnostic – will work anywhere • Feature-rich – multi-protocol, async notifications and more
  6. FAÇADE Option 2-A. Single Universal Façade Pros: • The internal

    architecture is hidden – easy evolution • Single entry point – simpler and better security • Place to tailor and optimize external requests • Consistent development and delivery practices • Platform agnostic – will work anywhere • Feature-rich – multi-protocol, async notifications and more Cons: • Extra work to implement • Constant changes
  7. BFF 2 BFF 1 App 1 App 2 Option 2-B.

    Backend For Frontend (BFF)
  8. BFF 2 BFF 1 App 1 App 2 Option 2-B.

    Backend For Frontend (BFF) Pros: • The internal architecture is hidden – easy evolution • Single entry point – simpler and better security • Consistent development and delivery practices • Platform agnostic – will work anywhere • Feature-rich – multi-protocol, async notifications and more • Extra optimization of application requests
  9. BFF 2 BFF 1 App 1 App 2 Option 2-B.

    Backend For Frontend (BFF) Pros: • The internal architecture is hidden – easy evolution • Single entry point – simpler and better security • Consistent development and delivery practices • Platform agnostic – will work anywhere • Feature-rich – multi-protocol, async notifications and more • Extra optimization of application requests Cons: • Extra work to implement
  10. FAÇADE 1 FAÇADE 2 Pros: • The internal architecture is

    hidden – easy evolution • Consistent development and delivery practices • Platform agnostic – will work anywhere • Feature-rich – multi-protocol, async notifications, and more • Extra optimization of application requests • Smaller APIs – easier changes Option 2-C. Multiple Façades
  11. FAÇADE 1 FAÇADE 2 Pros: • The internal architecture is

    hidden – easy evolution • Consistent development and delivery practices • Platform agnostic – will work anywhere • Feature-rich – multi-protocol, async notifications, and more • Extra optimization of application requests • Smaller APIs – easier changes Cons: • Multiple entry points - higher complexity • Extra work to implement Option 2-C. Multiple Façades
  12. API Gateway Option 3. API Gateway Cloud-native: • AWS API

    Gateway • Microsoft Azure API Management Simple free cloud agnostic: • KongHQ • Nginx Plus API Management: • Apigee (Google) • 3scale (Red Hat)
  13. API Gateway Option 3. API Gateway Pros: • The internal

    architecture is hidden – easy evolution • Single entry point – simpler and better security • Prebuilt cross-cutting services – less work to add authorization, throttling, tracing, audit logging • Pre-integrated with cloud services (cloud only) • Extra security – feature reach well tested 3rd party implementation • API productization - website, documentation, SDK generation, and more
  14. API Gateway Option 3. API Gateway Pros: • The internal

    architecture is hidden – easy evolution • Single entry point – simpler and better security • Prebuilt cross-cutting services – less work to add authorization, throttling, tracing, audit logging • Pre-integrated with cloud services (cloud only) • Extra security – feature reach well tested 3rd party implementation • API productization - website, documentation, SDK generation, and more Cons: • Extra technology to learn and maintain • Limited functionality – hard to support complex processing, multi-protocol or async notifications • Inconsistent development and delivery practices
  15. Retry Policy A Retry policy is exactly what the name

    implies. The request is retried after a short wait if an error response is received. The wait time is configurable as shown in the following table: Wait time value Example sequence Constant 2s, 2s, 2s, 2s… Exponentially increasing 2s 4s, 8s, 16s… Specified list 100ms, 100ms, 100ms, 2s, 4s. 8s
  16. Circuit Breaker Policy A Circuit Breaker policy gives the target

    service a break after a repeated number of failures. Such a state might indicate that the service is experiencing a serious problem and is temporarily unable to response. After a defined number of consecutive failures, the connection attempts are paused temporarily, “opening” the circuit.
  17. Closed: In electrical circuits, when a circuit breaker is closed

    indicates that electric current is passing. In the resilience pattern it means that you are passing “requests”
  18. Open: in this state, the circuit does not pass the

    requests to the destination, only returns to the requester that the service is out, avoiding to overload the destination with new requests, besides providing feedback faster, without having to wait for the end of a request that probably will fail. The circuit goes to the open state after reaching a predefined threshold of faults and will also remain open for a predefined time.
  19. Half-Open: This is a check state. After reaching the time

    in the Open state, the system goes to this state and the next request will be forwarded to the destination. If the destination returns a fault, the circuit returns to the Open state, if it returns successfully it goes to the Closed state.
  20. Infrastructure-based resiliency To implement infrastructure-based resiliency, you can use a

    service mesh. • A management interface, which could be a UI or an API • For example, Istio, with Istio you can define retry policies with a traffic rule, offloading this logic to your services’ sidecar proxies
  21. Code-based resiliency To implement code-based resiliency, you can write a

    logic or use a 3rd party library for resilience and transient failure handling. github.com/App-vNext/Polly
  22. Other Usage Scenarios of a Retry Policy • Reading/writing to

    file system • Using databases • Reading/writing to message queue
  23. Summary Retry Policy - the request is retried after a

    short wait if an error response is received. Circuit Breaker Policy - a Circuit Breaker policy gives the target service a break after a repeated number of failures.
  24. Resiliency approaches There are two fundamental approaches to resiliency: •

    Infrastructure • Code Review resiliency concepts Resiliency is the ability to recover from transient failures Summary