fault-tolerant rest api invocations in an application … · object store connector and cache scope...

Gerald LoefflerSenior Curriculum Developer and Technical Instructor, EMEA2017-10-23

Fault-Tolerant REST API Invocations in an Application Network

All contents © MuleSoft Inc.

Safe harbor statement

The information in this presentation is confidential and proprietary to MuleSoft and may not be disclosed without the permission of MuleSoft. This presentation is not subject to your license agreement or any other service or subscription agreement with MuleSoft. MuleSoft has no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation and MuleSoft's strategy and possible future developments, products and or platforms directions and functionality are all subject to change and may be changed by MuleSoft at any time for any reason without notice. The information on this document is not a commitment, promise or legal obligation to deliver any material, code or functionality. This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This document is for informational purposes and may not be incorporated into a contract. MuleSoft assumes no responsibility for errors or omissions in this document, except if such damages were caused by MuleSoft intentionally or grossly negligent.

All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.

2


MuleSoft instructor-led architecture courses

3

● Anypoint Platform Architecture:

○ Solution Design (4-5d)

○ Application Network Design (2d)

The significance of failure in application networks


What do these lines represent?

5

System API <-> backend system

Experience API <- frontend system

API <-> API

Remote calls / API invocations:


API-led connectivity

6

Experience APIs

Process APIs

System APIs

website mobile app

Salesforce SAP Mainframe


A concrete application network

7


Synchronous API invocations for 2 use cases

8


Cascading failures w/o fault-tolerant API invocations

9


Why might an API invocation fail?

10

API client API implementation


Goal of fault-tolerant API invocations

11This Talk Our Fixation

Fault-tolerant API invocation strategies and their implementation in Mule runtime


Timeout

13

● Slow API invocations○ Endanger your SLA

○ May well eventually fail

● Set short timeouts for all API invocation○ Fail fast - don’t freeze timeout

Graph: http://blog.skylight.io/the-log-normal-reality/


Timeout on Mule runtime

14

● HTTP Request Connector supports timeouts directly


Retry

15

● Many failures are transient○ Java IO/net exceptions

○ HTTP 5xx, 408 (Timeout), 423 (Locked), 429 (Too Many Requests)

● Retry failed API invocations○ Only a few times

○ With timeouts and minimal delay

○ Only if idempotent: GET, HEAD, OPTIONS, PUT, DELETE


Fallback API invocation

16

● After retries on the primary API have been exhausted:

● Invoke a fallback API○ Different endpoint of same API

■ DR, older version, different AWS region, …

○ Different API with less than ideal functionality

○ Invoke with timeouts and retries


Cached fallback result

17

● After retries on primary and fallback APIs have been exhausted:

● Maintain a client-side cache of API invocation results○ Keyed by input parameters

○ Auto-evicting

○ Only if there is a reasonable chance of cache hits


Static fallback result

18

● As a last resort:

● Return statically configured results○ Degrade service - don’t fail

○ Needs to be provided specifically for each API

○ Works best for reference data:

■ Countries, currencies, product recommendations, ...


● Configuration requires functional domain knowledge

Fault-tolerant API invocation strategies

19

Thank You [email protected]

[email protected]


MuleSoft Training instructor-led courses 1/2

21

● Overview○ Getting Started with Anypoint Platform (1.5d)

● Architects○ Anypoint Platform Architecture: Solution Design (4-5d)

○ Anypoint Platform Architecture: Application Network Design (2d)

● Operations○ Anypoint Platform Operations: CloudHub (1-2d)

○ Anypoint Platform Operations: Customer-Hosted Runtimes (2d)

○ Anypoint Platform Operations: API Management (1d)


MuleSoft Training instructor-led courses 2/2

22

● Developers○ Web-based

■ Anypoint Platform: Flow Design (1d)

■ Anypoint Platform: API Design (2d)

○ Anypoint Studio-based

■ Anypoint Platform Development: Fundamentals (4-5d)

■ Anypoint Platform Development: Advanced (3-4d)

■ Anypoint Platform Development: DataWeave (1d)

■ Anypoint Platform Development: Custom Connectors (1d)


The Eight Fallacies of Distributed Computing

23

1. The network is reliable

2. Latency is zero

3. Bandwidth is infinite

4. The network is secure

5. Topology doesn't change

6. There is one administrator

7. Transport cost is zero

8. The network is homogeneous

L. Peter Deutsch (1994), James Gosling (1997)


Retry on Mule runtime

24

● HTTP Request Connector○ Validates HTTP response status○ Configurable

● Until Successful Scope implements retries○ Custom rule for idempotent HTTP methods


Fallback API invocation on Mule runtime

25

● Result from

Until Successful Scope

fed into

Choice Router


Cached fallback result on Mule runtime

26

● Both

Object Store Connector

and

Cache Scope

support this use case


Static fallback result on Mule runtime

27

● One option for configuring static fallback results is properties○ CloudHub Runtime manager supports overriding these after deployment


Implementation options on Mule runtimes

28

● Library approach○ Vanilla Mule runtime features - as shown so far

○ Mule 4: packaged as Smart Connector

○ Future: auto-generated from RAML by REST Connect

○ Connector on top of 3rd party libraries■ E.g., non-productized Mule Hystrix Connector

● Sidecar approach○ As implemented by service meshes like Envoy/Istio

■ Timeout and retry but no fallback API/results

○ Transparent to Mule app

○ Moves fault-tolerance config out of Mule app

integration logic

fault-tolerance strategies

integration logic

fault-tolerance strategies


The bible, 2nd edition, is underway!

29

Available in December

fault-tolerant rest api invocations in an application … · object store connector and cache scope...

Documents