Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Language Abstractions for Scalable and Resilient Architectures

Language Abstractions for Scalable and Resilient Architectures

0286822f506fc4621bd3ea0bcbfef238?s=128

Bucharest FP

April 29, 2015
Tweet

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 :)