Moving beyond request-reply: How smart APIs are different....Web-UI Me Output Mgmt Current situation...
91
Moving beyond request-reply: How smart APIs are different. @berndruecker
Transcript of Moving beyond request-reply: How smart APIs are different....Web-UI Me Output Mgmt Current situation...
Moving beyond request-reply:How smart APIs are different.
@berndruecker
SomeService
SomeService
SomeService
SomeService
SomeService
SomeService
SomeService
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 errorwhile 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
StatefulRetry
We are having some technicaldifficulties and cannot present you
your boarding pass right away.
But we do actively retry ourselves, so lean back, relax and we will send it
on 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!
StatefulRetry
Warning:Contains Opinion
Berlin, Germany
http://berndruecker.io/[email protected]@berndruecker
Bernd RueckerCo-founder and Chief Technologist ofCamunda
Check-In
You can use a workflow engine (=durable state machine)!
BarcodeREST
Statefulretry
Want to see code?https://github.com/berndruecker/flowing-retail
has to implement
Retryhas 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!
CreditCard
Payment
Charge Credit CardcardNumber
amount
Charge Credit CardcardNumber
amounttransactionId
Not idempotent
Idempotent
charge
Generally: create Idsas soon as possible
Distributed systems introduce complexity you have to tackle!
CreditCard
PaymentREST
Distributedsystems
It is impossible todifferentiate certain
failure scenarios.
Independant ofcommunication style!
Service Provider
Client
Distributed systems introduce complexity you have to tackle!
CreditCard
PaymentREST
Distributed systems introduce complexity you have to tackle!
CreditCard
PaymentREST
Cancel
charge
Being able to implementlong running services
is essential for smart APIs(on a technical level)
@berndruecker
Example
Booking Payment
RetrievePayment
@berndruecker
Example
Booking PaymentCreditCard
RetrievePayment
@berndruecker
Example
Booking PaymentCreditCard
RetrievePayment
Rejected
@berndruecker
Example
Booking Payment
If the creditcard was
rejected, thecustomer canprovide new
details
CreditCard
RetrievePayment
RejectedRejected
@berndruecker
Example
Booking Payment
If the creditcard was
rejected, thecustomer canprovide new
details
CreditCard
RetrievePayment
RejectedRejected
@berndruecker
A fewsmart god services tellanemic CRUD services what to do
Sam Newmann
Paymentfailed
Who is responsible to deal with problems?
Booking Payment
If the credit card was
rejected, the customer can provide new
details
CreditCard
RetrievePayment
RejectedPaymentreceived
@berndruecker
Paymentfailed
Long running services
Booking PaymentCreditCard
RetrievePayment
RejectedPaymentreceived
Smart endpoints are potentially long-running
@berndruecker
Being able to implementlong running services
is essential for smart APIs(on a business level)
@berndruecker
Long running servicesrequire async communication
Synchronous communication
Synchronous communicationis the crystal meth of
distributed programming
Todd Montgomery and Martin Thompson in “How did we end up here” at GOTO Chicago 2015
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
Asynchronous communication
You need tomonitor timeouts
Workflow…
Workflow…
Being able to implementlong running services
makes it easy to get async
@berndruecker
Can your companyleverage yourhipster architecture?
Sh
utte
rstock
You need tochange businessprocesses andcustomerexperience!
Example
@berndruecker
Example
Payment
SeatReservationBooking
TicketGeneration
Example
@berndruecker
sync
Example
@berndruecker
Weaknesses
Payment
SeatReservationBooking
TicketGeneration
REST
Weaknesses: Latency creep
Payment
SeatReservationBooking
TicketGeneration
REST
300 ms1150 + x ms
600 ms
250 ms
Weaknesses: Availabiliy erosion
Payment
SeatReservationBooking
TicketGeneration
REST99 % uptime
99 % uptime
99 % uptime
96 % uptime
And it is even hard to implement
Payment
SeatReservationBooking
TicketGeneration
REST
And it is even hard to implement
Payment
SeatReservationBooking
TicketGeneration
REST
Typical pattern
Payment
SeatReservationBooking
TicketGeneration
REST
Simulate synchronicty by waiting(callback or polling)
@berndruecker
happy case
failurecase
Redesign your business process accordingly!
Or some interfaceto 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.
API
API
APIAPI
API
API
API
Microservices
External Services
Standard Software
„What the hell just happened?“
@berndruecker
Example:order fulfillment viadash 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
OrderPlaced
PaymentReceived
GoodsFetched
Notification
Checkout
Payment
Inventory
Shipment
Event-driven architecture@berndruecker
Peer-to-peer event chains
Checkout
Payment
Inventory
Shipment
Order placed
Payment received
Goodsshipped
Goodsfetched
@berndruecker
Peer-to-peer event chains
Checkout
Payment
Inventory
Shipment
Order placed
Payment received
Goodsshipped
Goodsfetched
@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
Goodsshipped
Goodsfetched
Fetch the goodsbefore thepayment
@berndruecker
Peer-to-peer event chains
Checkout
Payment
Inventory
Shipment
Fetch the goodsbefore thepayment
Goodsfetched
Order placed
Payment received
Goodsshipped
@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
ShipmentPaymentreceived
Order placed
Retrievepayment
@berndruecker
Order
Events & Commands
Checkout
Payment
Inventory
ShipmentPaymentreceived
Order placed
Retrievepayment
@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
Retrievepayment
It can still be messaging!
@berndruecker
Order
It is about where to decide about the coupling!
Checkout
Payment
Inventory
Shipment
Order placed
Retrievepayment
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 servicesor applications
Monolith Chaos
Choreography
Orchestration
@berndruecker
Process Monitoring
Your servicesor applications
Your IT architecture
Process Monitoring
Monolith Chaos
Choreography
Orchestration
Your servicesor 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 orchestration
Thank you!
[email protected]@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/
