We're exploring "Reactive Architectures" at Senacor Technologies. This is our view on this topic - why should we go reactive and how.
It might be less than in pure theory but we need a practical approach to this topic. One that fits our company and our customers. For both worlds, we can't just throw away the existing technical steps and our skillets.
Another focus of the talk is on a few topics which did hurt us in the past but usually nobody talks about them in reactive presentations.
2. who am I?
Ralph Winzinger
Principal Architect, Senacor Technolgies
emerging technolgies, high scalable
architectures, engineering processes,
dissemination of knowledge
@rwinz
ralph.winzinger@senacor.com
8. architectural blueprint
HTML / JS
service
legacy / core integration
IoT 3rd…
API gateway
service
IMDG
native, reactive user experience,
optimized for low bandwidth access
offer high scalable service integration to
address fine grained request/response
cycles and various 3rd parties
maximize functional decoupling and
vertical decomposition up to
microservices
optimized persistence technology
aligned with functional requirement up to
high performance in-memory computing
transparently integrate legacy systems
into state-of-the-art architectures
…
9. clients & integration
high quality, native like user
experience
mobile first, responsive
design (if not native)
async communication for
maximized responsiveness
full-duplex communication
(push, partial update)
high scalable gateway
services, optimized for
handling finegrained
requests, long polling
requests, server push
integration of new channels
(e.g. WebRTC, messaging,
voice, video-chat)
async, non-blocking
Angular.js Node.js / Vert.x
10. services
no app containers
shared nothing service
architecture for easy scale
out
independent development
and deployment
vertical decomposition
aligned with functional
features
further breakdown towards
single responsibility ans
micro services
lightweight communication,
self discovery at best
resilient inter-service
connection for failover and
scalability
spring boot vert.x
11. shared nothing, almost
service service service maximum isolation between services
- no shared state (including persistence)
- no shared domain model or logic
easy scale out & easy failover
share non-functional infrastructure code
- network access, serialization, failover, …
Asgard, Hystrix, Ribbon, Finagle, Simian Army, Hazelcast, …
12. λ
I’ve seen the light … !
lambdas
streams
optionals
futures
https://github.com/ReactiveX/RxJava
RxJava
observable
observable future
loads of functions
18. event sourcing
derive object state := left fold all events
every state change is triggered by an event
apply(apply(apply(apply(new, ev0), ev1), ev2), …)
do not store state, but events
so … no persistent state … but how do I query data?
19. event sourcing & CQRS
aggregate
createEvent(cmd)
apply(ev)
command
publish
consumestore social
service
consume
hadoop
graphDB
analytics
service
query
27. deployment & ops
scale out & resilience
one service per server
ultra-fast deployment
precise monitoring
28. wanna play?
message based communication
auto discovery
location agnostic deployment
service monitoring
auto spawning / suicide
setup / tear down virtual machines
async / parallel service calls
local caching
fallback services
service call timeout
partial page update
server -> client push
circuit breaker
back pressure / thrott
bulk head