Trends in technology. Audience was programmers / architects in a financial services domain.

1. Trends in Technology Dhananjay Nene July 13, 2010 http://blog.dhananjaynene.com http://twitter.com/dnene

2. Some quick caveats

3. A few, not most might be recent insights into some not so recent trends

4. Since we are dealing with the latest trends, some opinions might be forward looking

5. These opinions are my own and should not be construed to reflect anybody else's

7. Programming

8. Architecture

9. Miscellaneous

10. Client Tier Trends

11. The Rich Internet Client has been coming ...

12. .. but has been stifled by tensions between specificity and genericity ..

13. .. or between user interactiveness and time / cost

14. Some of these tradeoffs are most visible in the mobile space

15. eg. Internet Apps or Client Installables

16. Leveraging the platform, or coding to the common denominator

17. What is certain is that Richness is no longer the monopoly of the client installed

18. AJAX and Javascript have demonstrated the ability to create browser based rich applications

19. And jQuery has demonstrated the path to contain quirkiness, verbosity and high development costs

20. Even as CSS has taken on most presentation tasks

21. However new challenges emerge as the older ones are contained

22. Form factors moving from discrete to a continuum

23. Even as Touch Inputs become more heavily used

24. Platform shakeouts haven't happened Symbian, iOS, Android and others

25. Specificity vs Genericity is still a big issue

26. And no consistent customer expectations

27. I believe HTML5, CSS, Javascript, AJAX will dominate in the longer term for most but the most demanding client apps .. but thats a trend in progress

28. RIP : This site best viewed in Internet Explorer.

29. Firefox, Chrome, Safari & Other webkit browser support necessary

30. As is support for multiple form factors and input mechanisms (specifically touch)

31. Touch requires lot of dumbing down of screens

32. And more error tolerances (thus wider gaps between display units)

33. I believe there is an upcoming category for integrated clients which compose data across applications

34. A good example is HootSuite, TweetDeck, Seesmic supporting multiple social networks simultaneously

35. Similarly applications will be required to render themselves into common container clients

36. But of course we heard that earlier with portal servers .. so this is still up in the air

37. In the meanwhile users don't want to press the refresh or the save button

38. Comet and eventually HTML 5 Websockets to the rescue

39. Now onto programming ..

40. The Java mindshare erosion is substantial

41. And its usage is likely to be dipping

42. Java is the new low-level / infrastructure / plumbing language

43. Even as the JVM has never been in a stronger position

44. The VM is the new OS

45. Now cross VM support is being built for many languages eg. Python, Ruby, Scala and others

46. Dynamic languages (PHP, Python, Perl, Ruby) after earlier bursts continue to hold their own

47. Some of them are getting newer runtimes or environments (eg JRuby, PyPy, Jython, IronPython)

48. But new languages such as Scala and Clojure are capturing many developer's imagination

49. And Erlang, Haskell, F# - all functional programming languages show a steady climb even though from fairly small current usage

50. What is functional programming ?

51. In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state. .. source - Wikipedia

52. One of the suggested reasons for ascendancy of functional programming is the upcoming multicore challenge.

53. It is also suggested that programs are much easier to write and maintain using functional programming techniques.

54. Should one switch to functional programming ?

55. Depends upon the specific nature of applications

56. In any case it makes sense to slowly build adequate skillsets in the same.

57. The days of the dominant language (C, C++, VB, Java) seem to be over.

58. Moreover the days of one language for an app are also history

59. We already use HTML, CSS, Javascript + 1 backend language for all web applications

60. Now increasingly it will be just as easy to use multiple languages for the back end as well.

61. Polyglot programming is certainly a much easier option now.

62. Though adoption is still a little unclear.

63. Subversion was supposed to be the new & better CVS

64. But it is increasingly getting challenged by Git and Mercurial

65. The landscape is most certainly shifting towards DVCS

66. Architecture

67. Cloud

68. Beyond the will it become popular stage

69. While I am a little uncomfortable with the term private clouds, I shall let it stick

70. Enterprise private clouds likely to mirror developments in the internet based clouds

71. The interoperable cloud allows the possibility of private clouds for normal loads and leveraging the internet clouds for peak loads

72. The major influence is usage of a large number of commodity servers instead of smaller number of large capacity servers

73. This has an important requirement of making horizontal scaling necessary at much lower thresholds

74. NoSQL

75. The relational database has completely dominated the data storage space for long.

76. Even as it seems to be starting to face a substantial threat to that absolute dominance.

77. NoSQL is different things for different people. Its a family of approaches – not one approach

78. Complex relationship maintenance is requiring graph databases

79. Some apps prefer to move intelligence (schema) away from the database and into the application. Thus some prefer NoSQL for its schemaless capabilities.

80. But much of the pressure is coming from large internet sites

81. For whom the RDBMS doesn't provide the right CAP tradeoffs

82. it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees: Consistency Availability Partition Tolerance

83. The importance of C, A and P vary across different class of applications

84. Thus some particular approaches of NoSQL could be more or less applicable than others

85. Internet applications especially the really large ones, prioritize A and P in favour of C

86. However this audience focuses on financial software, and may find it more essential to prioritise C.

87. The key takeaway is to not treat C as always mandatory or required and deprioritise it where applicable – a process that requires some unlearning

88. Given a telecom analogy – the dawn of the stupid network, I find another reason why NoSQL is exciting.

89. According to that thought, internet won compared to POTS since it had a dumb network with intelligent endpoints compared to an intelligent network with dumb endpoints

90. Same for schemaless databases

91. Though I agree the thought is very hard to appreciate, when one has been exposed to SQL for long.

92. However, in relative terms this is still a nascent field. Observe carefully and leverage when and if appropriate

93. REST – Representational State Transfer

94. This is now the dominant style of architecting applications on the internet

95. REST and WS-* will compete inside the enterprise

96. While WS-* focuses on leveraging typical application design semantics including RPC, REST eschews complexity and focuses on simple document / resource access semantics

97. It is possible to talk at length on how REST leverages the very aspects that made other aspects of internet such as WWW successful.

98. But many coming from a more conventional distributed architecture background may find REST a little hard to find comfort with. Especially its lack of registries, no predefined metadata using IDL etc.

99. I find the arguments not too dissimilar from static vs. dynamically typed languages

100. REST makes it really easy for clients to leverage exposed API

101. Also Hypermedia as the engine of application state can actually help reduce many application state errors.

102. Mashups and application integration

103. Inter application collaboration for servicing a particular user request including interaction with existing SaaS applications (eg. Google Maps) going to be increasingly important

104. Lines between applications and services blurring

105. An interesting implication of mashups is in the area of transactions

106. 2PC / XA approaches of distributed transactions are simply impractical in large distributed services cloud especially on a WAN or across firewalls

107. Since technology is unlikely to help solve this problem, the solutions are going to come from remodeling the business logic.

108. eg. Long Running Business Transactions

109. Map reduce

110. Made popular by google

111. I see it increasingly used in the field of offline computations and analytics

112. Just earlier today AWS announced cluster compute instances : pair of quad core nodes with 10Gbps connectivity

113. The enterprise trails the internet

114. The momentum of architectural evolution is squarely with the internet applications

115. Browser platforms, Web 2.0, Social Networking, Cloud, REST, Mashups, NoSQL, Map Reduce are all internet contributions finding their way into the enterprise

116. Some other miscellaneous trends

117. Social Networking enters the enterprise

118. Geo tagging and Geo location databases

119. Oauth is the new authentication and authorisation system. Whither SAML ?

120. Javascript goes to the backend eg. node.js and V8

121. Fast Javascript engines allow high performance clients on the browser

122. Responsiveness starting to be a key requirement eg. Facebook Bigpipe

123. Design for extreme concurrency and long running connections eg. Tornado from Friendfeed

124. Thank You !