Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Easily scale enterprise applications using distributed data grids


Published on

Presented at JPrime conference 2017 (

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:

Article about flexible clustering:



Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Easily scale enterprise applications using distributed data grids

  2. 2. SCALABLE APPLICATIONS What it means? Another buzzword? @omihalyi
  3. 3. HIGHLY SCALABLE APPLICATIONS !? Just great. Buzzword Bingo time! @omihalyi
  4. 4. SERIOUSLY, WHAT ARE WE AFTER? The main Goal: add more resources to do the job faster. @omihalyi
  5. 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. 6. TYPES OF SCALING VERTICAL easy, brute force, often works inefficient, limited by physics HORIZONTAL enables granular scaling more complexity @omihalyi
  7. 7. CHALLENGES OF HORIZONTAL SCALING distributed programming increased communication shared state @omihalyi
  8. 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. 9. IN-MEMORY DATAGRIDS (1/2) distributed shared state data replication and recovery data evenly distributed distributed communication locks queues, topics, executors @omihalyi
  10. 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. 11. EXAMPLES OF DATA-GRIDS Hazelcast JBoss Infinispan Oracle Coherence Terracotta @omihalyi
  12. 12. HAZELCAST MEMORY UTILIZATION Replicated up to X nodes Data evenly distributed Lite nodes without data Off-heap data (enterprise) @omihalyi
  13. 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. 14. DEMO TIME
  15. 15. PAYARA SERVER derived from GlassFish Java EE Server embedded Hazelcast HTTP session replication JCache CDI integration message bus over CDI events @omihalyi
  16. 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. 17. SCALE UP! Once an app is designed for flexible clustering, it becomes elastic - easily adaptable to increasing load. @omihalyi
  18. 18. #1 MULTIPLICATION Additional instances more CPUs and other resources Simple load balancer is enough data is shared automatically @omihalyi
  19. 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. 20. #2 SCALING MEMORY @omihalyi
  21. 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. 22. #3 SEPARATING DATA FROM LOGIC @omihalyi
  23. 23. DEMO TIME
  24. 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. 25. #4 SCALE APP PARTS SEPARATELY @omihalyi
  26. 26. ANYTHING TO ASK? Thank you
  27. 27. RESOURCES source code: Hazelcast: , Payara: , @omihalyi OndrejM-demonstrations/scaling- with-datagrids article about flexible clustering