Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Why Reactive Architecture Will
Take Over the World
Steve Pember
GReach, 2014
A Few Questions
Have you ever...
Wondered why your company’s
codebase is all in one repo?
Have you ever...
thought “why are there so many
#@$!% tables in this database?”
Have you ever...
Dreaded executing
the unit test suite?
Have you ever...
Gone through a major
refactoring of your app?
Have you ever...
Gone on an ‘whale hunt’ on the codebase just
to add a new feature?
With “Traditional” Monolithic
Architecture,
You Can Reach MVP quickly.
The entirety of the application’s
functionality
is in one convenient location.
But that’s it.
Won’t scale?
WAIT!
...Sure, but there’s more to it.
Normal?
Architecture choice is more
important than any framework
Architecture Choice is More
Important Than Any
Framework*
*And We all Know that Only JVM Frameworks /
Languages would even...
Enter SOA
... which creates faster, leaner
code ...
... which results in rapid long-term
development time...
... and easier code
maintainability...
... which saves you Money.
Scale micro services instead of
whole systems
Each service can be written with
the methods and technologies
best suited to it
Separation of Concerns is a Good
Thing.
Also, it’s fun! l
However.
There’s some non-trivial upfront
time investing in a service
communication format.
Intra-Service communication has
a cost, particularly if it’s
synchronous.
Becoming Reactive
4 Principles of Reactive
Event-Driven
Scalable
Resilient
Responsive
No One correct Reactive
Architecture
“An application must be reactive
from top to bottom.”
-The Reactive Manifesto
Small, event-based services
Inter-service communication via
asynchronous Events
Message Brokers
Route Messages asynchronously
through a message queue when
data needs processing
RESTful Messages and Events...
... Consumers only operate on
data in the Message.
Add additional nodes to handle
load without additional
configuration
Plus Additional Decoupling on…
But which Broker to pick?
Rabbit MQ
Language Agnostic (additional decoupling)
Message Persistence
Message Recovery
A Few Examples
https://blog.twitter.com/2013/new-tweets-per-second-record-and-how
Change was Needed
Monolithic: 200-300 requests/
sec /host
Reactive: 10 - 20K requests / sec /
host
During the 2010 World Cup,
Twitter hit a record of 3283 TPS
Average 5700 TPS
Dynamically scale to 143,199
TPS…
With 5x - 12x fewer machines than
before
What about
NodeJS?
Node Has Increased Popularity of
Event-Based Programming
JS Is Not A Great Server-Side
Language
• Toy Garbage Collection
• No Proper Package Imports (for now)
• Quirky Interpreter
• Tricky scoping rules
• No Numerical ...
Groovylang has the power to
compete
Build More Event-Based Apps on
the JVM
Spread Awareness
An Anti-Case Study
Source: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
Source: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
2X FASTER!!! ….
Architecture choice is more
important than any framework
Don’t be like PayPal
Be Like Netflix
Thank You!
Image CreditsComplexity (pipes): http://www.flickr.com/photos/bhophoto/384574407/
Simple Pipeline: http://tierracos.com/ou...
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)
Próxima SlideShare
Cargando en…5
×

Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)

14.601 visualizaciones

Publicado el

The natural tendency for application developers is to construct their code in a procedural, monolithic pattern. Veteran Developers know that this leads to error prone, unscalable, slow software – yet it is alarmingly prevalent. There have been several architectural patterns that have risen over the years which have attempted to mitigate this problem. We’ve heard of Service Oriented Architecture, Integration Patterns, and Event-Driven Systems, but the Reactive pattern has the best chance for success.

In this talk I will discuss the tenants of the Reactive Pattern and the importance of moving away from Monolithic architectures into Reactive. We will examine Spring Integration and the Grails Async features (along with Netty and RabbitMQ) in order to show they can quickly and effectively help your application to become Reactive. Finally, I will argue that the JVM is the best foundation currently for this architecture – but that if we’re not careful, NodeJS may be the most popular.

Publicado en: Software

Why Reactive Architecture Will Take Over The World (and why we should be wary of NodeJS)

  1. 1. Why Reactive Architecture Will Take Over the World Steve Pember GReach, 2014
  2. 2. A Few Questions
  3. 3. Have you ever... Wondered why your company’s codebase is all in one repo?
  4. 4. Have you ever... thought “why are there so many #@$!% tables in this database?”
  5. 5. Have you ever... Dreaded executing the unit test suite?
  6. 6. Have you ever... Gone through a major refactoring of your app?
  7. 7. Have you ever... Gone on an ‘whale hunt’ on the codebase just to add a new feature?
  8. 8. With “Traditional” Monolithic Architecture, You Can Reach MVP quickly.
  9. 9. The entirety of the application’s functionality is in one convenient location.
  10. 10. But that’s it.
  11. 11. Won’t scale? WAIT!
  12. 12. ...Sure, but there’s more to it.
  13. 13. Normal?
  14. 14. Architecture choice is more important than any framework
  15. 15. Architecture Choice is More Important Than Any Framework* *And We all Know that Only JVM Frameworks / Languages would even be considered
  16. 16. Enter SOA
  17. 17. ... which creates faster, leaner code ...
  18. 18. ... which results in rapid long-term development time...
  19. 19. ... and easier code maintainability...
  20. 20. ... which saves you Money.
  21. 21. Scale micro services instead of whole systems
  22. 22. Each service can be written with the methods and technologies best suited to it
  23. 23. Separation of Concerns is a Good Thing.
  24. 24. Also, it’s fun! l
  25. 25. However.
  26. 26. There’s some non-trivial upfront time investing in a service communication format.
  27. 27. Intra-Service communication has a cost, particularly if it’s synchronous.
  28. 28. Becoming Reactive
  29. 29. 4 Principles of Reactive
  30. 30. Event-Driven
  31. 31. Scalable
  32. 32. Resilient
  33. 33. Responsive
  34. 34. No One correct Reactive Architecture
  35. 35. “An application must be reactive from top to bottom.” -The Reactive Manifesto
  36. 36. Small, event-based services
  37. 37. Inter-service communication via asynchronous Events
  38. 38. Message Brokers
  39. 39. Route Messages asynchronously through a message queue when data needs processing
  40. 40. RESTful Messages and Events... ... Consumers only operate on data in the Message.
  41. 41. Add additional nodes to handle load without additional configuration
  42. 42. Plus Additional Decoupling on…
  43. 43. But which Broker to pick?
  44. 44. Rabbit MQ Language Agnostic (additional decoupling) Message Persistence Message Recovery
  45. 45. A Few Examples
  46. 46. https://blog.twitter.com/2013/new-tweets-per-second-record-and-how
  47. 47. Change was Needed
  48. 48. Monolithic: 200-300 requests/ sec /host Reactive: 10 - 20K requests / sec / host
  49. 49. During the 2010 World Cup, Twitter hit a record of 3283 TPS
  50. 50. Average 5700 TPS Dynamically scale to 143,199 TPS…
  51. 51. With 5x - 12x fewer machines than before
  52. 52. What about NodeJS?
  53. 53. Node Has Increased Popularity of Event-Based Programming
  54. 54. JS Is Not A Great Server-Side Language
  55. 55. • Toy Garbage Collection • No Proper Package Imports (for now) • Quirky Interpreter • Tricky scoping rules • No Numerical Precision
  56. 56. Groovylang has the power to compete
  57. 57. Build More Event-Based Apps on the JVM
  58. 58. Spread Awareness
  59. 59. An Anti-Case Study
  60. 60. Source: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
  61. 61. Source: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
  62. 62. 2X FASTER!!! ….
  63. 63. Architecture choice is more important than any framework
  64. 64. Don’t be like PayPal
  65. 65. Be Like Netflix
  66. 66. Thank You!
  67. 67. Image CreditsComplexity (pipes): http://www.flickr.com/photos/bhophoto/384574407/ Simple Pipeline: http://tierracos.com/our-companies/tierra-pipeline/ Highway: http://farnorthdallas.advocatemag.com/wp-content/uploads/2013/04/882349_500402383328407_539732406_o.jpg Homer & doughnuts: http://thechurchillreview.blogspot.com/2012/10/feeling-terror-too-young-aka-kiddie.html Tom Brady: http://stamperdad.wordpress.com/category/tom-brady/ Telephone Exchange Operator: http://fineartamerica.com/featured/telephone-exchange-1920s-granger.html People in Queue: http://www.guardian.co.uk/money/2010/mar/23/dole-queue-jobseekers-online Cookie Monster: http://muppet.wikia.com/wiki/Cookie_Monster_Through_the_Years Scrooge McDuck: http://smallbusiness.uprinting.com/how-pennies-are-hurting-small-business/ Too Many Cooks: http://www.ecommercesystems.com/featured-articles/cooks-kitchen-driving-ecommerce-business/ Clustered Macs: http://www.uiowa.edu/mihpclab/micg.html Resuscitate: http://www.dailymail.co.uk/health/article-2034160/Do-resuscitate-Theyre-fateful-words-meaning-doctors-wont-try-save-you- collapse-hospital.html Iron Man: http://images.wikia.com/marvelmovies Mail Sorting: http://riversidechamber.files.wordpress.com Twitter Logo & app chart: https://blog.twitter.com/engineering Modern Server Farm: http://bookriot.com/2013/03/26/book-less-libraries-and-other-contemporary-realities/ Grey World: http://upload.wikimedia.org/wikipedia/commons/d/d0/BlankMap-World-1ce.png Monolith: http://sofakingwetarrededd.blogspot.com/2012_12_01_archive.html Star Trek: http://www.gifbin.com/984064 Reactive Manifesto: http://www.reactivemanifesto.org/ Cheetah: http://www.livescience.com/21944-usain-bolt-vs-cheetah-animal-olympics.html Buzzword Bingo: http://www.amsterdamadblog.com/columns/buzzword-bingo/ Businessman meditating: http://www.huffingtonpost.co.uk/2013/07/09/meditation-successful-businessmen_n_3567694.html Chaos Monkey: http://luckyrobot.com/netflix-chaos-monkey-keeps-movies-streaming/ NodeJS: http://misclassblog.com/interactive-web-development/node-js/ Turtles: http://people.wcsu.edu/pinout/herpetology/tcarolinei/29366343.EasternBoxTurtle2.jpg, http://www.huffingtonpost.com/2013/04/26/24-tiny-turtles-who-need-a-reality-check_n_3134793.html, http://www.ecology.com/2012/05/23/world-turtle-day/

×