While a microservices architecture is more scalable than a monolith, it has a direct hit on performance. To cope with that, one performance improvement is to set up a cache. It can be configured for database access, for REST calls or just to store session state across a cluster. In this demo-based talk, I’ll show how Hazelcast In-Memory Data Grid can help you in each one of those areas and how to configure it. Hint: it’s much easier than one would expect.
Takeaways:
• Microservices are not for everyone
• Microservices actually decrease performance but allow for horizontal scaling
• Hazelcast IMDG can with the performance hit caused by microservices (or clustered application in general)
3. @nicolas_frankel
Hazelcast
HAZELCAST IMDG is an operational,
in-memory, distributed computing
platform that manages data using
in-memory storage, and performs
parallel execution for breakthrough
application speed and scale.
HAZELCAST JET is the ultra fast,
application embeddable, 3rd
generation stream processing
engine for low latency batch
and stream processing.
4. @nicolas_frankel
• Componentization via Services
• Smart endpoints and dumb pipes
• Decentralized Governance
• Decentralized Data Management
• Infrastructure Automation
• Design for failure
• Evolutionary Design
• Organized around Business Capabilities
• Products not Projects
Microservices: a tentative definition
https://martinfowler.com/articles/microservices.html
7. @nicolas_frankel
« You have to be in a really unusual spot to see in-
process function calls turn into a performance hot spot
these days, but remote calls are slow. If your service
calls half-a-dozen remote services, each which calls
another half-a-dozen remote services, these response
times add up to some horrible latency
characteristics. »
-- https://martinfowler.com/articles/microservice-trade-offs.html
Distributed systems
8. @nicolas_frankel
• The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
• Topology doesn't change
• There is one administrator
• Transport cost is zero
• The network is homogeneous
Fallacies of distributed computing
https://yourlogicalfallacyis.com/
17. @nicolas_frankel
• Level 1 cache
• Implemented by default
• Related to the Session object
• Level 2 cache
• Optional
• Multiple integrations available
Hibernate
18. @nicolas_frankel
• The cache doesn’t contain the key
1. Load from the database
2. Put it in the cache
• The cache contains the key
1. Return it
How it reads
21. @nicolas_frankel
• The code only interacts with
Hazelcast
• Registered listeners allow to write
to the database
• Sync or async
Alternative
22. @nicolas_frankel
• Catalog service
• Stock service
• Pricing service
• Cart service
• Recommendation service
• Payment service
• etc.
E-commerce architecture
28. @nicolas_frankel
1. Filter-based
2. Spring Session integration
3. Direct Tomcat integration
• Per-node configuration
• Or through Spring Boot embedded
4. Direct Jetty integration
Hazelcast to the rescue!
30. @nicolas_frankel
Takeaways
• Scalability and performance are not the same
• Caching helps performance
• The cost is stale data
• Hazelcast IMDG provides several integration-points
for caching across different areas
• Database access
• HTTP call
• Session data
@startuml
participant "a:A" as a
boundary "Layer X" as x
boundary "Layer Y" as y
boundary "Layer Z" as z
participant "b:B" as b
activate a
a -> x: call()
activate x
x -> y: call()
activate y
y -> z: call()
activate z
z -> b: call()
hide footbox
@enduml
participant "a:A" as a
boundary "Layer X" as x
boundary "Layer Y" as y
boundary "Layer Z" as z
participant "b:B" as b
activate a
a -> x: call()
activate x
x -> y: call()
activate y
y -> z: call()
activate z
z -> b: call()
z <-- b
y <-- z
deactivate z
x <-- y
deactivate y
a <-- x
deactivate x
deactivate a
skinparam dpi 300
hide footbox