Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
TIPS AND TRICKS FOR YOUR SERVICE ORIENTED ARCHITECTURE CakeFest, San Francisco, Sep 2013
WARNING
NO CAKEPHP AHEAD
This talk is for those...
Stuck with the legacy
dealing with CRONs
in the need of a solid foundation
rely on web services
need a pluggable software architecture
SOA
Agenda 1. Service Oriented WHAT?!?! 2. Tips, Tricks and lessons learned (the hard way) 3. Conclusion
1
SO(A) WHAT?
A software design based on discrete software components, "services", that collectively provide the functionalities of the ...
You typically start with the infamous web application which does everything on its own
Then you realize that to provide a chat system to your users PHP might not be the best...
And soon you also decide, to improve performances, that your frontend should have its own in-memory persistence, to be fas...
Then, as always...
SCALE.
And eventually, your lead architect will come up and tell you that your Java-based chat sucks and should be replaced with....
NODEJS
In human-understandable words, SOA is a software design which embraces splitting a monolithic, totalitarian software archi...
Ok, but in the real world?
A few points...
DATA
each service might have its own data-layer, but nothing prevents you from sharing data across the services
reads: abstract the data
WEBSERVICES
Services can request data to other services, usually through WSs
POX
SOAP
HTTP
REST
Note to self: check the difference between HTTP and REST APIs
Note to self: check the difference between HTTP and REST APIs (HATEOAS)
Note to self: check the difference between HTTP and REST APIs (HATEOAS)
EVENTS
services notify the architecture that an event has happened
asynchronous messaging queues
2
TIPS AND TRICKS
LEARNT THE HARD WAY
2.1 AVOID SOA
DIFFICULT TO TEST
COMPLEX
SOA would be overkill for most of the common scenarios
But if you're handling a product or a monolithic software stack, the added complexity pays off on the long run
2.2 FREE THE DATA
CONSIDER ELIMINATING FK CONSTRAINTS
A service might need to handle data with another DBMS, so FKs are virtually impossible
ABSTRACT THE DATA
You might think in "rows" but the architecture thinks in "resources"
No more FKs and the ability of JOINing to retrieve some related data
But you choose what perfectly fits each service: your transactions over a RDBMS and your community over a graph DB
2.3 Standardize
Build a vast suite of E2E tests
and give your developer a way to easily test
EVERY DEVELOPER NEEDS THE ENTIRE ARCHITECTURE ON LOCAL
The architecture needs to be installed in ~1 hour
Setting up VMs is an hassle and they are so slow!
go #vagrant
2.4 IDENTIFY WISELY
AUTHENTICATION IS KING
Centralized authentication = identity service
NEVER HANDLE CREDENTIALS IN CLEAR
NEVER. man in the middle
NEVER. man in the middle SSL
NEVER. man in the middle SSL tokenize
OAuth
OpenID
JWS
JSON WEB SIGNATURE
JSON WEB TOKEN
JSON WEB SIGNATURE
JAVASCRIPT OBJECT SIGNING & ENCRYPTION
JOSE http://www.thread-safe.com/2012/03/json-object-signing-and-encryption-jose.html
1. The user enters the credentials once in your frontend JS APP AUTH SERVICE 2. The JS app will forward them to your Auth ...
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 JS APP
AUTH SERVICE 3. The Auth webservice will then generate the encrypted JWS and set a cookie with its value
JS APP AUTH SERVICE 4. The JS app can now just execute calls using that cookie
1. The user enters the credentials once in your frontend JS APP AUTH SERVICE 2. The JS app will forward them to your Auth ...
setcookie($name, $jws,$ttl, $path, $domain, true);
setcookie($name, $jws,$ttl, $path, $domain, true); HTTPS
JWS in PHP?
namshi/jose
use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get...
use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get...
use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get...
use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get...
use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get...
use NamshiJOSEJWS; $jws = new JWS('RS256'); $jws->setPayload(array( 'uid' => $user->getid(), )); $privateKey = openssl_get...
I can't simply use the HTTP basic authentication, it was so convenient!
...and flawed. Modern apps, modern tech.
All my authenticated traffic needs to go through HTTPS: it will be so SLOW!
Only if you don't know about...
WebP
WebP lossless compression
WebP lossless compression 30% smaller than PNG
And if you don't know about...
SPDY
HTTP on steroids
(come to my next talk)
(that one won't suck)
2.5 EMBRACE MESSAGING
Don't wait, notify instead
Different services can intercept an even, separately
If one is down, the others keep working
Who cares about milliseconds for notifications?
The human body is the bottleneck
Email?
SMS?
Be reliable
“Daemons are great”
“Daemons are great” - No PHP developer ever
SUPERVISOR http://supervisord.org/
SUPERVISE http://cr.yp.to/daemontools/supervise.html
use python ;-)
It doesn’t matter...
if you talk ‫اﻟﻌﺮﺑﯿﺔ‬ ‫اﻟﺤﺮوف‬
Rabbit makes everyone talk the same language
chat Batch processing frontend sync daemons transcoding agony ERP telcom
But I PHP
Monogamy is so ‘90 “given a hammer, everything becomes a nail”
One size doesn’t fit all
2.5 ALWAYS SUNDAY?
Monitor in real time
and do retrospectives
Talking about retrospectives?
Logs are first-class citizens
Sharpen as much as possible
Assume things will break
All in all...
SOA is complex
A puzzle with more pieces
More things to keep in mind
COMPLEX IS NOT COMPLICATED
Loose coupling
every service is independent, not forced to the constraints of a monolithic block
you have the freedom of changing or replacing services without the hassle of touching an entire system
State-of-the-art defense against outages
Fault tolerance
if one of the services has an outage, the rest of the architecture still works
if a service, listening for messages, is down, the publisher doesn't get stuck
Cleaner architecture
SoC happens at architectural, not application, level and you can perform large-scale refactorings without the fear of dest...
Perfect ground for advanced tooling
...yawn...
Alessandro Nadalin
Alessandro Nadalin @_odino_
Alessandro Nadalin @_odino_ Namshi | Rocket Internet
Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology
Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology odino.org
Thanks! Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology odino.org
Image credits http://www.flickr.com/photos/randystiefer/6998037429/sizes/h/in/photostream/ http://www.flickr.com/photos/55...
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Tips and Tricks for your Service Oriented Architecture @ CakeFest 2013 in San Francisco
Upcoming SlideShare
Loading in …5
×

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

6,067 views

Published on

A collection of advices to not bang your head against the wall like I did while taming service-oriented architectures.

Published in: Technology, Education
no profile picture user
Show More

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

×