How smart APIs are different. @berndruecker Some Service Some - - PowerPoint PPT Presentation

Moving beyond request-reply: How smart APIs are different.

@berndruecker

Some Service Some Service Some Service Some Service Some Service Some Service Some Service

Failure will happen. Accept it! But keep it local! Be resilient.

Photo by Tookapic, available under Creative Commons CC0 1.0 license.

„There was an error while sending your boarding pass“

Check-in Web-UI

Me

Current situation

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Current situation

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Current situation

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Current situation – the good part

Circuit breaker

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Current situation – the bad part

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Current situation – the bad part

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Current situation – the bad part

Stateful Retry

We are having some technical difficulties and cannot present you your boarding pass right away. But we do actively retry ourselves, so lean back, relax and we will send it

• n time.

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Possible situation – much better!

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Possible situation – much better!

Stateful Retry

Warning: Contains Opinion

Berlin, Germany

http://berndruecker.io/ mail@berndruecker.io @berndruecker

Bernd Ruecker

Co-founder and Chief T echnologist of Camunda

Check-In

You can use a workflow engine (=durable state machine)!

Barcode

REST

Stateful retry

Want to see code?

https://github.com/berndruecker/flowing-retail

has to implement

Retry

has to implement

Idempotency

Client Service Provider

Don‘t worry, it will happen safely – even if you loose connection. Feel free to reload this page any time!

Photo by pixabay, available under Creative Commons CC0 1.0 license.

Requirement: Idempotency of services!

Photo by pixabay, available under Creative Commons CC0 1.0 license.

Requirement: Idempotency of services!

Photo by Chr.Späth, available under Public Domain.

Make every service idempotent!

Credit Card Payment

Charge Credit Card cardNumber amount Charge Credit Card cardNumber amount transactionId

Not Not idempotent Idempotent

charge

Generally: create Ids as soon as possible

Distributed systems introduce complexity you have to tackle!

Credit Card Payment

REST

Distributed systems

It is impossible to differentiate certain failure scenarios.

Independant of communication style!

Service Provider Client

Distributed systems introduce complexity you have to tackle!

Credit Card Payment

REST

Distributed systems introduce complexity you have to tackle!

Credit Card Payment

REST

Cancel charge

Being able to implement long running services is essential for smart APIs

(on a technical level)

@berndruecker

Example

Booking Payment

Retrieve Payment

@berndruecker

Example

Booking Payment Credit Card

Retrieve Payment

@berndruecker

Example

Booking Payment Credit Card

Retrieve Payment Rejected

@berndruecker

Example

Booking Payment

If the credit card was rejected, the customer can provide new details

Credit Card

Retrieve Payment Rejected Rejected

@berndruecker

Example

Booking Payment

If the credit card was rejected, the customer can provide new details

Credit Card

Retrieve Payment Rejected Rejected

@berndruecker

A few smart god services tell anemic CRUD services what to do

Sam Newmann

Payment failed

Who is responsible to deal with problems?

Booking Payment

If the credit card was rejected, the customer can provide new details

Credit Card

Retrieve Payment Rejected Payment received

@berndruecker

Payment failed

Long running services

Booking Payment Credit Card

Retrieve Payment Rejected Payment received

Smart endpoints are potentially long-running @berndruecker

Being able to implement long running services is essential for smart APIs

(on a business level)

@berndruecker

Long running services require async communication

Synchronous communication

Synchronous communication is the crystal meth of distributed programming

T

• dd Montgomery and Martin Thompson

in “How did we end up here” at GOT

O Chicago 2015

Check-in

Barcode Generator

Web-UI

Me

Output Mgmt

Asynchronous communication

You need to monitor timeouts

Workflow…

Workflow…

Being able to implement long running services makes it easy to get async

@berndruecker

Can your company leverage your hipster architecture?

Shutterstock

You need to change busi sines ess pr processes es and customer er expe perience ience!

Example

@berndruecker

Example

Payment Seat Reservation Booking Ticket Generation

Example

@berndruecker sync

Example

@berndruecker

Weaknesses

Payment Seat Reservation Booking Ticket Generation

REST

Weaknesses: Latency creep

Payment Seat Reservation Booking Ticket Generation

REST

300 ms 1150 + x ms 600 ms 250 ms

Weaknesses: Availabiliy erosion

Payment Seat Reservation Booking Ticket Generation

REST

99 % uptime 99 % uptime 99 % uptime 96 % uptime

And it is even hard to implement

Payment Seat Reservation Booking Ticket Generation

REST

And it is even hard to implement

Payment Seat Reservation Booking Ticket Generation

REST

T ypical pattern

Payment Seat Reservation Booking Ticket Generation

REST Simulate synchronicty by waiting (callback or polling)

@berndruecker happy case failure case

Redesign your business process accordingly!

Or some interface to poll for status Sync in happy case Async response

@berndruecker

Redesign your business process accordingly!

Your business processes need to be more reactive!

@berndruecker https://www.reactivemanifesto.org/

Yeah! Let‘s go reactive.

Phil Calcado at QCon NYC 2019

API API API API API API API

Microservices External Services Standard Software

„What the hell just happened?“

@berndruecker

Example:

• rder fulfillment via

dash button

Photo by 0xF2, available under Creative Commons BY-ND 2.0

• license. https://www.flickr.com/photos/0xf2/29873149904/

@berndruecker

Three steps…

@berndruecker

(Micro-)services

Checkout Payment Inventory Shipment

@berndruecker

Order Placed Payment Received Goods Fetched

Notification Checkout Payment Inventory Shipment

Event-driven architecture

@berndruecker

Peer-to-peer event chains

Checkout Payment Inventory Shipment

Order placed Payment received Goods shipped Goods fetched

@berndruecker

Peer-to-peer event chains

Checkout Payment Inventory Shipment

Order placed Payment received Goods shipped Goods fetched

@berndruecker

The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years.

https://martinfowler.com/articles/201701-event-driven.html @berndruecker

The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years.

https://martinfowler.com/articles/201701-event-driven.html @berndruecker

The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years.

https://martinfowler.com/articles/201701-event-driven.html @berndruecker

Peer-to-peer event chains

Checkout Payment Inventory Shipment

Order placed Payment received Goods shipped Goods fetched

Fetch the goods before the payment

@berndruecker

Peer-to-peer event chains

Checkout Payment Inventory Shipment

Fetch the goods before the payment

Goods fetched Order placed Payment received Goods shipped

@berndruecker

What we wanted

Photo by Lijian Zhang, available under Creative Commons SA 2.0 License and P..19 / CC BY-SA 4.0 @berndruecker

Order

Extract the end-to-end responsibility

Checkout Payment Inventory Shipment

Payment received Order placed Retrieve payment

@berndruecker

Order

Events & Commands

Checkout Payment Inventory Shipment

Payment received Order placed Retrieve payment

@berndruecker

Event Command

Fact, happened in the past, immutable Intend, Want s.th. to happen

Order

It is not about the protocol!

Checkout Payment Inventory Shipment

Order placed Retrieve payment

It can still be messaging!

@berndruecker

Order

It is about where to decide about the coupling!

Checkout Payment Inventory Shipment

Order placed Retrieve payment

Order decides . to listen to the event . to issue the command

@berndruecker

Extract Orchestration logic

Workflows live inside service boundaries

@berndruecker

Your IT architecture

Choreography Orchestration

@berndruecker

Your services

• r applications

Monolith Chaos Choreography Orchestration

@berndruecker

Process Monitoring

Your services

• r applications

Your IT architecture

Process Monitoring

Monolith Chaos Choreography Orchestration

Your services

• r applications

Balance choreography and orchestration

@berndruecker

. Distributed systems are complex. At-least-once, retries and idempotency are here to stay. Embrace async! . Long-running services make your life easier and your API smarter. . Change business processes and customer experience accordingly . Use commands + events = balance choreography and

• rchestration

Thank you!

mail@berndruecker.io @berndruecker https://berndruecker.io https://medium.com/berndruecker https://github.com/berndruecker

https://www.infoq.com/articles/events- workflow-automation

Contact: Slides: Blog: Code:

https://www.infoworld.com/article/3254777/ application-development/ 3-common-pitfalls-of-microservices- integrationand-how-to-avoid-them.html https://thenewstack.io/5-workflow-automation- use-cases-you-might-not-have-considered/