SpringOne Platform 2017 Paul Perez, Pymma Further to our customers request, we had to implement a fine monitoring system for the OpenESB business process engine. The largest OpenESB configurations on production runs concurrently dozens of engine instances, that daily, generate up to 10 billion of events. These events must be aggregated and analysed to generate data for monitoring. A classical solution would be to store the events first and then process them in a batch mode. Simply, it would require too much storage and CPU capacities to process this number of events and a too long delay to provide monitoring information on time. So, our architect decided to process the message coming from our engines as a stream of events. This processing involves three types of application.The buffer: It is used to store the events coming from the event providers (here OpenESB). The buffer must have a very low latency to capture a huge number of events without slowing down the event producer. At the same time, the buffer must capture data from multiple producer concurrently. This involves a powerful support of distributed and concurrent processes. Apache Kafka, Cassandra are some good examples of buffer. The engine: the engine implements a kind of step by step process with intermediate states. Each step executes a part of the event aggregation and analysis process, and generate intermediate state useful for the next steps. For obvious efficiency reasons, the intermediate states must not be stored outside the engine. One of the engine key feature is to process concurrently numerous events on many machines. Apache Spark and especially Apache Storm are typical examples of this type of software. The persistence system: when the event aggregation or analysis process is complete, the process results are sent to a persistence system which implements a query language to provide an easy access to the results. MongoDB, Crate, PostgreSQL, Greenplum can be used as a persistence system.Soevent aggregation or analysis process requires knowledge and installation of three or more different software. And this said, companies are reluctant to dedicate such budget and time to deploy an event aggregation or analysis process chain.In our presentation, we demonstrate how, at our profit, GemFire or Geode can act as a buffer, an engine and a persistence system and avoid the multiplication of software and deployment. We explain how the asynchronous Event Queue and Event Handler work together to act as an engine which support step by step aggregation and analysis process, and take advantage of the distributed cache to work as a buffer and a result store. We also detail how GemFire partitioned region internal design, provides a great scalability and provides very good results for events aggregation and data analysis.We hope that thanks to this presentation, the delegate will get a different point of view on GemFire or Geode and would like to use it as an event processing system.

1. Apache Geode
An efficient alternative to
Kafka-Storm-Spark
By Paul Perez
Pymma
1

2. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
About (s)
Paul Perez
Architect at Pymma
Fan of integration technologies
Long love story with Geode family
1998: Gemstone App Server
2006: Presale in UK
2017: Geode features in OpenESB
2
Bureau of IT architecture
Based in London (UK)
Founded in 1999
Expertise on
Architecture design
Software integration
One of the main OpenESB contributors

3. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
About OpenESB
Three examples
1-Service oriented projects
2-Domain synchronisation
3-Exchanges between data sets
More than an Enterprise Service Bus
It is an Extended Service Bus
3
Open Extended Services
Bus
Powerful integration tool
Reliable, light and scalable
Integration best practices
Ubiquitous product
Large systems to Raspberry PIs
Used in a large scope of projects

4. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
4
Receive Transfer
order by email
Swift transfer
Send email for
confirmation
Check account
Banker validation
Log transaction
Check rights
Ex 01: Service Oriented Application
4
Manual
Validation
Service invocation
Service publication
Service orchestration
Service composition
International
Fund transfer

5. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
5
Ex 02: Domains synchronization
5
Domain Model
Pilote
Domain Model
Meals
Domain Model
Luggage
Domain Model
Ticket
Domain Model
Plane
Domain Model
Airport
UPDATE
Dependency
Knowledge = dependency
Difficulties to upgrade the domains
Domain-Driven Design

6. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Domain Model
Luggage
Domain Model
Ticket
Update
Update
Ex 02: Domains synchronization
6
Domain Model
Pilote
Domain Model
Meals
Domain Model
Plane
Domain Model
Airport
Update
Event
Update
Update
Update
No
Dependency

7. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Ex 03: Exchanges between data sets
7
• Street lights
• Cross road
• Monument
400 000 light sources in Paris
• Long delay before fault detection
• Long delay to inform the maintenance teams
Street light maintenance is difficult

8. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Ex 03: Exchanges between data sets
8
Street light
Light sensor Internet relay
Light
Regular
messages
Analytics toolTask lists for
maintenance teams
Storage

9. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Ex 03: Exchanges between data sets
9
Reporting
Tools
MQTT Messages
MQTT
Servers
Relational
Database
Intelligent
Event
Processing
Intelligent
Event
Processing

10. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Analytics System
OpenESB and Analytic requirements
10
Process
Start
Process
Complete

11. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
What are our constraints?
Two main constraints
The event content is a raw message to refine
What – when – where
Billions of events are generated daily
Process, activity and variable events
The analytics process must run out of OpenESB
OpenESB has not been designed for this task
OpenESB resources must be mainly dedicated for the processes
An external system is needed to fulfil analytics requirements
11

12. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Events and messages processing
12
External System
Events
Which external analytic system
for OpenESB ?

13. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Educational example for this presentation
13
Compute
duration
Average
per day
Average
per sec
Average
per min
Average
per hour
Process
Start
Process
Complete

14. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
External System: Global view
14
External System
Buffer Engine Persistence
Engine
Design for stream processing
Good performances
Horizontal scalability
Java language supported
Buffer
Asynchronous ingestion
Compliant with the engine
Horizontal scalability
Java language supported
Persistence container
Any type of persistence
SQL-NoSQL
File System
Not covered here

15. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
External System: The buffer
Asynchronous partner
Wonderful data ingestion
Very good feedback
Lot of learning resources available
Uses disks to store messages
Requires Zookeeper to run
Powerful message ingestion
Asynchronous communication
Release OpenESB resources
Good guarantee of delivery
Horizonal scalability
Compliant with many engines
15
Buffer

16. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
External System: The engine
Spark and Storm were good candidates
Designed for “real time” streaming
Good horizontal scalability
Good feedbacks from many projects
We decided to use Storm
Storm: Matched our background
Spark: Very active project
Spark: Micro batch less suitable for streaming
Spark: Java API more complex (Scala)
Storm: Easier to understand
Storm: Elegant architecture
Storm: Requires Zookeeper to run
16

17. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
External System: The engine
17
Compute
Duration
Average
per day
Average
per sec
Average
per min
Average
per hour
BPEL
complete
BPEL
start
Spout
Bolt
Persistenc
e
Topology

18. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Executor
External System: The engine
18
Topology
Executor
Executor
Executor

19. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
External System
Powerful event processing chain
Worked well and quickly in a POC
Provides a good horizontal scalability
Complex to install
Requires too many skills and too much expertise
Logically, our customers refused this offer
Our customers wanted a simpler solution
19
ZOOKEEPER

20. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
20
An alternative ?

21. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Apache geode: an alternative
We searched for a simpler solution
An all-in-one product to replace, the buffer and engine
Research on the market
Gemfire / Geode looked like a good candidate
We had enough background to give Geode a go
Apache Geode
Good message ingestion
Horizontal scalability
Event framework that can compete with Storm
21

22. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Kafka and Geode comparison
Strong capability of ingestion
Good horizontal scalability
High quality of service
Fault tolerance
Stores data on disk
Requires ZooKeeper
Mainly the same features but
Simpler to understand
No additional products needed
Stores data in memory
Memory is limited (few TBytes)
(We don’t need Terabytes of memory)
22

23. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Storm and Geode comparison
Light and efficient architecture
Dedicated for event-stream processing
Designed for process parallelisation
Does not deal with data storage
Horizontal scalability
Requires ZooKeeper
Single point of failure possible
Often seen as a distributed cache but
Complete Event framework
Developed to design push architectures
No additional product
No single point of failure
No congestion point
Data and processes collocate in Geode
23

24. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
24
Asynchronous event
framework

25. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Region
N
Handler 01
Region
01
Asynchronous Event framework
25
Asynchronous
Event Queue
Event Events
Geode event framework
Entry creation, update, deletion generates events
Events are sent to a queue
The handlers feed the next regions to carry on the analytics process
This design is similar to the one defined in Storm
The analytics process is smartly divided in steps
Event

26. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Asynchronous Event framework
AEQ in parallel mode vs serial mode
Parallel= false: serial mode
One queue per region (Keep events order, but possible point of contention)
Parallel= true: parallel mode
One queue per member per region (Horizontal Scalability)
26
create async-event-queue --id=BPELAEQ --
listener=com.pymma.bpel.monitoring.geode.aggregation.BPELEventAggregation
Duration --parallel=true --batch-size=10000 -- batch-time-interval=100 --
group=groupA
create region --name=eventBpelStop --type=PARTITION --group=groupA

27. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Machine 01
Machine 03
Machine 02
Asynchronous Event framework
Parallel=false
Mode=Serial
Keep event order
Contention possible
27
A2
A1
A3
Handler

28. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Machine 01
Machine 03
Machine 02
Asynchronous Event framework
Parallel=True
Mode=Parallel
Horizontal scalability
28
A2
A1
A3
Handler
Handler
Handler

29. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Machine 03
Machine 01
Geode scalability
29
01
Compute
01
02
01
Compute
01
02
Machine 02
01
Compute
01
02
Compute
02
03
Compute
02
03
Compute
02
03

30. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Geode Scalability
Partitioned regions improve the horizontal scalability
Automatic scalability
Not the case with replicated regions
Bonus: High guarantee of delivery
Automatic redundancy in case of failure
Redundant entries don’t generate multiple events
A region event is generated once and only once
The event unicity is guaranteed
30

31. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Storm vs Geode scalability
31
Spout

32. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Storm vs Geode scalability
32
Storm’s scalability:
Provided by the bolts redundancy
Geode scalability:
Provided by the process redundancy
Scalability granularity
Storm: Tuning at the step level (finest granularity)
Geode: Tuning at the process level (coarsest granularity)
Additional effort required to get the same granularity level

33. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Geode scalability
33
01 02
01 02
01 02
03
03
03
02
02

34. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Geode scalability
34
Adding regions could be an opportunity
To increase the scalability of a step
To get a better granularity for the scalability
But it stops the opportunity
To improve the collocation
To run all the process steps in the same JVM
To avoid network slowdowns
See Murex “Olivier Mallassi” SpringOne 2016
Topic behind the scope of this presentation

35. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Conclusion
35
ZOOKEEPER

36. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Conclusion
Good performances
Simple deployment
Easy scalability
Just add new members
Reliability
No single point of failure
Less resource and budget required
More flexible architecture
Better acceptance from our customers
Good performances
Complex deployment
Complex Scalability
Combination Kafka, Storm,
Zookeeper
Storm: Fine grain scalability
Reliability
Presumed SPOF with Storm/Nimbus
High resource and budget required
Rejected by our customers
36
Apache GeodeKafka + Storm + Zookeeper

37. Unless otherwise indicated, these slides are © 2013 -2016 Piv otal Software, Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
Conclusion
Geode has a unique design
Data and processes collocate in the same environment
Ultra fast exchanges in memory
For our project
This design overcomes Kafka, Storm used separately
It advantageously supersedes Kafka + Storm together
Apache geode became our first choice for that project
37

38. Thank you for your interest !!!
Questions and Comments ?