Microservices should be autonomous and independent, but what happens when your business domain doesn’t allow it, and you need to get data from other microservices? You’ll soon realize that simple HTTP calls are not enough anymore, or that your app is more brittle than ever and then you switch to messaging. With messaging you need to have a different mindset and be willing to embrace new challenges.
In this session, we’ll explore different ways of getting data from one ‘micro-service’ to another and while doing that we’ll talk about the benefits or the drawbacks of choosing an approach or another.
5. MONOLITH
Self-contained
Single codebase
Single deploy unit
Easy life for developers
Dependencies are in your code
Single technology stack
6. MONOLITH
All or nothing deploys
Downtimes
Long build times
~ 0 continuous delivery
Hard to test
25. “It’s perfectly fine to use async HTTP Calls”
You’ll have exactly the same issues as with sync
calls
Distribute load?!
You can serve more request
You can serve the requests faster
26.
27. HTTP General Notes
Sync by nature
Make a TCP connection for each request
No retry out of the box
No delivery guarantees
Location transparency
Good for public facing APIs
Familiar
Easy to debug
38. RPC
A kind of API call
Done through a message broker
Ties systems together but preserves their
encapsulations
Makes an external system look ‘local’
No direct code dependencies
42. Gain vs Loss
You don’t lose the requests
You can add more handler instances
You can ‘apparently’ spread the load
You can process more requests
Need to match the request
to the response
Is still sync
44. Messaging
Gives you loosely coupled integration
Doesn’t require both systems to be up
Messages ca be transformed in transit - Enrichers
Messaging systems trade consistency for availability
You don’t lose messages
Involves a Producer and a consumer
51. Gains
• Is a reaction to the problems
of distributed systems
• Process more requests
• Process request faster
• Don’t lose requests
You move the potential
issues to another
subsystem (DB in our case)
Eventual consistency
remains a problem
Loss
52. Solutions to eventual problems
Connection is scarce
Batch process the message
Use a semaphore to process them in batches
54. Agility
Faster development
No integration process
You depend only on a response
Teams have ownership and full understanding of the codebase
You can switch technologies if needed
62. Queues
Useful for point to point communication
Messages are ordered and timestamped
Pull-mode
63. Actor model
Born from Reactive Programming
Actors are processes that encapsulate behavior
Actors are more than message consumers
Can delegate and create new actors
Can supervise children
At most once delivery
66. Message Brokers
One process sends a message to a named queue/topic
One or many consumers
Handles connections and disconnections
Dead-letter queue concept
Message Guarantees ( 3 types)
Different Protocols
70. AMQP General Notes
Async by nature
Guaranteed message delivery
At-least once, exactly once, at most once delivery
No DNS resolve
Programmatic routing
Retries out-of-the box
Ack, Nack out of the box
Has the “channel” concept