The Seneca Pattern at EngineYard Distill 2013 Conference

Like this? Share it with your network

Share

The Seneca Pattern at EngineYard Distill 2013 Conference

  • 1,694 views
Uploaded on

A discussion of the psychological basis for the Seneca message-passing and micro-service pattern.

A discussion of the psychological basis for the Seneca message-passing and micro-service pattern.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,694
On Slideshare
1,671
From Embeds
23
Number of Embeds
1

Actions

Shares
Downloads
9
Comments
0
Likes
3

Embeds 23

https://twitter.com 23

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. How do You Build Big Apps? @rjrodger senecajs.org Tuesday 13 August 2013
  • 2. Technical Debt Tuesday 13 August 2013
  • 3. "A good plan, violently executed now, is better than a perfect plan next week." Tuesday 13 August 2013
  • 4. You Must take on Technical Debt or You Will Die Tuesday 13 August 2013
  • 5. Sometimes, it Happens Anyway Tuesday 13 August 2013
  • 6. Tuesday 13 August 2013
  • 7. Tuesday 13 August 2013
  • 8. Tuesday 13 August 2013
  • 9. NTSC 1941 Standard: Black+White only Signal encodes Brightness Each Channel gets 6Mhz Happy Days! Tuesday 13 August 2013
  • 10. Color Television Three Colors: Red, Green, Blue Each Color needs 3Mhz You only have 6Mhz and you need 9Mhz! Technical Debt FTW Tuesday 13 August 2013
  • 11. You can't Break the old Black+White TVs Tuesday 13 August 2013
  • 12. We must send the old brightness signal White Light = 30% Red 59% Green 11% Blue Send White, Red and Blue Tuesday 13 August 2013
  • 13. You need to embed the color signals inside the brightness signal Tuesday 13 August 2013
  • 14. Color TV circuits are more complicated than they should be. Tuesday 13 August 2013
  • 15. How do you Reduce Technical Debt? Tuesday 13 August 2013
  • 16. Longer and more detailed Specifications! Tuesday 13 August 2013
  • 17. Better Languages Better Mental Models Tuesday 13 August 2013
  • 18. How did the Romans do Long Division? Tuesday 13 August 2013
  • 19. LXXII MMMDCXII L rem XII Tuesday 13 August 2013
  • 20. How did the Romans do Addition? Tuesday 13 August 2013
  • 21. 1. Normalize: IV → IIII 2. Concatenate: IIII + XI → IIIIXI 3. Sort, descending: IIIIXI → XIIIII 4. Reduce: XIIIII → XV IV + XI = ? Tuesday 13 August 2013
  • 22. How did the Romans do Subtraction? Tuesday 13 August 2013
  • 23. 1. Normalize: XXIV → XXIIII 2. Eliminate: XXIIII - XV → XIIII - V 3. Expand: XIIII - V → VIIIIIIIII - V 4. Repeat 2 and 3 until no moves left 5. Reduce: IIIIIIIII → IX XXIV - XV = ? Tuesday 13 August 2013
  • 24. How did the Romans do Multiplication? Tuesday 13 August 2013
  • 25. III → 3 VI → 6 → 110 III × VI = ? 3 × 001 × 0 = 0 3 × 010 × 1 = 6 3 × 100 × 1 = 12 18 bit shifting Tuesday 13 August 2013
  • 26. How did the Romans do Division? Tuesday 13 August 2013
  • 27. they didn't Tuesday 13 August 2013
  • 28. Roman Numerals have Technical Debt Tuesday 13 August 2013
  • 29. Tuesday 13 August 2013
  • 30. Positional Number Systems make us Smarter Tuesday 13 August 2013
  • 31. Mental Models for Code Tuesday 13 August 2013
  • 32. Procedural Functional Object-Oriented Logic Tuesday 13 August 2013
  • 33. Let's Experiment Tuesday 13 August 2013
  • 34. Stand up. Everybody. Tuesday 13 August 2013
  • 35. Is this a car? Tuesday 13 August 2013
  • 36. YES NO Stay standing Sit down And stay down! Tuesday 13 August 2013
  • 37. Tuesday 13 August 2013
  • 38. Tuesday 13 August 2013
  • 39. Tuesday 13 August 2013
  • 40. Tuesday 13 August 2013
  • 41. Tuesday 13 August 2013
  • 42. Tuesday 13 August 2013
  • 43. Objects are Roman Numerals Tuesday 13 August 2013
  • 44. Objects break as system complexity grows Tuesday 13 August 2013
  • 45. The need for design "patterns" is telling you something Tuesday 13 August 2013
  • 46. Procedural Functional Object-Oriented Logic Tuesday 13 August 2013
  • 47. Procedural code tends to Spaghetti Tuesday 13 August 2013
  • 48. Procedural Functional Object-Oriented Logic Tuesday 13 August 2013
  • 49. Functional and Logic are More Powerful Tuesday 13 August 2013
  • 50. What Happened? Why didn't they Win? Tuesday 13 August 2013
  • 51. Technical Debt Tuesday 13 August 2013
  • 52. Procedural Functional Object-Oriented Logic Tuesday 13 August 2013
  • 53. What do we Need? Tuesday 13 August 2013
  • 54. A Better Mental Model Tuesday 13 August 2013
  • 55. Easy to Learn Easy to Scale (humans) Easy to Scale (machines) Easy to Implement Easy to build a Mental Model Does not have to achieve Very Large Scale Tuesday 13 August 2013
  • 56. We need Models that Work for Human Brains Tuesday 13 August 2013
  • 57. Why is Ruby on Rails Popular? Tuesday 13 August 2013
  • 58. Opinionated == Shared Mental Model Tuesday 13 August 2013
  • 59. Ruby on Rails Model is an Accident of History Tuesday 13 August 2013
  • 60. Let's Design a Model! Tuesday 13 August 2013
  • 61. What does a Programmer do? Self-contained Algorithms Procedural Business Logic Fitting it all Together Tuesday 13 August 2013
  • 62. Fitting it all Together is the Hard Part Tuesday 13 August 2013
  • 63. What are Humans Good At? Tuesday 13 August 2013
  • 64. If a card has a vowel on one side, it must have an odd number on the other. Which cards should you turn over to verify that the rule is followed? Tuesday 13 August 2013
  • 65. If you're drinking beer, you must be 21 or over. Which patrons should you ask for ID? Tuesday 13 August 2013
  • 66. You solved the second version using Pattern Matching Tuesday 13 August 2013
  • 67. Why is Pattern Matching Such a Win? Tuesday 13 August 2013
  • 68. We are Pattern Matchers It scales for humans and machines Works without needing context Tuesday 13 August 2013
  • 69. Why do I Care? Tuesday 13 August 2013
  • 70. We build Minimum Viable Products for startups. It's all about technical debt. Tuesday 13 August 2013
  • 71. Lucius Annaeus Seneca Tuesday 13 August 2013
  • 72. The Seneca Strategy Tuesday 13 August 2013
  • 73. Embrace Micro-Services Tuesday 13 August 2013
  • 74. Lots of Little Processes Do one thing, and do it Well Communicate with Messages Tuesday 13 August 2013
  • 75. Pattern Match on Messages Tuesday 13 August 2013
  • 76. Messages are Asynchronous Send them any way you like Use JSON as the data model Tuesday 13 August 2013
  • 77. "Send Tweet" Acted on by Tweet Service Example { command:"tweet" author:"@rjrodger" status:"Distill Rocks!" } Tuesday 13 August 2013
  • 78. Tweet Service If I see a message with this property: Match the Pattern! command:"tweet" It's Mine! I don't care how you get it to me. And I'll ignore anything else. Tuesday 13 August 2013
  • 79. The Tweet Service can be written in Any Language Tuesday 13 August 2013
  • 80. Keep it Small Die and restart on Errors Report your status Tuesday 13 August 2013
  • 81. Level Up The Pattern Matching Tuesday 13 August 2013
  • 82. Patterns map to Actions Tuesday 13 August 2013
  • 83. cmd:drive start engine, and go! cmd:drive, type:hover turn on anti-gravity start engine and go! Example Tuesday 13 August 2013
  • 84. Two Rules to make this Unique 1. More properties always wins 2. Check properties alphabetically Tuesday 13 August 2013
  • 85. cmd:drive cmd:drive, type:hover Mapping cmd: drive type: wheel speed: 50 cmd: drive type: hover speed: 100 Tuesday 13 August 2013
  • 86. One More Thing Tuesday 13 August 2013
  • 87. Layers Tuesday 13 August 2013
  • 88. When you add a pattern: If the pattern Already Exists, Keep the Old Action, so you can use it inside the New Action Tuesday 13 August 2013
  • 89. cmd:drive start engine, and go! cmd:drive call prior action set speed to speed Example Tuesday 13 August 2013
  • 90. Implementation senecajs.org Tuesday 13 August 2013
  • 91. Let's build stuff! Tuesday 13 August 2013
  • 92. Blog Data Layer Platform-as-a-Service Tuesday 13 August 2013
  • 93. the actions are Blog cmd:draft, post:content cmd:publish, post:id cmd:redact, post:id cmd:homepage cmd:comment, post:id, comment:comment Tuesday 13 August 2013
  • 94. action, not abstraction easy to learn easy to modify easy to maintain self-documenting Win Tuesday 13 August 2013
  • 95. the actions are Data Layer cmd:save, name:entity cmd:load, name:entity cmd:list, name:entity cmd:remove, name:entity Tuesday 13 August 2013
  • 96. save some data cmd: save, name: product, data: { name: Apple, price: 1.99 } Tuesday 13 August 2013
  • 97. load some data cmd: load, name: product, query: { name:Apple } Tuesday 13 August 2013
  • 98. implement the actions cmd:save insert into table name values data cmd:load select * from name where query Tuesday 13 August 2013
  • 99. add caching cmd:save call prior action write into cache data cmd:load read data from cache if found, return data, else call prior action Tuesday 13 August 2013
  • 100. layers cmd:save call prior action write into cache data cmd:load read data from cache if found, return data, else call prior action insert into table name values data select * from name where query Tuesday 13 August 2013
  • 101. more data layers validation permissions throttling custom logic multiple databases ... Tuesday 13 August 2013
  • 102. multiple databases cmd:save, name:session save data to redis cmd:save insert into table name values data when entity is a session: all other entities: Tuesday 13 August 2013
  • 103. fine-grained control easy to extend easy to customize easy to debug - there's no magic Win Tuesday 13 August 2013
  • 104. Micro-Services deployer dispatcher controller Platform-as-a-Service Tuesday 13 August 2013
  • 105. deployer controller dispatcher app appapp requests start stop install route dashboard Tuesday 13 August 2013
  • 106. controller actions dash:install, app:details submit cmd:install, app:details to message bus (deployer picks up) dash:start, app:id submit cmd:start, app:id to message bus (dispatcher picks up) dash:stop, app:id submit cmd:stop, app:id to message bus (dispatcher picks up) Tuesday 13 August 2013
  • 107. deployer actions cmd:install, app:details download app code to server get route from app details submit cmd:route, route:path, server:server to message bus (dispatcher picks up) Tuesday 13 August 2013
  • 108. dispatcher actions cmd:route add route and server to local routing table cmd:start, app:id start routing requests to app cmd:stop, app:id stop routing requests to app Tuesday 13 August 2013
  • 109. controller, dispatcher, deployer are all in one app install apps to localhost focus on what, not how Prototype Tuesday 13 August 2013
  • 110. controller, dispatcher, deployer are separate processes communicate via direct HTTP apps live on VMs but ... no design changes! Minimum Viable Product Tuesday 13 August 2013
  • 111. controller, dispatcher, deployer are many processes communicate via a message bus apps live anywhere but ... no design changes! Scale It Tuesday 13 August 2013
  • 112. build now, scale later! easy refactoring language independence easily observe and manage Win Tuesday 13 August 2013
  • 113. How do You Build Big Apps? Tuesday 13 August 2013
  • 114. Design for Many Languages Tuesday 13 August 2013
  • 115. Design for Scale (human + machine) Tuesday 13 August 2013
  • 116. Design for Human Brains Tuesday 13 August 2013
  • 117. Thank You! @rjrodger senecajs.org Tuesday 13 August 2013