Language Abstractions for Scalable and Resilient Architectures

http://bucharestfp.ro/2015/04/29/language-abstractions-for-scalable-and-resilient-architectures/

Transcript

1. Functional Programming
 Language abstractions for scalable and resilient architectures
2. Modern architectures" • Complex interdependencies • Multiple layers of abstraction and indirection " Should be: • Resilient – able to scale up also down • Robust, antifragile " Antifragile: term coined by Nassim Nicholas Taleb. A system is antifragile if robust as a whole, regardless the failure of some of its individuals.
3. It’s ok to fail" • Failure is just a normal event, like any other " • Failure is natural, successful systems have individuals’/components’ failure built into the design " • Some examples: " • In IT, the long standing and omnipresent proof of success for the “ok to fail” design : the TCP/IP stack • In real life: human specie, as a whole, is successful and robust " • Tools eg programming languages, where the focus is on actions and interactions (verbs in FP paradigm), are naturally fitted for building complex resilient systems.
4. The legacy we live with - a part of it • The 70’s: C language. It’s design provided the first powerful, revolutionary abstractions that mapped efficiently to the typical machine instructions back then, as they still do, nowadays " • The 80’s: C++ came along, and the OO golden age began: data, actions and the desired result of actions upon data stay together conceptually, abstracted by classes and objects (encapsulated stateful interaction, designed strong coupling between actions/behavious and state). Other existing paradigms and supporting languages (eg functional) existed but were not mainstream (Lisp – created in 1958, Haskell etc). " • The 90’s – Java. First JVM. The machine becomes abstract (another layer of indirection). JVM as another layer of indirection lead to the creation of Java.next languages: • Clojure – functional and dynamically typed • Scala – multiparadigm, OO & functional, statically typed • Groovy, Clojure – Lisp implementation on JVM • Last but not least, Java 8 adopts functional programming and design patterns, with higher-order functions, streams etc.
5. Standing on the shoulders of giants • Erlang " • Joe Armstrong – awesome engineer, and awful C programmer • http://youtu.be/HCwRGHj5jOE, so it’s ok to fail as C user and still design a revolutionary language with a virtual machine written in C, as long as you are part of an extraordinary team that compensates for the lack of C usage skills :) " • In Erlang the way components are able to interact ensures the key to system robustness. So we had the first software language designed with “individual failure is normal” in mind " • Design choices: • Processes – share no memory, are insulated and can interact only with each other by exchanging messages; managed by Erlang VM with lightweight memory footprint • Supervisor (OTP) • Process communication constructs: messages, links, signals, monitors
6. Powerful abstractions" • Immutability and persistent data structures – Chris Okasaki's Purely Functional Data Structures http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf " • Sequences are immutable – just a way to consume a succession of data. • In Clojure are immutable and represent an abstraction over the underlying data structure per se (do not modify the storage structure of that data). They are only a view over the underlying data, unlike Java iterators " • Laziness – the value is not computed until actually required • As a design choice, FP languages have structures that are intentionally lazy (eg map, filter and so on) • Once a value is computed, it is cached so that any future reference need not re- compute it. The term for this caching is memoization.
7. Three constructs for concurrency by design Erlang AKKA Clojure Design choice Process: " - Run inside Erlang VM (not OS process) - Lightweight - Use dynamically allocated stack -> memory allocation performance - Communicate by exchanging messages asynchronously Actor: " - Fully location transparent, decoupling between the running instance of the actor and the reference to the actor - Lightweight processes - Share-nothing, fully isolated - Non-blocking, asynchronous message communication; (mailbox, message queue) - Actors controlled by scheduler Agent: " - Also in Scala AKKA - Provide independent, asynchrono us change of individual locations - Bound to a single storage location for their lifetime (as opposed to actors), and only allow mutation of that location (to a new state) to occur as a result of an action - Actions are functions (may be polymorphic) that are asynchronously applied to an Agent's state and whose return value becomes the Agent's new state.
8. Reactive Streams • http://www.reactive-streams.org/ " • Driven by industry (from companies with similar needs the reactive streams were born; a collaboration between Netflix, Pivotal, RedHat, Twitter, Typesafe and others) " • API for Stream-oriented libraries for the JVM that process a potentially unbounded (infinite) number of elements in sequence, asynchronously passing elements between components, with mandatory non-blocking backpressure (the receiving side is not forced to buffer arbitrary amounts of data), in a publisher-subscriber pattern. " • Inspired by the Reactive Manifesto (http://www.reactivemanifesto.org/)
9. Vă mulțumesc. " " Întrebări și discuții ? " Let’s handle them asynchronously, in a message driven manner :)