forty years of pretending
play

Forty Years of Pretending @reiddraper About me Eng. @ Basho - PowerPoint PPT Presentation

Forty Years of Pretending @reiddraper About me Eng. @ Basho @reiddraper Nobody ever got fired for making an RPC call RPC claims transparency between local and remote procedure calls This abstraction fails Even a simple web app is a


  1. Forty Years of Pretending @reiddraper

  2. About me

  3. Eng. @ Basho @reiddraper

  4. Nobody ever got fired for making an RPC call

  5. RPC claims transparency between local and remote procedure calls

  6. This abstraction fails

  7. Even a simple web app is a distributed system

  8. A resurgence with Javascript

  9. RPC

  10. History

  11. Pretending

  12. Today

  13. Tomorrow?

  14. RPC

  15. R emote P rocedure C all

  16. [ … ] RPC mechanism is one in which local procedures and remote procedures are (effectively) indistinguishable to the programmer. - Nelson

  17. [ … ] the calling environment is suspended, the parameters are passed across the network to the environment where the procedure is to execute [ … ], and the desired procedure is executed there. [ … ] the results are passed backed to the calling environment, where execution resumes as if returning from a simple single-machine call - Nelson

  18. A synchronous network call does not make RPC

  19. send(2) is not an RPC call

  20. transparency between local and remote procedure calls

  21. Motivation for RPC

  22. Distributed systems are hard

  23. The procedure call is familiar

  24. Let's lift distributed programming to the procedure call abstraction

  25. Let's lift distributed programming to the method call abstraction

  26. Let's lift distributed programming to the function call abstraction

  27. History

  28. Telnet

  29. RFC 674 1974 Postel and White

  30. P rocedure C all P rotocol

  31. RFC 707 1976 White

  32. R emote P rocedure C all

  33. The principal goal of all resource- sharing computer networks, including the now international ARPA Network (the ARPANET), is to usefully interconnect geographically distributed hardware, software, and human resources - White

  34. It forces upon the user all of the trappings of the resource's own system. - White

  35. It provides no basis for bootstrapping new composite resources from existing ones. - White

  36. Xerox Remote Procedure Call XML-RPC RFC 674 CORBA v1 2014 1974 1981 1991 1998 1970 1976 1984 1995 2003 RFC 1831 RFC 707 SOAP Implementing Remote Procedure Calls

  37. An alternative history

  38. The Actor Model 1973 Hewitt

  39. RFC 684 1975 Schantz

  40. [ … ] objection to the"PCP philosophy" - Schantz

  41. RPC blurs the line between local (cheap) and remote (expensive)

  42. RPC blurs the line between local ( cheap ) and remote ( expensive )

  43. [ … ] a model which relies on procedure calling for its basis does not take into account the special nature of the network environment - Schantz

  44. [ … ] and that such an environment can be more suitably handled in a message passing model. - Schantz

  45. Goes on …

  46. A Critique of the Remote Procedure Call Paradigm 1988 Tanenbaum van Renesse

  47. Implementing Distributed Systems Using Linear Naming 1993 Bawden

  48. RFC 2616 (HTTP 1.1) 1999 Fielding et al.

  49. REST 2000 Fielding

  50. Problems with RPC

  51. Consistent code

  52. How do you atomically update the code?

  53. Handling failure

  54. What if the remote node never responds?

  55. Or the underlying TCP connection is closed?

  56. Did it fail halfway through?

  57. Did it fail right before it returned to us?

  58. Why don't we have a stacktrace?

  59. What if our procedure made another RPC call?

  60. Serializing values

  61. How do you serialize a file- descriptor?

  62. How do you serialize a database connection?

  63. The streaming problem

  64. Can we start processing partial results?

  65. The continuation problem

  66. The procedure call only models A->B->A communication

  67. (8) Fallacies of Distributed Computing

  68. Fallacies of Distributed Computing

  69. 1. The network is reliable

  70. 2. Latency is zero

  71. 3. Bandwidth is infinite

  72. 4. The network is secure

  73. 5. Topology doesn't change

  74. 6. There is one administrator

  75. 7. Transport cost is zero

  76. 8. The network is homogeneous

  77. Today

  78. Javascript and compile-to-Javascript

  79. Code sharing!

  80. Coupling

  81. Even a simple web app is a distributed system

  82. meteor.js derby yesod-fay shoreleave hapstack dnode now.js nodejs-light_rpc

  83. Tomorrow

  84. The principal goal of all resource- sharing computer networks, including the now international ARPA Network (the ARPANET), is to usefully interconnect geographically distributed hardware, software, and human resources - White

  85. Distributed systems are still hard

  86. Implementing Distributed Systems Using Linear Naming 1993 Bawden

  87. Bloom (UC Berkeley)

  88. Questions @reiddraper

Recommend


More recommend