Presented at JPrime conference 2017 (jprime.io) With the right tools, building scalable applications can be much easier than it seems. I want to show you the variety of options you get when you design applications around distributed data grids. They can become a backbone for building horizontally scalable applications, while at the same time providing flexible caching to scale up the performance vertically. Suddenly it will be possible to tweak the applications beyond what you would expect, with very little effort, often without even rebuilding the applications. We’ll analyze what’s possible and how to do it, not only in theory but also demonstrating on an application based on Java EE, Hazelcast, and Node.js. In the end, you’ll understand the power of distributed data grids and how to use them efficiently to scale the applications in various scenarios, be it high-throughput, low-latency, microservice architecture and more. Source code: https://github.com/OndrejM-demonstrations/scaling-with-datagrids Article about flexible clustering: http://blog.payara.fish/flexible-clustering-with-payara-server Hazelcast: hazelcast.com, hazelcast.org Payara: payara.fish, payara.org

1. EASILY SCALE ENTERPRISE
APPLICATIONS USING
DISTRIBUTED DATA GRIDS
Ondrej Mihályi
@omihalyi

2. SCALABLE APPLICATIONS
What it means? Another buzzword?
@omihalyi

3. HIGHLY SCALABLE APPLICATIONS !?
Just great. Buzzword Bingo time!
@omihalyi

4. SERIOUSLY, WHAT ARE WE AFTER?
The main Goal:
add more resources to do the job
faster.
@omihalyi

5. WHAT IS SCALABILITY
Ability to improve with more resources
Not straightforward
More working hours ≠ more done
More people on the job ≠ faster
@omihalyi

6. TYPES OF SCALING
VERTICAL
easy, brute force, often works inefficient,
limited by physics
HORIZONTAL
enables granular scaling
more complexity
@omihalyi

7. CHALLENGES OF HORIZONTAL
SCALING
distributed programming
increased communication
shared state
@omihalyi

8. AVOIDING BOTTLENECKS
:
Speedup limited by the parts that
don't benefit from added resources
bottlenecks: sequential tasks,
synchronization, communication
@omihalyi
AMDAHL'S LAW

9. IN-MEMORY DATAGRIDS (1/2)
distributed shared state
data replication and recovery
data evenly distributed
distributed communication
locks
queues, topics, executors
@omihalyi

10. DISTRIBUTED IN-MEMORY
DATAGRIDS (2/2)
simplified programming model
common structures (map, set, ...)
service-discovery, load-balancing
distributed execution
code and queries sent to the data
bonus: fast persistence with no ORM
@omihalyi

11. EXAMPLES OF DATA-GRIDS
Hazelcast
JBoss Infinispan
Oracle Coherence
Terracotta
@omihalyi

12. HAZELCAST MEMORY UTILIZATION
Replicated up to X nodes
Data evenly distributed
Lite nodes without data
Off-heap data (enterprise)
@omihalyi

13. OTHER HAZELCAST FEATURES
Auto discovery and recovery
multicast and TCP joiners
data redistribution when nodes join/leave
Distributed cache (JCache API)
Distributed queries and ExecutorService
@omihalyi

14. DEMO TIME

15. PAYARA SERVER
derived from GlassFish Java EE Server
embedded Hazelcast
HTTP session replication
JCache CDI integration
message bus over CDI events
@omihalyi

16. PAYARA MICRO
derived from embedded GlassFish
executable JAR or embedded
web apps in a separate file or uber JAR
designed for flexible clustering
Hazelcast started by default
@omihalyi

17. SCALE UP!
Once an app is designed for flexible
clustering, it becomes elastic - easily
adaptable to increasing load.
@omihalyi

18. #1 MULTIPLICATION
Additional instances
more CPUs and other resources
Simple load balancer is enough
data is shared automatically
@omihalyi

19. #2 SCALING MEMORY
Data access is often a bottleneck
→ Keep data in memory
Additional instances with no apps
Dumb nodes carrying data
Increase available memory
Increase resilience to outages
@omihalyi

20. #2 SCALING MEMORY
@omihalyi

21. #3 SEPARATING DATA FROM LOGIC
more data → more heap and time in GC
run critical apps on lite nodes
slower data access but less GC cycles
tweak GC & heap for throughput
data and app nodes in pair on the same
machine
@omihalyi

22. #3 SEPARATING DATA FROM LOGIC
@omihalyi

23. DEMO TIME

24. #4 SCALE APP PARTS SEPARATELY
some parts of an app are bottlenecks
split those into separate services
can be scaled higher
resources assigned more granularly
small and lean services with Payara Micro
or even a standalone Hazelcast
@omihalyi

25. #4 SCALE APP PARTS SEPARATELY
@omihalyi

26. ANYTHING TO ASK?
Thank you

27. RESOURCES
source code:
Hazelcast: ,
Payara: ,
@omihalyi
OndrejM-demonstrations/scaling-
with-datagrids
article about flexible clustering
hazelcast.com hazelcast.org
payara.fish payara.org