Successfully reported this slideshow.

Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco

14

Share

Loading in …3
×
1 of 165
1 of 165

More Related Content

More from Alessandro Nadalin

Related Books

Free with a 14 day trial from Scribd

See all

Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco

  1. 1. TIPS AND TRICKS FOR YOUR SERVICE ORIENTED ARCHITECTURE CakeFest, San Francisco, Sep 2013
  2. 2. WARNING
  3. 3. NO CAKEPHP AHEAD
  4. 4. This talk is for those...
  5. 5. Stuck with the legacy
  6. 6. dealing with CRONs
  7. 7. in the need of a solid foundation
  8. 8. rely on web services
  9. 9. need a pluggable software architecture
  10. 10. SOA
  11. 11. Agenda 1. Service Oriented WHAT?!?! 2. Tips, Tricks and lessons learned (the hard way) 3. Conclusion
  12. 12. 1
  13. 13. SO(A) WHAT?
  14. 14. A software design based on discrete software components, "services", that collectively provide the functionalities of the larger software application
  15. 15. You typically start with the infamous web application which does everything on its own
  16. 16. Then you realize that to provide a chat system to your users PHP might not be the best...
  17. 17. And soon you also decide, to improve performances, that your frontend should have its own in-memory persistence, to be faster and you put it into another service
  18. 18. Then, as always...
  19. 19. SCALE.
  20. 20. And eventually, your lead architect will come up and tell you that your Java-based chat sucks and should be replaced with...
  21. 21. NODEJS
  22. 22. In human-understandable words, SOA is a software design which embraces splitting a monolithic, totalitarian software architecture into smaller pieces, thus making them independent, loosely coupled and more maintainable
  23. 23. Ok, but in the real world?
  24. 24. A few points...
  25. 25. DATA
  26. 26. each service might have its own data-layer, but nothing prevents you from sharing data across the services
  27. 27. reads: abstract the data
  28. 28. WEBSERVICES
  29. 29. Services can request data to other services, usually through WSs
  30. 30. POX
  31. 31. SOAP
  32. 32. HTTP
  33. 33. REST
  34. 34. Note to self: check the difference between HTTP and REST APIs
  35. 35. Note to self: check the difference between HTTP and REST APIs (HATEOAS)
  36. 36. Note to self: check the difference between HTTP and REST APIs (HATEOAS)
  37. 37. EVENTS
  38. 38. services notify the architecture that an event has happened
  39. 39. asynchronous messaging queues
  40. 40. 2
  41. 41. TIPS AND TRICKS
  42. 42. LEARNT THE HARD WAY
  43. 43. 2.1 AVOID SOA
  44. 44. DIFFICULT TO TEST
  45. 45. COMPLEX
  46. 46. SOA would be overkill for most of the common scenarios
  47. 47. But if you're handling a product or a monolithic software stack, the added complexity pays off on the long run
  48. 48. 2.2 FREE THE DATA
  49. 49. CONSIDER ELIMINATING FK CONSTRAINTS
  50. 50. A service might need to handle data with another DBMS, so FKs are virtually impossible
  51. 51. ABSTRACT THE DATA
  52. 52. You might think in "rows" but the architecture thinks in "resources"
  53. 53. No more FKs and the ability of JOINing to retrieve some related data
  54. 54. But you choose what perfectly fits each service: your transactions over a RDBMS and your community over a graph DB
  55. 55. 2.3 Standardize
  56. 56. Build a vast suite of E2E tests
  57. 57. and give your developer a way to easily test
  58. 58. EVERY DEVELOPER NEEDS THE ENTIRE ARCHITECTURE ON LOCAL
  59. 59. The architecture needs to be installed in ~1 hour
  60. 60. Setting up VMs is an hassle and they are so slow!
  61. 61. go #vagrant
  62. 62. 2.4 IDENTIFY WISELY
  63. 63. AUTHENTICATION IS KING
  64. 64. Centralized authentication = identity service
  65. 65. NEVER HANDLE CREDENTIALS IN CLEAR
  66. 66. NEVER. man in the middle
  67. 67. NEVER. man in the middle SSL
  68. 68. NEVER. man in the middle SSL tokenize
  69. 69. OAuth
  70. 70. OpenID
  71. 71. JWS
  72. 72. JSON WEB SIGNATURE
  73. 73. JSON WEB TOKEN
  74. 74. JSON WEB SIGNATURE
  75. 75. JAVASCRIPT OBJECT SIGNING & ENCRYPTION
  76. 76. JOSE http://www.thread-safe.com/2012/03/json-object-signing-and-encryption-jose.html
  77. 77. 1. The user enters the credentials once in your frontend JS APP AUTH SERVICE 2. The JS app will forward them to your Auth webservice 3. The Auth webservice will then generate the encrypted JWS and set a cookie with its value JS APP 4. The JS app can now just execute calls using that cookie
  78. 78. 1. The user enters the credentials once in your frontend JS APP
  79. 79. AUTH SERVICE 2. The JS app will forward them to your Auth webservice JS APP
  80. 80. AUTH SERVICE 3. The Auth webservice will then generate the encrypted JWS and set a cookie with its value
  81. 81. JS APP AUTH SERVICE 4. The JS app can now just execute calls using that cookie
  82. 82. 1. The user enters the credentials once in your frontend JS APP AUTH SERVICE 2. The JS app will forward them to your Auth webservice 3. The Auth webservice will then generate the encrypted JWS and set a cookie with its value JS APP 4. The JS app can now just execute calls using that cookie
  83. 83. setcookie($name, $jws,$ttl, $path, $domain, true);
  84. 84. setcookie($name, $jws,$ttl, $path, $domain, true); HTTPS
  85. 85. JWS in PHP?
  86. 86. namshi/jose
  87. 87. use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get_privatekey("file://path/to/private. key"); $jws->sign($privateKey); setcookie('identity', $jws->getTokenString()); use NamshiJOSEJWS; $jws = JWS::load($_COOKIE['identity']); $public_key = openssl_pkey_get_public("/path/to/public.key"); if ($jws->verify($public_key)) { echo "EUREKA!; }
  88. 88. use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get_privatekey("file://path/to/private. key"); $jws->sign($privateKey); setcookie('identity', $jws->getTokenString()); use NamshiJOSEJWS; $jws = JWS::load($_COOKIE['identity']); $public_key = openssl_pkey_get_public("/path/to/public.key"); if ($jws->verify($public_key)) { echo "EUREKA!; }
  89. 89. use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get_privatekey("file://path/to/private. key"); $jws->sign($privateKey); setcookie('identity', $jws->getTokenString()); use NamshiJOSEJWS; $jws = JWS::load($_COOKIE['identity']); $public_key = openssl_pkey_get_public("/path/to/public.key"); if ($jws->verify($public_key)) { echo "EUREKA!; }
  90. 90. use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get_privatekey("file://path/to/private. key"); $jws->sign($privateKey); setcookie('identity', $jws->getTokenString(), ...); use NamshiJOSEJWS; $jws = JWS::load($_COOKIE['identity']); $public_key = openssl_pkey_get_public("/path/to/public.key"); if ($jws->verify($public_key)) { echo "EUREKA!; }
  91. 91. use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get_privatekey("file://path/to/private. key"); $jws->sign($privateKey); setcookie('identity', $jws->getTokenString()); use NamshiJOSEJWS; $jws = JWS::load($_COOKIE['identity']); $public_key = openssl_pkey_get_public("/path/to/public.key"); if ($jws->verify($public_key)) { echo "EUREKA!; }
  92. 92. use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get_privatekey("file://path/to/private. key"); $jws->sign($privateKey); setcookie('identity', $jws->getTokenString()); use NamshiJOSEJWS; $jws = JWS::load($_COOKIE['identity']); $public_key = openssl_pkey_get_public("/path/to/public.key"); if ($jws->verify($public_key)) { echo "EUREKA!; }
  93. 93. I can't simply use the HTTP basic authentication, it was so convenient!
  94. 94. ...and flawed. Modern apps, modern tech.
  95. 95. All my authenticated traffic needs to go through HTTPS: it will be so SLOW!
  96. 96. Only if you don't know about...
  97. 97. WebP
  98. 98. WebP lossless compression
  99. 99. WebP lossless compression 30% smaller than PNG
  100. 100. And if you don't know about...
  101. 101. SPDY
  102. 102. HTTP on steroids
  103. 103. (come to my next talk)
  104. 104. (that one won't suck)
  105. 105. 2.5 EMBRACE MESSAGING
  106. 106. Don't wait, notify instead
  107. 107. Different services can intercept an even, separately
  108. 108. If one is down, the others keep working
  109. 109. Who cares about milliseconds for notifications?
  110. 110. The human body is the bottleneck
  111. 111. Email?
  112. 112. SMS?
  113. 113. Be reliable
  114. 114. “Daemons are great”
  115. 115. “Daemons are great” - No PHP developer ever
  116. 116. SUPERVISOR http://supervisord.org/
  117. 117. SUPERVISE http://cr.yp.to/daemontools/supervise.html
  118. 118. use python ;-)
  119. 119. It doesn’t matter...
  120. 120. if you talk ‫اﻟﻌﺮﺑﯿﺔ‬ ‫اﻟﺤﺮوف‬
  121. 121. Rabbit makes everyone talk the same language
  122. 122. chat Batch processing frontend sync daemons transcoding agony ERP telcom
  123. 123. But I PHP
  124. 124. Monogamy is so ‘90 “given a hammer, everything becomes a nail”
  125. 125. One size doesn’t fit all
  126. 126. 2.5 ALWAYS SUNDAY?
  127. 127. Monitor in real time
  128. 128. and do retrospectives
  129. 129. Talking about retrospectives?
  130. 130. Logs are first-class citizens
  131. 131. Sharpen as much as possible
  132. 132. Assume things will break
  133. 133. All in all...
  134. 134. SOA is complex
  135. 135. A puzzle with more pieces
  136. 136. More things to keep in mind
  137. 137. COMPLEX IS NOT COMPLICATED
  138. 138. Loose coupling
  139. 139. every service is independent, not forced to the constraints of a monolithic block
  140. 140. you have the freedom of changing or replacing services without the hassle of touching an entire system
  141. 141. State-of-the-art defense against outages
  142. 142. Fault tolerance
  143. 143. if one of the services has an outage, the rest of the architecture still works
  144. 144. if a service, listening for messages, is down, the publisher doesn't get stuck
  145. 145. Cleaner architecture
  146. 146. SoC happens at architectural, not application, level and you can perform large-scale refactorings without the fear of destroying the entire system
  147. 147. Perfect ground for advanced tooling
  148. 148. ...yawn...
  149. 149. Alessandro Nadalin
  150. 150. Alessandro Nadalin @_odino_
  151. 151. Alessandro Nadalin @_odino_ Namshi | Rocket Internet
  152. 152. Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology
  153. 153. Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology odino.org
  154. 154. Thanks! Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology odino.org
  155. 155. Image credits http://www.flickr.com/photos/randystiefer/6998037429/sizes/h/in/photostream/ http://www.flickr.com/photos/55432818@N02/5500963965/ http://www.flickr.com/photos/pamhule/4503305775/ http://www.flickr.com/photos/wili/1427890704/ http://www.flickr.com/photos/nickpiggott/5212959770/sizes/l/in/photostream/ http://www.flickr.com/photos/nomad9491/2549965427/sizes/l/in/photostream/ http://www.flickr.com/photos/amyvdh/95764607/sizes/l/in/photostream/ http://www.flickr.com/photos/matthoult/4524176654/ http://www.flickr.com/photos/kittyeden/2416355396/sizes/l/in/photostream/ http://www.flickr.com/photos/jpverkamp/3078094381/ http://www.flickr.com/photos/madpoet_one/5554416836/ http://www.flickr.com/photos/87792096@N00/2732978107/ http://www.flickr.com/photos/petriv/4787037035/ http://www.flickr.com/photos/51035796522@N01/111091247/sizes/l/in/photostream/ http://www.flickr.com/photos/m-i-k-e/6366787693/sizes/l/in/photostream/ http://www.flickr.com/photos/39065466@N04/9111005211/ http://www.flickr.com/photos/marchorowitz/5449945176/sizes/l/in/photolist-9iAoQ1-8s4ueH-bCWef9-bCWdPh-e48XUm- bu67nh-a7xaEr-8wLiNh-9aYU1k-9F4VUN-dYqzr1-9vosHb-8BtFuw-8P3h2e-9tqc6M-82qpt4-7UgkBJ-dgSnfS-aJiubZ-9Xji2U-9UVpkC- 7BSh7Y-8GE54k-91GHtB-8VMHJ2-8wiwvo-aCmPCg-925Tg8-bcBv9T-dGUseY/ http://www.flickr.com/photos/blegg/745322703/sizes/l/in/photostream/ http://www.flickr.com/photos/centralasian/4649550142/sizes/l/in/photostream/ http://www.flickr.com/photos/pennstatelive/4947279459/sizes/l/in/photostream/ http://www.flickr.com/photos/tjblackwell/7819341478/ http://www.flickr.com/photos/brainbitch/6066375386/ http://www.flickr.com/photos/nnova/4215594009/ http://www.flickr.com/photos/publicenergy/2246574379/ http://www.flickr.com/photos/andrewteman/4592833017/sizes/o/in/photostream/ http://www.flickr.com/photos/beautifulrevelry/8548004964/sizes/o/in/photostream/ http://www.flickr.com/photos/denaldo/5066810104/sizes/l/in/photostream/ http://www.flickr.com/photos/picturewendy/8365723674/sizes/l/in/photostream/ http://www.flickr.com/photos/danielygo/6644679037/sizes/l/in/photostream/ http://www.flickr.com/photos/ross/7614352/sizes/l/in/photostream/ http://www.flickr.com/photos/75932013@N02/6874087329/sizes/l/in/photostream/ http://crucifixjel.deviantart.com/art/300-Wallpaper-03-66516887

×