Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Reactive programming

No description
by

Wanja Krah

on 26 May 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Reactive programming

In the beginning
Processor
Memory
Magic!
Then things became cool
Fast processor
More memory
Cheap storage
More magic!
Which meant:
Get instruction
Calculate instruction
Get next instruction
Which meant:
We could store our state
And make things easier
OOP
Transactions
Etc.
Now things have become professional
Everything we need
More we can ever use
Spread over the world
Working in parallel
Customers become demanding
On demand
Instant experience
All at the same time
Anywhere
Anytime
High quality
We need that cloud
But how to make use of the size of the cloud
to whatever size it must grow
The reactive manifesto
Basically a set of best practices to meet non-functionals
Or a philosophy
A revolution!
in a database!
Personalized
Reactive Systems are:
More flexible
Loosely coupled
Scalable
Easier to develop
Amenable to change
More tolerant of failure
Meet failure with elegance rather than disaster
Gives users effective interactive feedback
Reactive Systems:
Responsive
Resilient
Elastic
Message Driven
Wait a minute!
We have OO and Transactions!
Instructional
Transactional
Reactive
Change is the exception

No scaling

Failure is the exception

Customers are new

One size fits all

State is unknown

Data is volatile
Change is the norm

Scales over a countable amount
Failure is the exception

Customers are forgivable
Customers are known

State is stored

Data is structured
Change often is the norm
Scales dynamically, linear, without limit
Failure is the norm

Customers are demanding
Services are personalized real-time
State is alive

Data is massive and unstructured
functional & non-functional(!)

> 100 nodes
for the more demanding customers
without down-time, fast redeploy, etc.
tens of cores
mobile devices to cloud-based clusters running thousends of multi-core processors
seconds of response-time
milliseconds of response-time
hours of offline maintenance
100% uptime
Gigabytes of data
Petabytes of data
Forgiving customerbase
Demanding individuals
Responsive
Respond in a timely matter
Rapid
Consistent QoS
Establish a reliable upper-bound
Detect and deal with problems
Simplify error-handling
Build end user confidence
Encourage further interaction


Cornerstone of usability and utility
Resilient
Stay responsive in the face of failure
Any
(sub)
system
Replicate
to ensure high availability
Contain
failure within each component
Isolate
Fail and recover without compromising all
Delegate
recovery


Do not burden the client of a component with its failure handling
Set of instructions to meet new demands
Elastic
Stay responsive under varying workload
React to changes of input rate
Shard or replicate and distribute input
No contention points
No bottlenecks
Predictive, reactive and scaling algorithms


Achieve elasticity cost-effective on commodity hardware- and software platforms
contention point: e.g. shared datasource
Message Driven
Rely on asynchronous message passing
Establish boundaries
ensure loose coupling
isolation
location transparency
delegate errors as messages
Enables elasticity
Management of failure works with same constructs and semantics


Only consume resources while active
A large system is the sum of smaller systems, therefor:
Apply reactive design principles consiously from start
Case Twitter
Adapted from 5.700 tpm to 140.000 tpm
Decreased amount of machines 5 to 12 times
Social
Shops
News
Financial
Upper-boundary world impulses
What to expect?
Functional programming
State
Behaviour
Mailbox
Children
No shared mutable state
State predetermined by events
We love to think in state
Tricky on IO
Pro:
Con:
Actor oriented approach
CQRS - Command Query Responsibility Segregation
Different object models in different logical processes
No single representation with CRUD

Wrap up
The world has changed
We have to change
This will change everything
Now is your turn to speak
Questions
Ideas
Brainers
Critics
Calls to Action
And more:
Event sourcing
Eventually Consistant
Every state change = event
Trade-off between availlability & consistancy
Domain Driven Design
Focus on core domain and domain logic
But not only in a cloud-sense
Intel shows Moore's law:
The amount transistors within an integrated circuit doubles every two years by technical advancement
Prediction from 1965

Hit the maximum speed for one core
Amount of cores is increasing since 2006
Per 2020 3D chip stacking?

OctoCore
No difference between horizontal scaling and vertical scaling
Relational data scales bad

Isn't everything transactional?
My neighbour kid got FL 200,- a month pocket money
took the money from the bank
Hopped to Belgium
Took the same money again
Company X trashed client with 4000 loans
The money example IRL
The e-mail within the transaction
System sends e-mail per loan it is trashing
System rolls back at loan 3890
System restarts the transaction
Commands --> Domain --> Events --> Representations
My domain knows a person-entity and a address-entity
My representation knows a person with an address
Events may be:
movement
; or
address correction
A
movement
event may trigger 'gold member'
Microservices
Bounded context
'Person' within HR is different than within Finance
Integration of services
At least once delivery
At most once delivery
BUT NOT
exactly once delivery
Idempotency
Services must be idempotent
An actor handling the failure can continue the conversation
Full transcript